BPEL

Originally termed BPEL4WS (Business Process Execution Language for Web Services), BPEL was created in 2002 by IBM, Microsoft and BEA and taken to OASIS for standardization at approximately the same time that the WSCI was going through the W3C. The vendors' choice of OASIS was probably a reaction to the demand by the W3C that all patents should be royalty-free. BPEL extends programming languages by providing ways in which they may work together but its primary concern is with business processes. It has inherited some features from its forerunner, BPML (Business Process Management Language). Verner [2004] describes both systems as being built on the π calculus³³. Version 2.0, renamed as WS-BPEL but not

significantly different from its earlier version, was released in 2004 by OASIS.

The BPEL specification argues compellingly for the necessity of a meta-level integration standard above web services which will enable the exciting and dynamic service interactions so far available only in science-fiction:

Systems integration requires more than the ability to conduct simple interactions by using standard protocols. The full potential of Web Services as an integration platform will be achieved only when applications and business processes are able to integrate their complex interactions by using a standard process integration model [Andrews et al., 2003].

33 A process algebra, developed by Hoare and Milner. See Pucella, 2001.

One of the differences between this kind of model and web services is that the former needs to be stateful in order to keep track of message sequences and process interactions. BPEL is proposed partly as a solution to the problem of maintaining state – in fact state maintenance is mentioned throughout as crucial. BPEL aims to specify the "visible message exchange behavior of each of the parties involved in the protocol, without revealing their internal implementation" [Andrews et al., 2003]. BPEL offers itself both as a "model" for business interactions and as a "grammar" to define them. It seeks to create relationships, but in doing so it may be returning to an earlier model and obscuring the loosely-coupled nature of web-service interactions in which it is the messages, not the participants, which are defined.

While WSCI uses WSDL, the role of BPEL is to attempt to extend WSDL. Like WSCI, BPEL builds upon the WSDL definition of operations, but BPEL attempts to organize their sequence, without making any assumptions about the messaging technology (e.g. SOAP) that will be used.

Its focus is on the abstract sections of WSDL, not the concrete ones in which the bindings are made, although it also, separately, describes executable business processes.

Figure 6-2: Schematic of a BPEL Process for Handling a Purchase Order [Andrews et al., 2003]

The BPEL specification gives an example of a BPEL process in terms of the handling of a purchase order, as illustrated in Figure 6-2, in which the dotted lines "represent sequencing", the grouping (shown here in the yellow rectangle) represents a concurrent sequence, and the two

solid arrows represent data dependencies which arise from the necessity of determining both the shipping price, before a final price calculation may be achieved, and shipping data, before the production schedule can be finalized. In the WSDL document used by this service, these operations are embraced in the abstract by a number of port types or interfaces. BPEL then extends WSDL by introducing a number of extensible elements, the most significant of which for this discussion are PartnerLinks (defining the role and the functionality that must be provided by whoever assumes the role) and variables elements (for maintaining state).

Defining roles and maintaining state is all too reminiscent of object-oriented middleware. As if that were not enough, the specification continues: "Finally, it is important to observe how an assignment activity is used to transfer information between data variables. The simple

assignments shown in this example transfer a message part from a source variable to a message part in a target variable" [Andrews et al., 2003] and goes on to describe "switch" and "while"

elements. The language appears to concern messages but the concepts are closer to programmatic code sequences.

BPEL's focus on the functionality of the role is a key difference between it and WSCI. Where BPEL sees roles, WSCI sees messages. Where BPEL sees hierarchy, employing a central process "engine" controlled by one of the players, WSCI sees equals. BPEL is concerned with constructing a "fractal-like" [Verner, 2004] meta-service out of smaller services, whereas WSCI is more about services collaborating with each other. BPEL and WSCI are not necessarily competing technologies in that they each deal with different aspects of web-service coordination, but of the two, WSCI seems closer in spirit to the aims of web services.

The weaknesses of BPEL according to Verner, are that it "addresses only processes composed exclusively of Web services" (one of the strengths of web services is that it provides the possibility of incorporating legacy systems), that its processes cannot be rendered graphically, that its design cannot be performed in a top-down fashion, that a BPEL process cannot be

analyzed, and, most tellingly, that it is "a vendor-driven process definitions language that has not yet been reflected in a royalty-free standard published by a recognized standards group" [2004].