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"
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
Stephan Tilkov responded to this post
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:
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
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
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.