Search for

   

  Web

 ebpml.org  

 

 

 

 

 

 

 

 

 

 

RSS source 

 

 

Disclaimer: The views expressed in this analysis only reflects the views of the author and not necessarily the one of his company.

Updates:

  • 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.

 

This page provide an analysis on BPEL4WS 1.0, it is so close to the new version (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 original concepts.

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 all going.

See my comment on "Where is BPEL 2.0 going?"

 

Release notes

v1.0.0 09/15/02 First version

v1.0.1 11/22/02 Added some comments about transformation, the "partner" attribute, and timeouts

v1.0.2 12/6/02 Added IBM's discussion forum on BPEL4WS 

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 content

 

General Remarks

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 Concepts 

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 (ebXML BPSS). 

Business Protocol: "Specify the mutually visible message exchange behavior of each of the parties involved in the protocol, without revealing their internal behavior"

Business Process

  •  Executable: "Executable business processes model actual behavior of a participant in a business interaction"

  •  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 this interface.

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.

Dependencies

WSDL 1.1, XML Schema 1.0, and XPath1.0.

BPEL Metamodel

A process definition is made of one activity, a series of partners and containers with specific correlation sets, the definition of fault handlers and compensation handlers.

An activity is itself decomposed in various elements 

Control flow

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 target activity".

"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, receive activities and pick activities) can be annotated to indicate that the occurrence of that activity causes a new instance of the business process to be created."

"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 terminates abnormally.

  • 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 "yes"."

I could not find any reference to a process composition (and the notion of sub-process). 

Message flow

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.

Data flow

"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.

	    <assign>
               <copy>
                  <from container="PO" part="customerInfo"/>
                  <to container="shippingRequest" 
                      part="customerInfo"/>
               </copy>
            </assign>

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.

Transaction flow

"There is a long history of work in this area regarding the use of Sagas [10] and open nested transactions [11]. 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 depth."

Extensibility 

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 following syntax:

<extension namespace="anyURI"/>

Collaboration specification

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 as follows:

 
<serviceLinkType name="BuyerSellerLink"
        xmlns="http://schemas.xmlsoap.org/ws/2002/07/service-link/">
  <role name="Buyer">
    <portType name="buy:BuyerPortType"/>
  </role>
  <role name="Seller">
    <portType name="sell:SellerPortType"/>
  </role>
</serviceLinkType>

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 happen??). 

Yuck

<receive partner="shippingProvider" portType="lns:shippingCallbackPT" operation="sendSchedule" container="shippingSchedule"> <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. 

Commentary

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 specifications.

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 toolkit to execute BPEL process definitions - nice ! 

Conclusion

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 its adoption? 

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.

Jean-Jacques Dubray

References

Support for the specification

 

Hit Counter