Automating business processes and transactions in web services

An introduction to BPELWS, WS-Coordination, and WS-Transaction

The new Business Process Execution Language for Web Services, WS-Transaction, and WS-Coordination specifications provide a comprehensive business process automation framework that allows companies to leverage the power and benefits of the Web Services Architecture to create and automate business transactions. Here we present a high level executive overview of what the three new specifications provide.

Share:

James Snell (jasnell@us.ibm.com)IBM Emerging Technologies

James Snell is a member of the emerging Internet technologies team within IBM's software group, where he plays an active role in the evolving architecture and implementation of Web services technologies. He is a coauthor of the book Programming Web Services with SOAP, published by O'Reilly & Associates. James can be reached at jasnell@us.ibm.com.



01 August 2002

Also available in Japanese

The role of dynamic e-business within the enterprise is to simplify the integration of business and application processes across technological and corporate domains. The relatively recent advent of web service technologies such as SOAP, WSDL, and UDDI has helped to evolve our thinking about how distributed applications can connect and work together in an increasingly dynamic way, yielding a more dynamic economic environment.

None of these core web service specifications (SOAP, WSDL, UDDI, etc) were designed to provide mechanisms by themselves for describing how individual web services can be connected to create reliable and dependable business solutions with the appropriate level of complexity. The technology industry has not yet produced a single standardized web services view of how to define and implement business processes so that such connections can be described. To address the concerns and needs of our customers, IBM again teamed with Microsoft and others to develop and propose a Business Process Execution Language for Web Services, a new specification that replaces and offers additional functionality and greater flexibility over previous individual efforts on the IBM Web Services Flow Language (WSFL) and Microsoft XLANG grammar.

The Business Process Execution Language for Web Services (BPEL4WS or BPEL for short) is a XML-based workflow definition language that allows businesses to describe sophisticated business processes that can both consume and provide web services. In this document we will introduce the fundamental principles of BPEL as well as two significant and complementary specifications, WS-Coordination and WS-Transaction, also developed jointly by IBM and Microsoft. These deal with how one coordinates the dependable outcome of both short- and long-running- business activities. This issue is central to the successful implementation of a distributed business process.

To illustrate the function and benefits of the BPEL, WS-Transaction, and WS-Coordination specifications, we will explore the application of those technologies to a real-world business scenario.

The challenge

Acme Travel Service is a fictitious travel agency that has decided to offer its customers the benefit of planning and reserving travel arrangements through a Web based application. As part of this application, Acme recognizes that the ability to allow business partners and customers programmatic access their services through a web services interface -- thereby allowing the customer or partner to loosely integrate Acme Travel's services into their business travel processes -- will give them a significant strategic advantage and help them to streamline their business.

Acme Travel is trying to achieve three key goals through the development and deployment of their web services:

  1. Allow customers to submit travel itineraries to Acme Travel agents,
  2. Automatically procure appropriate airline, hotel and vehicle reservations for customer itineraries, and
  3. Automatically return confirmation on all reservations back to the customer once processing of the itinerary is complete.

Acme Travel realizes that in order for this solution to work, however, it must have a way to integrate its itinerary processing workflow with those of the airlines, hotels and car rental companies with which it does business. This fact highlights several distinct challenges.

  • Acme Travel must have a way to connect the customer-facing web service it wants to externalize with the business process it wishes to automate and integrate with its business partners.
  • Each partner must externalize a means of allowing Acme Travel to directly integrate its business processes into the partner's reservation system.
  • Acme Travel must be able to ensure the reliability and dependability of the entire process.
  • Acme Travel must be able to coordinate the activities of each individual partner in order to properly ensure that the customer's itinerary is satisfactorily processed.

The basic process Acme Travel is looking to implement is illustrated in Figure 1.Figure 1: Reservation Process Flow

  1. Acme Travel receives an itinerary from Karla, the customer.
  2. After checking the itinerary for errors, the process determines which reservations to make, sending simultaneous requests to the appropriate airline, hotel and car rental agencies to make the appropriate reservations.
  3. If any of the three reservation tasks fails, the itinerary is cancelled by performing the "compensate" activity and Karla is notified of the problem.
  4. Acme Travel waits for confirmation of the three reservation requests.
  5. Upon receipt of confirmation, Acme Travel notifies Karla of the successful completion of the process and sends her the reservation confirmation numbers and the final itinerary details.
  6. Once Karla is notified of either the success or failure of her requested itinerary, she may submit another travel request.

The process itself is not very surprising and not very complex. The challenge comes, however, not in the definition of such a process, but in the implementation -- particularly when dealing with multiple independent business partners, all of whom may implement their part of the process with potentially incompatible technologies and with different business requirements. By applying BPEL, WS-Coordination and WS-Transaction to the problem however, the solution to this challenge becomes clear.

The solution
Business Process Execution Language, Web Services Coordination, and Web Services Transaction specifications published by IBM and Microsoft provide the mechanisms that allow Acme Travel to achieve its goals by providing the means to:

  • define how to integrate the reservation services of the airline, hotel and car rental partners into its business process
  • define how specific activities of a business process can be externalized publicly as web services. (Waiting for a customer itinerary, for example.)
  • coordinate the activity of multiple web services within the overall business transaction.
  • dynamically link to services from multiple providers at runtime based on data derived from the process flow itself (which airline the customer wishes to use, which car rental company, and so on).

This solution makes the assumption that each airline, hotel and car rental agency with which Acme Travel deals has externalized its reservation system as a web service.

