![Close [x]](http://dw1.s81c.com/i/c.gif){kind=small}
IBM, Microsoft, and BEA have just announced a set of web services standards for automating business processes on the Web:
- Business Process Execution Language for Web Services (BPEL4WS), for executable specification of business processes
- WS-Coordination (WS-C), for specifying an extensible framework for the coordination of actions of distributed applications
- WS-Transaction (WS-T), for coordination types that are used with the framework described in WS-Coordination
In addition, IBM is making available through alphaWorks a technology called Conversation Support for Web Services (CS-WS) for supporting a conversational model of interaction between distributed, autonomous systems. The goal of this article is to articulate a vision in which these complementary technologies work together to enable dynamic e-business. Once you've finished here, you'll understand the sorts of problems that this emerging technology is meant to address, and you'll be ready to download the CS-WS package from alphaWorks and start to explore its code. The Resources section below contains links to this package as well as other offsite materials referenced in this article.
We begin with a very brief overview of the technologies pertinent to our discussion. Then we introduce a travel reservation scenario, and see how the technologies we'll discuss here can be used to build web services of various levels of sophistication. We conclude with a summary of the complementary features that the conversation model brings to the table.
In this section, we'll briefly discuss the various technologies covered in this paper. See Resources below for more detailed information on all of these technologies.
BPEL4WS is a significant step towards building platform-independent, distributed, flexible business-process applications. It establishes an XML-based language for specifying the flow logic of business processes as a set of activities and the control dependencies between those activities. A BPEL4WS process externalizes its functionality as web services and makes use of other web services to deliver this functionality.
WS-Coordination describes an extensible framework for providing protocols that coordinate the actions of distributed applications. Using WS-Coordination, distributed applications operating in a heterogeneous environment can create the context needed to propagate an activity to other services and register for coordination protocols.
The WS-Transaction specification describes two coordination types, one called atomic transaction (AT) and the other called business activity (BA). Both are used with the extensible coordination framework described in the WS-Coordination specification. A coordination type specifies a set of coordination behaviors. Atomic transactions are used to coordinate activities having a short duration, while business activities are used to coordinate activities that are long in duration and that involve the application of 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. (See Resources below for more conversational models.) The specifications include an XML dialect to describe a conversation interaction, called Conversation Policy (CP). CPs are preprogrammed interaction patterns or protocols and are used to specify the message formats, sequencing constraints, and timing constraints that define the interaction protocol. The other specifications in the set extend the Java Connector Architecture APIs, both at the system and application level, to provide a standard runtime framework to execute CPs on a J2EE application server.
As mentioned earlier, a prototype implementation of CS-WS is available from IBM's alphaWorks site; see Resources for a link.
Technology usage: A real-world example
We'll use the familiar travel reservation scenario to illustrate how these new technologies ease the development of dynamic e-business systems. We'll describe how the technologies we're considering can be used to build web services of various levels of sophistication. We begin with a simple scenario for which 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, we discuss the role that conversations could play in conjunction with all these other technologies.
Stage 1: Using the standard web services stack
Acme Travel enters the web services era by offering a network-accessible service for sending travel reservation requests. The service is defined using WSDL, published in UDDI, and has an associated SOAP binding. 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 Acme Travel personnel. These Acme employees perform the necessary steps for completing the reservation and e-mail the electronic tickets to the customer.
Stage 2: Adding process automation and partner integration
Now let's see what happens when Acme adds support for process automation and partner integration by adding a BPEL engine to its IT infrastructure and a BPEL process to automate a long-running transaction. This BPEL process provides the implementation of the web service that Acme exposes to its customers. BPEL adds integration with its airline, rental car, and hotel partners by invoking web services provided by them, and by having Acme's partners invoke Acme's web services when appropriate.
The core BPEL reservation process makes all of this possible. An instance of the process is created upon receipt of a reservation request. The process coordinates the various activities involved in completing a single 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.
Stage 3: Adding conversation support
Acme's business process integration using BPEL4WS has now become a resounding success, leading to an explosion in Acme's business. This has led to several interesting developments, which we'll consider in the following sections.
Conversations ease iterative processes
Acme has found that booking travel through a web service is not a one-shot deal for many customers. Customers enter into an iterative bargaining exchange during which they submit a request, look at the price they are quoted for that original request, make adjustments for a better deal, resubmit the request, and so on. Essentially, there is a conversation going on between the customer and the travel agency. Acme can still use the core BPEL4WS processes for process automation, but the company needs another module on the outside interface of the service to converse with the customer. That module will look at a message that Acme receives from a customer, parse the message header, and, based on the conversation state and the header information, pass it to an appropriate handler. That handler will in turn send the message to the right BPEL4WS process.
Our conversation module will work as a BPEL4WS process broker. Acme wants this module to be realized in a flexible manner, just as 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.
Conversations make service interface changes transparent
Acme has noticed that some of its business partners change their web services interfaces fairly often. This means that the port types that Acme uses to connect to these partners change as well. Acme itself needs to change its own port type occasionally. In the connected world of web services, any such change is problematic. What Acme and its partners want is a mechanism to introduce such changes in a nonintrusive manner. Essentially, they would like to expose their web services to each other without tightly coupling each service to a particular 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 it sends to Acme, it 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.
Conversations make it easy to work with multiple business protocols
Another impact of Acme's success with BPEL4WS is that many more of its partners (car rental companies, airlines, hotel chains, etc.) now want to integrate with Acme's internal processes via web services. But these partners use different business protocols, though their core internal processes are the same. Acme needs a module that the core BPEL4WS process can invoke, and this module should 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.
Conversations ease protocol nesting
Acme adds seasonal promotion packages routinely. For example, it offers a Super Bowl package with tickets to the game, parties, and other festivities in addition to the regular air, car, and hotel reservations. This changes the business protocol. Acme needs a mechanism to extend its existing business protocols and add new protocols by protocol nesting. A Super Bowl ticket request is nested inside the regular travel request, and a request for restaurant reservations is nested inside the 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.
Conversations can support stateful message exchange sessions
Customers are finicky. Of course, Acme already knew that, but once the company's automated system was in place, customer finickyness became a real problem. A customer would often send a new request, change it before the booking was complete, change it again after the booking, and cancel parts of it -- only to never use the ticket at all and request a refund instead. Sometimes, this process 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 single session from the very beginning till the end, explicitly maintaining the state of the conversation, and acting 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.
Where do conversations fit into an application hierarchy?
In a recent article (see Resources for a link), Frank Leymann and Dieter Roller discuss process-based applications. They discussed an application structure with two layers: the bottom layer is made up of functional components, while the top consists of the flow logic of the application. There are several software engineering benefits to this approach, most notably the flexibility to accommodate changes to the application due to the decoupling of the functional modules from the flow logic that brokers those modules. Another important benefit is 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 a third layer on top of the flow logic. This is called the process broker layer, as it brokers the processes defined in the component broker layer (which is now in the middle) to deliver new functionality. A process broker layer is especially useful in 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. The process broker executes modular business protocols.
Figure 1 shows this 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. Conversation support is being positioned as a future J2EE extension for building conversational JCA adapters. Conversation Policies, as noted above, are XML documents that configure these adapters. WSIF (Web Services Invocation Framework) is a framework that can be used in conjunction with the an 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
BPEL4WS, WS-Coordination, and WS-Transaction, along with WSDL and UDDI, provide the basis for the programming model for dynamic e-business. The significant and complementary features that conversations bring to this model, as illustrated in our example, include:
Dynamic and flexible interaction patterns, as shown by the ability of the conversation technology to support complex interactions between Acme and customers.
Adaptable, open-ended, and extensible B2B integration capability, as demonstrated by the ability of the conversation module to account for interface changes.
The addition of the conversation module 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 for each partner while utilizing the same BPEL processes.
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.
Executable business protocols, nested protocols, and protocol switching as demonstrated in the Super Bowl scenario.
Now that you have an idea of the sorts of problems that conversations can solve, you should check out the CS-WS package at alphaWorks. This is an emerging technology, so your input will be greatly appreciated.
- Download the prototype implementation of Conversation Support for Web Services from IBM alphaWorks
- IBM Research has some good resources on conversational models. The following papers (in PDF format) are of particular interest:
- "Conversation Support for Business Process Integration," James E. Hanson, Prabir Nandi, and Santhosh Kumaran (originally presented at the 6th International Enterprise Distributed Object Computing Conference, Sep 17-20, 2002, Ecole Polytechnic, Switzerland).
- "Conversation-Enabled Web Services for Agents and E-business," James E. Hanson, Prabir Nandi, and David W. Levine, (originally presented at the International Conference on Internet Computing, 2002).
- Check out the following specifications, hosted by developerWorks:
- Business Process Execution Language for Web Services
- Web Services Coordination
- Web Services Transaction
- For more on the workflow architecture described in this article, see "Workflow-based applications," Frank Leymann and Dieter Roller (IBM Systems Journal, 1997).
- For more on IBM's J2EE application server offering, check out the WebSphere developer domain.
Santhosh Kumaran is a researcher at IBM's T.J. Watson Research Center in New York, where he manages the e-commerce systems group. Contact Santhosh at sbk@us.ibm.com.
Prabir Nandi is a researcher in the e-commerce department of IBM's T.J. Watson Research Center in New York. Contact him at prabir@us.ibm.com.
Table of contents
Next steps from IBM
WebSphere Application Server can leverage its built in Web Services support to expose services to remote consumers in an industry-standard way.
- Try: The no-charge WebSphere Application Server Community Edition is a pre-integrated, lightweight Java 5 application server built on Apache Tomcat and includes built in Web Services support.
- Article: Learn how to use of the JAX-WS programming model to create dispatch and dynamic proxy clients and how to create an asynchronous Web service client.
- Tutorial: This tutorial takes you through the steps to deploy Data Web Services to the WebSphere Application Server Community Edition.
- Demo: This demo shows how to extract and install the IBM Java Platform, Java EE 5 SDK with WebSphere Application Server.
- Buy: WebSphere Application Server - Express
Tags
Use the slider bar to see more or fewer tags.
For articles in technology zones (such as Java technology, Linux, Open source, XML), Popular tags shows the top tags for all technology zones. For articles in product zones (such as Info Mgmt, Rational, WebSphere), Popular tags shows the top tags for just that product zone.
For articles in technology zones (such as Java technology, Linux, Open source, XML), My tags shows your tags for all technology zones. For articles in product zones (such as Info Mgmt, Rational, WebSphere), My tags shows your tags for just that product zone.
Popular article tags |
My article tagsSkip to tags list
Popular article tags |
My article tags
