In this paper, Prasad Yendluri, Principal Architect at webMethods, takes a closer look at the WSCI and the BPEL4WS specifications, and examines they approach Web services choreography from different paths and employ different models.
Introduction
The promise of Web services is centered around standard and interoperable means of integrating loosely coupled Web based components that expose well-defined interfaces, while abstracting the implementation and platform specific details. The current and more mature core Web services standards SOAP, WSDL and UDDI provide a solid foundation to accomplish this. However, these specifications primarily enable development of simple Web services. WSDL is very useful for describing interfaces offered by individual and indivisible Web services. Coupled with the SOAP protocol that supplies an XML based messaging framework, vendors today are able to build Web services applications that can conduct simple interactions.
The ultimate goal of Web Services however is to facilitate and automate business process collaborations both inside and outside enterprise boundaries. Useful business applications of Web services in business-business, business-to-consumer and enterprise application integration environments will require the ability to compose complex and distributed Web services integrations and the ability to describe the relationships between the constituent low-level services. Realization of collaborative business processes as Web services integrations and the description of dynamic interactions and flow of messages among Web services in the context of a process is known as Web services Choreography.
Web services choreography specifications pick up things from where WSDL ends. WSDL essentially permits definition of the static interface of a Web service. Operations in a WSDL portType (WSDL container construct for Web service interface definition) are grouped into a single interface but they are independent of one another and the WSDL grammar does not permit specification of any relation or required sequencing of operations within a portType. Hence the interaction model of a WSDL portType is stateless and static without any correlation of interactions at the interface defined. Additionally WSDL describes interfaces from the perspective of a Service (provider) and hence it is geared toward a client-server model of interaction. Collaborative process models typically involve both client-server and peer-to-peer type interactions with long running and stateful conversations involving two or more parties, which WSDL is just not equipped to deliver. Hence the Web services choreography specifications use WSDL as a basis and extend the WSDL functionality to the Web services choreography space.
Though there are several specifications in the industry that address collaborative process modeling two main specifications WSCI (Web Services Choreography Interface) and BPEL4WS (Business Process Execution Language for Web Services) are designed specifically for Web services based choreography. Other important industry efforts in the area of choreography languages include BPML (Business Process Modeling Language) defined by BPMI.org, BPSS (Business Process Schema Specification) defined by ebXML, XPDL (XML Processing Description Language) defined by the Workflow Management Coalition, WSFL (Web Services Flow Language) defined by IBM, and XLANG defined by Microsoft. Of these, the last two specifications WSFL and XLANG have now been declared obsolete by their originators in favor of their combined successor BPEL4WS. In this article we take a closer look at the WSCI and the BPEL4WS specifications. We will also compare these with some of the other specifications listed above.
WSCI
In June 2002, Intalio, Sun, BEA and SAP released a joint specification named Web Services Choreography Interface (WSCI), an XML based interface description language for Web services choreography. This specification was also submitted to W3C as a note in August 2002. W3C has since formed a new Working Group called Web Services Choreography Working Group within the Web services Activity. The WSCI specification is one of the primary inputs into the Web Services Choreography Working Group. WebMethods is also involved in this WG as an active member since its formation.
WSCI addresses Web services based choreography from two primary levels. At the first level, WSCI builds up on the WSDL portType capabilities to describe the flow of messages exchanged by a Web service in the context of a process. This however is still a one-sided description of the message exchange, purely from the point of view of the Web service’s own interface (portType). The construct introduced by WSCI permits description of the externally “observable behavior” of a Web service, facilitating the expression of sequential and logical dependencies of exchanges at different operations in WSDL portType. In addition to chronological and logical sequencing rules, correlation of related exchanges, grouping of exchanges into transactions, exception handling and such dynamic behavioral aspects of a Web service can be specified via the WSCI <interface> .
At the second level WSCI defines the construct, which allows composition of two or more WSCI definitions (of the respective Web services) into a collaborative process involving the participants represented by the Web services. WSCI calls this the “Global Model”. A WSCI Global Model provides the ability to “link” operations in different interfaces and specify the direction of message flow between the linked operations, into a collective message exchange among interacting Web services, providing a global, message-oriented view of the overall process based on Web services.
WSCI Global Model is very similar in concept to the “Global Model” defined in the Web Services Flow Language (WSFL). The concept of a WSCI is also similar to the concept of construct introduced by the Web Services Conversation Language (WSCL) defined by HP; though WSCI goes far beyond the capabilities of WSCL by supporting contexts, correlations, transactions and exception handling.
WSCI Interface
WSCI describes the behavior of a Web service in terms of choreographed “activities”. Activities may be atomic or complex. Atomic activities represent the basic unit of behavior of a Web service, such as sending or receiving a message, or waiting for a specified amount of time. Atomic activities dealing with messages correspond to the execution of operations defined in a portType of a WSDL. Atomic activities are also known as “Actions”.
Complex activities are recursively composed of other activities; ultimately, each complex activity is composed of actions. Each complex activity defines a specific kind of choreography for the activities it is composed of. WSCI supports the definition of the following kinds of choreographies:
- Sequential execution: The activities must be executed in sequential order.
- Parallel execution: All activities must be executed, but they may be executed in any order.
- Looping: The activities are repeatedly executed based on the evaluation of a condition or an expression. WSCI supports for-each, while, and repeat-until style loops.
- Conditional execution: One out of several sets of activities is executed based on the evaluation of conditions (switch) or based on the occurrence of an event (choice).
Example WSCI Interface
Shown below is the WSDL fragment that describes the portType definition of a Web service implementing the Travel Agent functionality in a Travel Reservation System.
<portType name = "TAtoTraveler">
<operation name = "OrderTrip">
<input message = "tns:tripOrderRequest"/>
<output message = "tns:tripOrderAcknowledgement"/>
</operation>
<operation name = "bookTickets">
<input message = "tns:bookingRequest"/>
<output message = "tns:bookingConfirmation"/>
</operation>
<operation name = "SendStatement">
<output message = "tns:statement"/>
< /operation>
</portType>
The following WSCI interface definition code fragment shows how WSCI enhances the portType definition of WSDL above to define a choreography on the operations in the portType (not all details are shown in the interest of brevity):
<interface name = "TravelAgent">
<process name = "PlanAndBookTrip">
< sequence>
<action name = "ReceiveTripOrder"
role = "tns:TravelAgent"
operation = "tns:TAtoTraveler/OrderTrip">
< /action>
<action name = "ReceiveConfirmation"
role = "tns:TravelAgent"
operation = "tns:TAtoTraveler/bookTickets">
</action>
<action name = "SendStatement"
role = "tns:TravelAgent"
operation = "tns:TAtoTraveler/SendStatement"/>
< /action>
</sequence>
</process>
< /interface>
This WSCI interface defines a process that requires the execution of three actions “ReceiveTripOrder”, “ReceiveConfirmation” and “SendStatement” to be executed in that sequence as implied by the listing of these activities in that order within a statement in the process. Each action is also mapped to the corresponding operation in the WSDL portType definition shown earlier. For instance, the “ReceiveTripOrder” action is mapped to the “OrderTrip” operation in the portType “TAtoTraveler” via the operation attribute of the action.
WSCI Global Models
As described previously WSCI Global Models permit linking of actions in two or more WSCI interfaces into a collaborative process model involving participants represented by the respective individual Web services interfaces. WSCI Global Model is useful for visual modeling, analysis, validation and simulation of the overall process.
The following fragment of XML shows the definition of the WSCI global model for a travel reservation process involving three separate and individual Web service interface definitions namely traveler.wsci, travelAgent.wsci (from previous example) and airline.wsci.
<wsdl:import namespace="http://example.com/consumer/traveler"
location= "http://example.com/traveler.wsci"/>
<wsdl:import namespace=" http://example.com/consumer/airline"
location= "http://example.com/airline.wsci"/>
< wsdl:import namespace=" http://example.com/consumer/travelagent"
location= "http://example.com/travelagent.wsci"/>
<model name = "AirlineTicketing">
<interface ref = "airline:Airline" />
<interface ref = "traveler:Traveler" />
<interface ref = "travelagent:TravelAgent" />
<!-- Traveler / TravelAgent -->
<connect operations = " traveler:TravelerToTA/PlaceItinerary
travelagent:TAtoTraveler/ReceiveTrip"/>
<!-- other connect elements -->
< /model>
BPEL4WS
Business Process Execution Language for Web Services BPEL4WS is a specification from BEA, IBM, and Microsoft that was made available in public domain in July 2002. Like WSCI, the BPEL4WS specification’s process model is also layered on top of the Web service interface model (portType) defined by the WSDL 1.1 specification. However unlike WSCI, BPEL4WS does not define choreography aspects at the individual Web service level as a separate choreographed interface definition. Accordingly BPEL4WS does not also define a “global model” that builds on the choreographed interfaces at the individual Web service level. Instead BPEL4WS references the respective portType names and the operations in a specific portType directly via their namespace qualified names.
At the core of the BPEL4WS process model is the peer-to-peer interaction between Web services interfaces defined in WSDL. All parties involved in a process are modeled as WSDL services interfaces. A BPEL4WS process definition provides and/or uses one or more WSDL portTypes. The interfaces the process provides are used by its partners and the interfaces used by the process are provided by its partners. Since the BPEL4WS process interactions are at the WSDL operations in portType level, they are at abstract interface level resulting in a reusable process definition that can be used in different deployment scenarios. This particular aspect is true for WSCI (global models) as well.
However, unlike WSCI that defines all choreography aspects within the context of individual Web services only and simply connects the interfaces at the global model (process) level, BPEL4WS defines the choreography aspects (e.g. flow of control) at the process level that involves two or more Web service interfaces. This process level choreography defines which parts of the process execute in parallel, which execute in sequence, conditional flow of control at different parts in the process, exceptions and compensations etc. Many of the BPEL4WS process level choreography constructs have parallels to constructs in block-structured languages. Since the BPEL4WS defines the executable behavior of a process, the logic and the state of the process determining the nature and sequence of interactions of the process with its partners, it supplies an executable process definition, though still based on abstract Web services interfaces. This executable business process model of BPEL4WS does not distinguish between “public” or externally visible aspects of a process and its internal workings.
Protocols such as business-to-business protocols however do not address internal workings (private aspects) of the process at each end of the interacting parties, but model the interactions of the process in terms of mutually visible message exchanges and behavior of the each party involved at the message interaction level. BPEL4WS refers to this type of process modeling involving the public behavior only, as the “abstract” process. This is analogous to the “global models” of WSCI though in BPEL4WS this is viewed at the abstraction level of a process that potentially encompasses more than one Web service interface, where as the WSCI global models are at the individual Web services level.
The abstract process modeling aspect of BPEL4WS is not very well defined in the current specification though BPEL4WS promises to deliver that in a future version of the specification. BPEL4WS does contain a service-link concept and the associated construct called that is used to link two (complementary) portTypes. However the abstract process aspects of BPEL4WS are not rich enough at this point to represent a RosettaNet PIP for example.
Shown below is an abbreviated version of the BPEL4WS executable process instance. Many details are skipped in the interest of brevity:
<process name="purchaseOrderProcess"
targetNamespace="http://acme.com/ws-bp/purchase"
xmlns="http://schemas.xmlsoap.org/ws/2002/07/business-process/"
xmlns:lns="http://manufacturing.org/wsdl/purchase">
<partners>
<partner name="customer" ServiceLinkType="lns:purchaseLT"
myRole="purchaseService"/>
<partner name="invoiceProvider" serviceLinkType="lns:invoiceLT"
myRole="invoiceRequester"/>
...
</partners>
<containers>
...
</containers>
<sequence>
<receive partner="customer" portType="lns:purchaseOrderPT"
operation="sendPurchaseOrder" container="PO"/>
<flow>
< sequence>
<assign>
<copy>
<from container="PO" part="customerInfo"/>
<to container="shippingRequest" part="customerInfo"/>
</copy>
< /assign>
<invoke partner="shippingProvider"
portType="lns:shippingPT"
operation="requestShipping"
inputContainer="shippingRequest"
outputContainer="shippingInfo"/>
<receive partner="shippingProvider"
portType="lns:shippingCallbackPT"
operation="sendSchedule"
container="shippingSchedule"/>
</sequence>
<sequence>
<invoke partner="invoiceProvider"
portType="lns:computePricePT"
operation="initiatePriceCalculation"
inputContainer="PO"/>
<invoke partner="invoiceProvider"
portType="lns:computePricePT"
operation="sendShippingPrice"
inputContainer="shippingInfo"/>
</sequence>
</flow>
<reply partner="customer"
portType="lns:purchaseOrderPT"
operation="sendPurchaseOrder"
container="Invoice"/>
</sequence>
< /process>
This executable process definition comprises a single top level structured activity. This top level comprises activity, a structured activity and a activity, all of which must be executed in the order in which they occur in the top level . The in turn contains two more s, which can be executed in parallel. The inner s contain other activities that must be executed in the sequence that they occur in the respective s. Notice that each of , and activities take place on a particular operation in a portType.
In May 2003 a new Technical Committee in OASIS called WS-BPEL TC was formed with a slightly updated version of the BPEL4WS specification (version 1.1) as the primary input into the TC. Work in this TC is in progress with active participation from a large number of stake-holder companies. webMethods is also involved in the TC since formation as one of the editors of the WS-BPEL technical specification.
The WS-BPEL TC in OASIS and WS-Choroegraphy Working Group in W3C have many of the same member companies and individual members from those companies, participating in both works. Both groups have also recently established formal liaisons with each other and are trying to work cooperatively. However there is a significant overlap in the nature of the problem domain that both groups are working to produce standard specifications for. Hence many vendors are eagerly awaiting and working towards a proper alignment here so that the industry does not end up with two competing specifications in the same space from two different organizations.
webMethods Flow Language
The visual “Flow” language defined by webMethods that had been in use on the webMethods integration platform since early versions of the Integration Server, already supplies many of the flow functionalities introduced in WSCI and BPEL4WS. This simple yet powerful language lets one encapsulate a number of services into a compound service and manage the flow of data among the services. The operations available in Flow extend far beyond what BPEL4WS or WSCI define. In addition to operations such as INVOKE, SEQUENCE, BRANCH, LOOP, REPEAT and EXIT that have equivalents in the other languages, webMethods Flow language provides sophisticated mapping (data transformation) capabilities.
Conclusion
Both WSCI and BPEL4WS approach Web services based choreography from different paths and employ different models: WSCI from individual Web service centric choreography model and BPEL4WS from an executable process model. However both lack a well-defined public process model that is essential for modeling business-to-business protocols. Additionally both specifications follow a bottom-up approach where choreographies are built-up from component Web services interfaces that exist in the form of WSDL definitions. However, it is also very useful and perhaps more natural to model business process collaborations at the business level in terms of messages that get exchanged between parties and generate the Web services and the respective interfaces that are needed to realize the higher level business process, in a top-down fashion.
It is also very desirable for at least these two specifications and others like BPML (that we have not discussed but still very relevant) to converge into a single and coherent specification that all vendors can uniformly embrace, lest the industry would end-up with non-interoperable islands of Web services choreography implementations.
webMethods has a long history of supporting open and leading-edge standards. We are closely monitoring all the emerging standards in the Web services choreography space. We have announced our supportive stance for the BPEL4WS specification as it unifies WSFL and XLANG. webMethods has always been standards-based, and we will continue to lead and support industry standards as they evolve and as customers demand them.
Download the 30-day FREE evaluation of the webMethods Integration Server, webMethods Developer, and webMethods Adapters.
More information at Webmethods.com
