Dynamic e-Business Using BPEL4WS, WS-Coordination, WS-Transaction, and Conversation Support for Web Services
Santhosh Kumaran, Prabir Nandi
IBM T. J. Watson Research Center
Introduction
IBM, MS, and BEA have just announced a set of Web services standards for automating business processes on the Web: BPEL4WS for executable specification of business processes, WS-Coordination for specifying an extensible framework for the coordination of actions of distributed applications, and WS-Transaction for coordination types that are used with the framework described in WS-Coordination. Additionally, IBM is making available through alphaWorks a technology called “Conversation Support for Web Services” for supporting conversational model of interaction between distributed, autonomous systems. The goal of this document is to articulate a vision in which these complementary technologies work together enabling dynamic e-Business.
We begin with a very brief overview of the technologies. Then we introduce a travel reservation scenario and use various levels of sophistication of this scenario to motivate the use of various technologies. We conclude with a summary of the complementary features that the conversation model brings to the table.
Technology Overview
This section briefly discusses the various technologies covered in this paper.
BPEL4WS
BPEL4WS [3] is a significant step towards building platform-independent, distributed, flexible business process applications. It specifies an XML-based language for specifying the flow logic of business processes as a set of activities and the control dependencies between these activities. A BPEL4WS process externalizes its functionality as Web Services and makes use of other Web Services to deliver this functionality.
Web Services Coordination & Web Services Transaction
WS-Coordination [6] describes an extensible framework for providing protocols that coordinate the actions of distributed applications. Using WS-C, distributed applications operating in a heterogeneous environment can (1) create a context needed to propagate an activity to other services and (2) register for coordination protocols.
WS-Transaction [5] specification describes two coordination types, Atomic Transaction (AT) and Business Activity (BA), which are used with the extensible coordination framework described in the WS-Coordination specification. A coordination type specifies a set of coordination behaviors. The coordination type “Atomic Transaction” (AT) is used to coordinate activities having a short duration. The coordination type Business Activity (BA) is used to coordinate activities that are long in duration and desire to apply business logic to handle business exceptions.
Conversational Support for Web Services
Conversation Support for Web Services (CS-WS) proposes a set of specifications to support a conversational model of component integration using Web Services [1]. The specifications include a XML dialect to describe a conversation interaction, called Conversation Policy (CP). CP’s are preprogrammed interaction patterns or protocols and is used to specify the message formats, sequencing constraints, and timing constraints that define the interaction protocol. The other set of specification extends the Java Connector Architecture API’s, both at the system and application level to provide a standard runtime framework to execute CP’s on a J2EE Application Server.
Technology Usage
We use the all-too-familiar Travel Reservation scenario to illustrate how these new technologies ease the development of dynamic eBusiness systems. We introduce the scenario at various levels of sophistication. We begin with a simple scenario where the existing WS technology stack (WSDL, UDDI, SOAP) is sufficient. Next, we introduce additional requirements that demand the use of BPEL4WS, WS-C and WS-T. Finally, the role that Conversations could play in conjunction with the other technologies is discussed.
Travel Reservation Scenario: Stage 1
Acme Travel enters Web service era by offering a network-accessible service for sending travel reservation request. The service is defined using WSDL, published in UDDI, and has an associated SOAP binding. The customers’ IT systems can integrate with Acme by accessing this service programmatically from their business applications.
The implementation of this service merely stores the request in a database and sends an alert to the appropriate employees of the company. The employees perform the necessary steps for completing the reservation and e-mails the e-tickets to the customer.
Travel Reservation Scenario: Stage 2
Acme adds support for process automation and partner integration by having a BPEL engine in their IT infrastructure and having a BPEL process to automate the long running transaction. The BPEL process provides the implementation of the Web service that Acme exposes to the customers. BPEL adds integration with its airline, rental car, and hotel partners by invoking Web services provided by them and by making Web services for them to access Acme systems. The core BPEL reservation process makes all this possible. An instance of the process is created upon receipt of a reservation request. The process coordinates various activities involved in completing a travel reservation. This includes invoking services provided by airline, car rental, and hotel companies, storing information in appropriate data containers, handling exceptions, and invoking compensations if necessary.
Travel Reservation Scenario: Stage 3
Acme’s business process integration using BPEL4WS is a resounding success leading to an explosion in its business. This led to several interesting developments.
Acme found that travel booking through Web Services is not a one shot deal for many customers. Customers enter an iterative bargaining exchange in which they submit a request, look at the prices they are getting for the original requests, make adjustments for a better deal and resubmit the request and so on. Essentially there is a conversation going on between the customer and the travel agency. Acme could still use the core BPEL4WS processes for process automation, but it needed another module in the edge to converse with the customer. That module will look at a message that Acme received from the customer, parse the message header, and based on the conversation state and the header information, pass it to an appropriate handler. That handler then will send the message to the right BPEL4WS process. That module will work as a BPEL4WS process broker. Acme wants that module to be realized in a flexible manner much like BPEL4WS has made its business process applications extremely flexible.
Conversation Support for Web Services provides the technology to build that module in a flexible manner, complementing BPEL4WS.
Acme noticed that some of its business partners constantly change their Web services interface. This meant that the port types that Acme uses to connect to these partners would change as well. Acme itself finds the need to change the port type occasionally. In the connected world of Web services, any such change is problematic. What Acme and its partners wanted is a mechanism to introduce such changes in a non-intrusive manner. Essentially, they would like to expose their Web service to each other without the tight coupling to a type. The interfaces they expose to each other merely specify a message header and a generic message body. If a business partner changes the format of the message they send to Acme, they will also make available a downloadable “policy” and associated handler for receiving, parsing, and reformatting the new message format. Acme’s conversation module receives the new message using its existing interface, downloads the new policy, and handles the change gracefully. Other partners can continue to use the old formats.
Conversation Support for Web services provides the mechanism for adaptable and extensible B2B integration, complementing BPEL4WS.
Another impact of Acme’s success with BPEL4WS is that many more of its partners (car rental companies, airlines, hotel chains, etc.) want to integrate with its internal processes via Web Services. But these partners use different business protocols though the core internal processes are the same. Acme needs a module that the core BPEL4WS process can invoke, and this module will have the capability to select the appropriate business protocol based on the target partner, format the message based on the selected protocol and manage the conversation with the partner to execute the protocol.
Conversation Support for Web Services provides the technology to build that module in an incremental manner, complementing BPEL4WS.
Acme adds seasonal promotion packages routinely. For example, it offers a Super Bowl package with tickets to the game, parties, and other festivities on top of the regular air/car/hotel reservations. This changes the business protocol. Acme needs a mechanism to extend its existing business protocols and compose new protocols by protocol nesting. Super Bowl ticket request is nested inside the regular request, and request for restaurant reservations are nested inside Super Bowl reservation request and so on.
Conversation Support for Web services provides an open-ended mechanism to realize nested, composable protocols that complement BPEL4WS.
Customers are finicky. It is not that Acme didn’t know this before, but with the automated system this became a real problem. The customer will send a new request, change it before the booking is complete, change it after the booking, cancel parts of it, may not use the ticket at all, and send for refund, etc. Sometimes, it is cyclical, iterating several times before a transaction is completed and archived. Acme found it useful to have the message exchanges with the customer handled as a session from the very beginning till the end, explicitly maintain the state of the conversation, and act on the message based on the state and message content. BPEL4WS provided the process automation capability while the conversation module handled the stateful message exchange with the customer.
Conversation Support for Web services provides the capability to drive a stateful message exchange session with the customer while complementing BPEL4WS.
Application Hierarchy
Leymann and Roller discuss “process-based applications” in [6]. They showed the benefits of an application structure with two layers. The bottom layer is made up of functional components while the top layer consists the flow logic of the application. There are several software engineering benefits to this approach, most notably the flexibility in accommodating changes to the application due to the decoupling of the functional modules from the flow logic that brokers these modules. Another important benefit is the ease of development as these layers can be developed and tested independently. It is best to think of the top layer as the “component broker” layer as the flow logic in this layer is brokering the components in the bottom layer to deliver overall application functionality.
The conversation model takes this approach to the next level by introducing another layer on top of the flow logic. This is the “process broker” layer as it brokers the processes defined in the middle layer to deliver new functionality. This layer is especially useful when building distributed applications that connect autonomous entities. The process broker maintains a conversation state independent of process state and brokers the messages based on the conversation state. Process broker executes modular business protocols.
Figure 1 shows the new application structure. The bottom layer in expressed via WSDL, the middle layer is expressed in BPEL, and the top layer is expressed via Conversation Policies.
Figure 1: Application Hierarchy
Figure 2 shows the runtime picture. Conversation support and BPEL support are plug-ins in a J2EE application server such as WebSphere. Conversation support is being positioned as a future J2EE extension for building conversational JCA adapters. Conversation policies are XML documents that configure these adapters. WSIF (Web Services Invocation Framework) is a framework that can be used in conjunction with the WebSphere Application Server for invoking Web services independent of a specific binding to a transportation protocol. WSIF supports bindings for several commonly used transportation protocols.
Figure 2: Conversation support in Web Services complement BPEL4WS
Summary
BPEL4WS, WS-Coordination, and WS-Transaction, along with WSDL and UDDI, provide the basis for the programming model for dynamic e-Business. Below we summarize the significant and complementary features that Conversations bring to this model as explained in Travel Reservation Scenario: Stage 3:
2. Adaptable, open-ended, and extensible B2B integration capability as demonstrated in the ability of the conversation module to account for interface changes.
3. Conversation module serves as a process broker layer dealing with multiple business protocols that the partners employ to provide the business services the BPEL processes expect. For example, different car companies may have different protocols for making a reservation; the conversation module supports the selection of the right protocol while utilizing the same BPEL processes.
4. Message handling based on explicit conversation state. A very good example is shown in the travel reservation example, in which there could be several loops and state changes at the conversation level before a transaction is completed.
5. Executable business protocols, nested protocols, and protocol switching as demonstrated in the travel scenario.
References
Conversation Support for Business Process Integration, James E. Hanson, Prabir Nandi, and Santhosh Kumaran, The 6th International Enterprise Distributed Object Computing (EDOC'02 - Sep 17-20, 2002, Ecole Polytechnic, Switzerland)
2. Conversation-enabled Web Services for Agents and e-business, James E. Hanson, Prabir Nandi, and David W. Levine, Proceedings of the International Conference on Internet Computing (IC-02), CSREA Press, 2002, pp.791-796.
3. Business Process Execution Language for Web Services Specification
4. Web Services Coordination Specification