Disclaimer: The views expressed in this analysis only
reflects the views of the author and not necessarily the one of his company.
This page provide an
analysis on BPEL4WS 1.0, it is so close to the new
(1.1) that this analysis is still valid. Actually, as of June 04 the draft of
BPEL 2.0 does not show major differences from the
The specification is now
named BPEL or WS-BPEL. The working group is the
OASIS WS-BPEL Technical Committee.
See also "The
end in mind..." article which looks at why BPM today and where it is
See my comment on "Where
is BPEL 2.0 going?"
v1.0.0 09/15/02 First version
v1.0.1 11/22/02 Added some comments about
the "partner" attribute, and
v1.0.3 3/14/03 Updates
support from Collaxa and BindSystems
v1.0.3 9/22/03 Added new
reference to BPEL tutorial
v1.0.4 8/10/04 Updated the
You might want to take a look at the
definition of orchestration with respect to
composition, choreography, collaboration, and so on. Originally, BPEL was geared
towards developing an orchestration language. Overtime, the scope expanded, you
might want to read this document to understand where is
BPEL going today. I think that the future of BPEL is
something like BPEL-J.
Since this commentary was first
written, BPEL has risen in popularity and two camps have formed: the
one that consider BPEL as an execution language (Oracle, IBM,
FiveSight, OpenStorm, ...) and the ones that consider BPEL an
exchange format: Microsoft and BEA.
BPEL4WS recognizes the need for an independent (and choreographed)
representation of the interactions between parties. The neologism used here is
"business protocol" specified as abstract processes. Incidentally,
ebXML has worked on this concept since the fall of 1999, and provided a specification in May of 2001
Business Protocol: "Specify the mutually visible
message exchange behavior of each of the parties involved in the protocol,
without revealing their internal behavior"
Executable: "Executable business
processes model actual behavior of a participant in a business
Private: executable process
Public: business protocol
Abstract: processes involved in the definition of business protocols.
"Abstract processes are not typically executable.
They are meant to couple Web Service interface definitions with behavioral
specifications that can be used to both constrain the implementation of
business roles and define in precise terms the behavior that each party in a
business protocol can expect from the others." In other word
this is a process interface from the point of view of the party exposing
Service Interface: "The interaction with
each partner occurs through Web Service interfaces, and the structure of the
relationship at the interface level is encapsulated in what we call a service
link.". The spec does not seem to explain very well the
difference between an abstract process, a business protocol and a service
interface. In any case, there seem to be no elements or series of elements
supporting the concept of business protocol as defined above in the spec.
WSDL 1.1, XML Schema 1.0, and XPath1.0.
A process definition is made of one activity, a series of partners and
containers with specific correlation sets, the definition of fault handlers and
An activity is itself decomposed in various elements
The control flow is a nice hybrid model half-way between block structured and
state transition control flow definitions. The model uses "links" to
establish the dependencies between block definitions: "The
links are defined inside the flow and are used to connect a source activity to a
"When a fault occurs, normal processing is
terminated and control is transferred to the corresponding fault handler"
The control flow is pretty much defined by all the possible activities as
defined by BPEL semantics.
"The creation of a process instance is always
implicit; activities that receive messages (that is,
pick activities) can be annotated to indicate that
the occurrence of that activity causes a new instance of the business process to
"A business process instance is terminated in one
of the following ways:
When the activity that defines the behavior of the
process as a whole completes. In this case the termination is normal.
When a fault reaches the process scope, and is
either handled or not handled. In this case the termination is considered
abnormal even if the fault is handled and the fault handler does not rethrow
any fault. A compensation handler is never installed for a scope that
When a process instance is explicitly terminated by
a terminate activity (see Terminating the Service Instance). In this case
the termination is abnormal.
If a compensation handler is specified for the
business process as a whole (see Compensation Handlers), a business process
instance can be compensated after normal completion by platform-specific
means. This functionality is enabled by setting the
enableInstanceCompensation attribute of the process to
I could not find any reference to a process composition
(and the notion of sub-process).
The message flow is handled by 3 types of activities: receive, reply and
invoke. Receive and reply may be assigned to the same operation in case of
request/response. Invoke is used to define a solicit response operation type.
Interestingly enough, "partner" is a required attribute of these
activities which lead us to believe that messages can only be exchanged with the
outside world? In particular a process could not be used to describe the message
exchange between any two internal components (e.g. order entry and billing).
Another somewhat broken semantic is the lack of timeout
on an invoke activity. What if the response never comes back? No fault handler
can be activated.
"The information is passed between the different
activities in an implicit way through the sharing of globally visible data
containers." Containers may exchange specific data elements via the
use of "Assign" statements.
<from container="PO" part="customerInfo"/>
There is no capability provided by
BPEL to specify and execute transformations on the data.
Now one could argue that the business process definition is not the best place to specify a transformation on the containers since
BPEL allows for dynamic participants. In this case the transformation definition should relate the participant and a container.
However, it would be probably useful and simple to allow for a <transform> element that works just like assign except that the content of the target container is filled with the transformed content of the source container.
"There is a long history of work in this area
regarding the use of Sagas  and open nested transactions . BPEL4WS
provides a variant of such a compensation protocol by providing the ability for
flexible control of the reversal. BPEL4WS achieves this by providing the ability
to define fault handling and compensation in an application-specific manner,
resulting in a feature called Long-Running (Business) Transactions (LRTs)."
"It is important to understand that the notion of
LRT described here is purely local and occurs within a single business process
instance. There is no distributed coordination regarding an agreed-upon outcome
among multiple-participant services. The achievement of distributed agreement is
an orthogonal problem outside the scope of BPEL4WS, to be solved by using the
protocols described in the WS-Transaction specification.".
LRT are typically "undone". Business
rules to undo certain operations typically vary from use case to use case. "[The]
scope [element] can delineate a part of the behavior that is meant to be
reversible in an application-defined way by a compensation handler. Scopes with
compensation and fault handlers can be nested without constraint to arbitrary
BPEL supports extensibility by allowing
namespace-qualified attributes to appear on any BPEL element
and by allowing elements from other namespaces to appear within BPEL defined
elements. This is allowed in the XML Schema specifications for BPEL .
An extension namespace is declared by using the
BPEL finally acknowledge the importance of this
concept. It also recognizes that this type of relationship is peer-to-peer (and
not client server like the contract of XLang). They still think that "RPC"
is a valid mechanism to do B2B, but they acknowledge that asynchronous message
exchange is the primary mechanism. This is a big progress !
"The notion of service links is used to directly
model peer-to-peer partner relationships. " Fortunately
it was designed such that "the actual partner
service may be dynamically determined within the process".
The building block of a collaboration definition look
This seems a little bit weak as a collaboration
definition. This relationship is expressed at the port type level and not at the
operation level which it is made of. The link between the bindings is done in a
different element, the serviceReferences.
The choreography of the collaboration is defined as an
"abstract process". This rightfully chosen name (the collaboration
definition remains a bit abstract between all these links and interface
definition) is nothing more than a traditional process definition with some
limitations that would not make sense in a collaboration definition.
Well we hit a fundamental flaw of the web service
technology when it comes to collaboration definition and linking this
collaboration to an executable process. We have two service definitions
interacting in peer-to-peer mode, and the process definitions must constantly
hop from one definition to another based on the direction of the operation
(initiating message of the operation). By contrast ebXML define reusable units
of message exchange (business transactions), and it is only its usage within a
particular collaboration definition which determines the direction. In
ebXML we do not adopt any point of view as opposed to in the web services
framework one can only specify an interface. Not to confuse anyone, each WSDL
API definition is mirror of each other in order to enable the linking
definition. It is probably about time that the web services working group
abandon this approach to use the one specified by ebXML. (How likely is that to
<source linkName="ship-to-scheduling"/> </receive>
If this kind of specification was designed by some business analyst based
on a a real business scenario, there would be no operation called xxxCallback
!! I am wondering when the web services people will stop thinking of B2B other
than as COM or CORBA over the internet.
It is good to see that web services people finally understand the importance
of the "Collaboration" concept developed by ebXML on the foundation
work of other groups like RosettaNet or the TMF. In particular being able to
express a clear view of the collaboration is the only way to form agreements (at
the business process level) between two or more companies.
However, "BPEL" authors do not yet understand the concepts of
"Business Transactions" and its necessity for business state
alignment. They keep talking about callbacks and shy away from assembling
messages into meaningful transactions which when successful guarantee state
alignment: "The example makes the implicit assumption
that the customer request can be processed in a reasonable amount of time,
justifying the requirement that the invoker wait for a synchronous response
(because this service is offered as a request-response operation). When that
assumption does not hold, the interaction with the customer is better modeled
as a pair of asynchronous message exchanges. In that case, the "sendPurchaseOrder"
operation is a one-way operation and the asynchronous response is sent by
invoking a second one-way operation on a customer "callback"
interface. In addition to changing the signature of "sendPurchaseOrder"
and defining a new portType to represent the customer callback interface, two
modifications need to be made in the preceding example to support an
asynchronous response to the customer...". Unfortunately, in the
real (business) world we usually don't have the luxury to slice and dice
business transactions in unrelated one-way and call backs.
"BPEL" does a much better job than BPML at relating the
collaboration operations to the private process. Typically this happens by a:
receive-flow-reply sequence where the receive and reply point to the same
operation (e.g. a request/response operation). In BPML you have to design
a "sub-process" to do just that.
The control flow of BPEL is also better than the one of BPML. However, I
remain convinced that the control flow must be "plug-able" certain
fields or applications of BPM technologies might require specific control flow
BPEL is now ahead of BPML in expressivity and completeness. In particular I
have argued in a prior analysis, that BPML is designed really to model
"units of work" rather than business processes. BPEL is designed to
be able to deal with business process models though it remains fairly
"centric" and would not enable an arbitrary message exchange between
two partners to be simply "observed" by the process engine rather than
controlled. (see a
paper I wrote).
Since BPML does not offer and does not want to offer any differentiator
compared to BPEL, it is likely that most process engine vendors will adopt
BPEL rather than BPML (Vitria and Webmethods have already rushed to announce
their support for BPEL). What is happening was inevitable in the context of web
services and what is at stake for Microsoft and IBM. A big absentee in this
furious battle ... Oracle.
Like BPML, BPEL does not deal with user interactions, just as if
there weren't any worker left in a company that would influence the course of
process, or help deal with an exception. I view this as a severe limitation of
the web services approaches.
IBM has already released a
to execute BPEL process definitions - nice !
The realm of business process modeling is complex and the many attempts
developed in the past ten years have failed to capture all (and numerous)
semantics necessary to model real-world scenarios. BPEL is no exception. It
goes barely beyond the level of BPML, i.e. a framework to specify web service
compositions. BPEL like BPML and its ancestors XLang and WSFL gets lost in the
intricacies of WSDL. Hopefully someone in the web services group will finally
see the light soon and discover that if you forget for one moment the API and
focus on the message exchange between two roles, one can greatly simplify the
definition of collaborations and executable processes.
BEPL will benefit from the marketing machines of
Microsoft and IBM, probably the two best one on earth and therefore will become
the specification of choice. For that matter BPEL starts its life with an
engine developed by IBM and available to play with. What else could facilitate
This is what I wrote back in the summer of 2002 "It will be interesting to see how Oracle reacts to this. Oracle, IBM and
Microsoft are the only total infrastructure providers left (OS/DB/App
server/WS/EAI/B2B/... -of course Oracle does not sell an OS, but the database
does not use the OS primitives either!). In August they jumped in the band wagon
of WSCI. This sounds like an odd move considering what WSCI is and its place in
the ladder of "standards". I sure hope that the SUN's disease (react
to whatever Microsoft does) is not contagious because this is not how you build
a corporate strategy. I am expecting that Oracle should
probably support BPEL as part of its stack sooner or later." Well, 2 years
later...Oracle bought Collaxa, the historical BPEL vendor. Congratulations to
Edwin and his team, they made BPEL real ! Since then, SUN appears to have found
a cure and is also cooperating on Web Services standards, including BPEL.
Support for the specification