Step 1: Defining the business process
The first step for Acme Travel is to define and document the business process they will be implementing. The Business Process Execution Language provides an XML grammar that allows Acme Travel to create an abstract description of the itinerary reservation process.

One of the key differentiators of BPEL over other web services based process coordination specifications is that BPEL documents are executable scripts that can be interpreted by business process engines to implement the described process. Each step in the process corresponds to a single business activity. Each activity is implemented as an interaction with a web service provided either by Acme Travel or by one of its business partners. There are some portions of that script that need to be externalized to allow information to flow into the process and trigger various actions -- receiving the itinerary from the customer, for instance, or notifying the customer that the reservations have been made. Those portions of the script are externalized as web services. A business process execution engine that understands BPEL will provide the resources to make all of this happen. Acme Travel's developers will need only to define the process, provide the business logic for each activity and tell the engine how to locate the web services of the business partners and customers who interact with the process.

Step 2: Coordination and transactions
Once the business process and the connections with business partners have been defined, the next step is to provide a mechanism to coordinate all the activities involved in the Acme Travel business process so that a dependable outcome can be generated . There are several different distinct tasks that must be successfully completed, some of which run simultaneously, and Acme Travel has to be sure that all succeed or fail as a whole.

Distributed, long-running business transactions have always been difficult problems to solve. Aside from the basic technical questions, the extended duration and communication latency introduced by a collection of business tasks performed by different business partners running potentially incompatible software infrastructures introduces complex requirements. Transactions such as the process Acme Travel wants to put into place must be controlled on a task-by-task basis, with the infrastructure monitoring and managing the results of each individual activity as it relates to the entire process. Traditional transaction and coordination frameworks are best suited for managing an individual business task.

Another challenge is that of directly connecting together existing proprietary transaction service implementations. Most such products simply do not work together "out-of-the-box". Web services help to build a bridge between those products by providing a common framework through which divergent platforms can be integrated.

The WS-Coordination and WS-Transaction specifications complement BPEL in that they provide a web services-based approach to improving the dependability of automated, long running business transactions in an extensible, interoperable way.

The way that it works is straightforward. The Acme Travel business process involves a number of web services working together to provide a common solution. Each of those services needs to be able to coordinate their activities in order for the process to succeed. Coordination occurs by having each web service share a bit of common information that can be used to link the individual activities to an overall process. The WS-Coordination specification defines a framework through which those services can work from a shared "coordination context". That context contains the information necessary to link the various activities.

WS-Transaction, on the other hand, provides a framework that allows Acme Travel travel to monitor the success or failure of each individual, coordinated activity. It provides the means for Acme Travel to monitor the reservation process and reliably cancel the process in case something goes wrong along the way. In this instance, "reliably" means that if any part of an itinerary cannot be processed, no part of the itinerary is processed, or, if part of the itinerary has already been processed (for example, airline tickets have already been reserved), the work performed can be compensated for and undone. The fact that WS-Transaction is based on web services means that transaction support can be made interoperable across vendor-specific transaction management applications.

The benefits
The business process, coordination, and transaction management model being proposed helps customers to recognize several key benefits.

  • It is built on top of the web services architecture. Web services allow applications running on different, potentially incompatible runtime platforms to integrate and interact with one another in a flexible, dynamic way. By extending on this base, BPEL, WS-Coordination, and WS-Transaction help business streamline the integration process and implement more flexible business processes.
  • It is extensible. BPEL, WS-Coordination, and WS-Transaction, at their core, provide a general framework for how business process can be implemented but leave plenty of room for businesses to extend and customize the details to meet evolving business requirements . This allows the tools to evolve as business requirements evolve, thereby saving long-term development costs as your needs change.
  • It is flexible. The framework introduced by BPEL, WS-Coordination, and WS-Transaction provides support for a broad spectrum of transactional and non-transaction business processes.
  • It enables durable and reliable processing. The WS-Transaction specification provides the means to monitor the reliability of each individual task that must be completed in a larger process. The BPEL specification, meanwhile, provides the means to define how failed tasks can be compensated for.

On a business level, BPEL, WS-Coordination, and WS-Transaction help Acme Travel to achieve all of their goals in a way that allows them to easily integrate their business activities with those of their partners and customers without regard to the specific development or runtime platform each party has chosen to utilize. This allows Acme Travel -- and their partners -- to focus on what really counts: the business solution.

Finally, we've presented some very simple examples here to give you an idea of some of what the three specifications can provide. In real business life, there are more details and options and we might have nested business processes or even coordinated transactions within other coordinated transactions. BPEL, WS-Coordination, and WS-Transaction are designed to handle all these levels of complexity in a consistent way that builds upon and augments the rest of the web services standards stack.


Summary

IBM is committed to working with our customers, our partners, standards organizations and with the industry in general to further develop this architecture. As this work continues, technology previews will be released, starting with the IBM Web Services ToolKit for dynamic e-business and the IBM Business Process Execution Language for Web Services Java Runtime, both available through IBM alphaWorks. These technologies will allow developers to get early hands-on experience with the new specifications.

Resources

Comments

developerWorks: Sign in

Required fields are indicated with an asterisk (*).


Need an IBM ID?
Forgot your IBM ID?


Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.

 


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name



The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.

 


All information submitted is secure.

Dig deeper into SOA and web services on developerWorks


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=SOA and web services
ArticleID=11689
ArticleTitle=Automating business processes and transactions in web services
publish-date=08012002