Book Cover B = mC2

Business Strategy in a Multidimensional World


  • 12/08/2007: I have publish an article "The 7 Fallacies of Business Process Execution" which explains how BPMN and BPEL relate with each other and how to position BPEL in a BPMS.
  • 9/27/2007: I created WS-BPEL 2.0 metamodel. You can view it here.


Where is BPEL 2.0 going?

I am commenting here the WS-BPEL working draft 4/23/04 which is publicly available on the OASIS web site.

It looks like the BPEL working group is moving ahead with its plan to focus BPEL on B2B relationships. It can be applied in one of two ways, a BPEL process can define:

  • "a business protocol role, using the notion of abstract process".
  • "an executable business process, i.e. the logic and state of the process determine the nature and sequence of the Web Service interactions conducted at each business partner, and thus the interaction protocols".

One of the BPEL goals is to "lower the cost in establishing cross-enterprise automated business processes".

I guess I am very confused by these statements. After working for four years on ebXML, and being the editor of the ebXML Business Process Specification Schema module, I cannot but wonder how BPEL can be used in B2B scenarios. So problably the best way to continue my commentary is to take an example, say a simple RFQ/Order/Payment collaboration between a buyer and a supplier. I have taken an example that is simple but non trivial like the so many examples used to illustrate BPEL.

(Click to enlarge)

This example is using BPMN and details 3 main components of the overall process. The private process of the buyer, the private process of the supplier and collaboration between the buyer, the supplier, the bank and the credit check organization. The private process starts and as part of its "GetQuote" activity it sends an RFQ document to the supplier (this is when the collaboration starts). When the supplier receives this document it dispatches it to its ProcessRFQ activity. This activity is invoking the PrepareQuote activity which is actually an activity performed by a user. As part of the activity, the user invokes the ManageAccount activity which is in charge of creating a customer record if the customer is unknown and in all cases to perform a credit check with a partner agency. If all goes well, a quote is returned to the processRFQ activity which forward it to the customer. If the customer likes the quote, its process stipulates that it will start the SendOrder activity which creates and send an order relative to the quote. When the order is received by the supplier, it dispatches to the processRFQ activity, which ends at this point, and initiate the processOrder activity which notifies the IssueInvoice activity which sends an invoice as a response to the order. And so on...

If you want to see the details of one activity, please see figure 2.

Now, as you can see here, there are several concepts that ARE NOT supported by BPEL:

  • Of course the notion of activities performed by a user
  • the notion of independent activities, everything in a BPEL is a web service operation, not "an activity", i.e. a unit of work
  • the notion of activities interacting together two-by-two. One the supplier side, BPEL requires for instance two BPEL definitions, one to support the interaction between processRFQ and CreateQuote on one side and CreateQuote and ManageUser on the other side
  • On the B2B front, BPEL cannot efficiently represent the choreography of the collaboration independently of the abstract behavior of each party (See collaboration in blue)
  • It cannot represent either the multiparty collaboration featured above, where a credit check is performs on initiation of the Order/Invoice operation (i.e. when the request is sent and before the Invoice is returned). BPEL can only represent multiparty collaboration that have a "center" of control. We are back to the Ariba/CommerceOne days with some B2B agent in the middle. We all know how successful was that model.

Now, on the "EAI" front (BPEL does not claim clearly that space but some vendors like Collaxa view as a domain of application of BPEL), BPEL is not much more efficient than on the business process or B2B collaboration space. If I completely agree with Collaxa on the fact that EAI is a good domain of application for BPEL, BPEL is still missing the capability of transformation so useful in that space. In the example above, for instance I cannot say that the order document consumed by my ProcessQuote activity is actually a transformed version of the order document sent by the buyer. These kinds of transformation are done "by hand" with the assign/copy activity. BPEL is so entrenched in B2B now that when you try to apply BPEL to EAI you realize that every message based activity (send receive and invoke) have a "partnerLink", ... but in EAI there is no partner, just components. So if you now have a private process linking your B2B interface to your back end systems you are left with this dilemma that some activities must have a partnerLink while other don't.

Nothing has fundamentally changed compared to my previous analysis of BPEL.

So where does this leaves us? I have been arguing for sometime that BPEL is a programming language that let us write business logic that can be part of a business process. In the example above, the processRFQ or manageAccount, or sendOrder/processOrder activities are all (web) services that manage a given business entity (RFQ, Account, Order). The lifecycle of these services is long running itself as the business processes they participate in. Typically this business logic is very hard to write, debug, maintain. Most technologies like Java/J2EE or .NET/COM+ have never been designed for that purpose. All message handling is done as hoc. It looks like that some people understand this since IBM and BEA (and Collaxa way before them) has come up with the concept of BPEL-J.

So a service would look like this:

This service is "orchestrated" and can easily be described in BPEL (without partnerLinks). The business process itself is not an orchestration but a choreography. This concept is now supported by WS-CDL and its authors, and I think to a certain extend by BPMN.

Unfortunately, by pushing BPEL in the wrong direction, the working groups and editors will achieve nothing: the B2B model supported by BPEL will not be able to compete with the one proposed by WS-CDL and ebXML BPSS, while the at the same time, we would still be waiting for an "orchestration" language that no one else is working on. I have my little idea of the politics behind all this but it is kind of sad that after working for 5 years on the problem (XLang was announced in the spring of 1999) we never left the starting blocks, as I said before, BPEL represents how we thought (I thought) about Business Processes 5 years ago. In five years, we've got five years behind.

Jean-Jacques Dubray 6/13/04



  Hit Counter