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:
src="bpel_2_0_files/image002.gif" v:shapes="_x0000_s1025">
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
