Why do I strongly support BPEL-J?
BPEL-J is a proposal based on an already old idea (time flies) that I think was originally coming from Collaxa and Edwin's team. The concept was and still is brilliant and relies on the fact that BPEL is an orchestration language. Once you realize this, the next question becomes since it belongs to the family of programming languages, how can we make it "complete" not as in "turing complete" but rather is in "practically complete" such that developers using it are not struggling to write code that take advantage of it. Collaxa had done a lot of exploratory work (including building a product) in this area, while a standardization committee (JSR-207) was formed mainly driven by IBM and BEA. I have been a supporter of the idea ever since I got acquainted to Edwin in the fall of 2002 and got a chance to give feedback on their 1.0 product.
I am glad to see that now the heavy weights of application development infrastructures are also interested in the idea. This should ensure wide adoption of the concept and benefit SOA first and BPM second. (SOA is still in search for a "language" now that we have some idea on what "architecture" means).
Here is my take on where I think BPEL-J fits. I don't expect anyone at BEA, IBM or Collaxa, or even actually in the BPEL community to agree with me. But again, feedback is welcomed.
Nowadays, everybody talks about SOA, Web Services, and BPM but very few people talk about how to re-engineer existing applications or build new applications based on these concepts. A lot of examples of these technologies are actually "toy" applications like stoke quote or weather forecast.
For me SOA, Web Services and BPM provide me with the tools to build business logic that is:
- Integration ready
- Independent of the context in which this business logic is used
For instance, BPEL-J (it would be too complex in BPEL) allows me to write an "Quote Service" that precisely models the lifecycle of my quotes and the logic associated to how my company processes RFQ/Quotes/Orders.
What this picture shows is that I have constructed a web service that I can describe with WSDL (note how this web service is not just request / response but rather an orchestrated series of operations). This web service manages the lifecycle of a quote that gets created when an RFQ is received, and ends when the corresponding order is received. The service is build in a way that the quote generation itself is done outside, managed by another service or activity (see business process below). This is what I call "context independence" (context of usage that is).
Now, how can I use this service in a business process? Here is one possible business process: as a supplier providing a quote-to-cash business process. This process specifies that the RFQ has to be manually processed (a quote is returned from this activity). During the RFQ review, the user agent may create a new account via the account service. The Quote service invokes the SalesTax.com service, updates the quote and return it to the buyer. Then the buyer sends an order which is dispatched to both the Quote and Order service (via my BSI - business service interface). At this point the quote service instance is considered complete but my quote-to-cash process continues. My business process definition brings together a series of services that did not necessarily need to be designed to work together.
So, BPEL-J gives us a new implementation model for web services. Unlike my father's Java language, I can readily write business logic that can integrate with its peers and that can support long running asynchronous interactions with other pieces of business logic (don't try this at home with your regular JDK). This is the perfect programming model for building "model-oriented" business logic that is BPM ready.
A "Business Process" is a concepts that sits on top of these web services and that bring a series of peer web services into a "multi-party" collaboration. In this model, the services themselves are orchestrated not the business process ! This is not a Hub-and-spoke orchestration, but a collaboration of orchestrated services. It is merely the initiations of events (systems, partner, user) and subsequent responses of the orchestrated services which advance the state of the business process. Consequently, a business process engine is not "centralized" but is built around an architecture suggested by WS-CAF.
BPEL-J should spark a new wave of developments and will encourage the use of a new application model. This application model will finally support BPM readily unlike ECA based models like J2EE (I don't say .NET here because .NET has WSE 2.0 and soon Indigo, but you can also use .NET like J2EE). Of course, we now need to start working on the "business process definition language".
_____________________________________________________________________________________________
Stephan Tilkov responded to this post here.
I would like to re-iterate that what I am saying here, I never heard anyone saying it, even Edwin who invented the combination between Java and BP definition languages, so please hear me carefully, I am not recommending to use BPEL-J the way everybody recommends to use BPEL.
I say clearly that BPEL-J is a programming language well suited for implementing web services, not a business process definition or execution language.
Now, what can you do with this programming language that you could not do with Java:
a) existing business logic or the one you can code today with Java/EJB and C# is not “Business Process Ready”, i.e. I cannot mingle this business logic in my processes (someone has to do some work, right, so this business logic will be invoked one way or another by your business process). Whether process engine vendors or people like Howard Smith like it or not, you cannot take an existing application and "extract" its processes and run them in process engine without changing anything else. Existing application models simply do not land themselves to a business process approach. They rather follow the ECA (even condition action model) and are very synchronous in nature.
b) BPEL-J is the ideal programming language to write business process ready business logic. What I can do with BPEL-J is define how my organization should process orders (not at the business process level) but at the business logic, i.e. model oriented business logic level. Thanks to BPEL-J, I can now encapsulate the lifecycle of my orders in a service, regardless of the business process that a particular PO is being dealt with.
c) Of course, if you think of using BPEL for modeling Business Processes (but again, it is not designed for that ;-), BPEL-J is a big step backwards, java code has nothing to do in a business process definition.
Once I have build my order entry service with BPEL-J, I can now use it in various processes. It is going to guarantee me that regardless of the business process it is used in, my orders will be processed consistently. If all you had was Java, it would be much harder to write an Order Entry service that is business process ready.
