SOA programming model for implementing Web services, Part 3: Process choreography and business state machines

One approach to service composition is to define services as business processes using Business Process Execution Language (BPEL) or represent them as business state machines. The mainline code orchestrating the invocations of a series of such services runs in a special container called a process choreography engine. Container-provided functions enable long-running process executions that can even span enterprise boundaries, survive planned and unplanned outages, and facilitate business-to-business (B2B) collaboration.

Share:

Matthias Kloppmann, Senior Technical Staff Member, IBM Software Group

Author photoMatthias Kloppmann is a Senior Technical Staff Member with IBM Software Group’s laboratory in Boeblingen, Germany. He is the lead architect for Business Process Choreography. Since Matthias joined IBM in 1986, he has worked on a variety of projects, focusing on the architecture of workflow systems and Web services. Matthias holds an M.Sc. in computer science and electrical engineering from the University of Stuttgart.



Donald Ferguson, Ph.D. (dff@us.ibm.com), Fellow, IBM 

Author photoDonald F. Ferguson, Ph.D. is one of 55 IBM Fellows, the highest technical position in the IBM engineering community of 200,000 technical professionals. Don is the Chief Architect and Technical Lead for the IBM Software Group family of products, which includes IBM Lotus, Rational, WebSphere, IBM DB2, and IBM Tivoli. Don chairs the SWG Architecture Board, bringing together the SWG's lead product architects. Don's most recent efforts have focused on Web services, business process management, client platform, outsourcing/hosting platform, Grid services, and application development for WebSphere. Don was the Chief Architect for the WebSphere family of products from their inception until assuming the role of SWG Chief Architect in 2003.



Marcia Stockton, Senior Technical Staff Member and Master Inventor, IBM Software Group

Author photoMarcia L. Stockton is a Senior Technical Staff Member and Master Inventor with IBM's Software Group in Research Triangle Park, North Carolina (residing in California), and a senior IEEE member. She leads the Software Group Architecture Board's Programming Model Workgroup, where she drives horizontal integration initiatives and promotes programming model simplification across Lotus, Rational, WebSphere, DB2 and Tivoli products. Her 73 filed U.S. patents range from networking, Web, security, privacy, multimedia, wireless, pervasive devices, to radio frequency identification (RFID). Recently she led efforts to define architectures for identity management and for edge server distributed programming. She joined IBM in 1988 as a networking software professional. She earned a B.A. from Swarthmore College in 1975.



12 July 2005

Also available in Vietnamese

This is the third in our series on the programming model for IBM's Service-Oriented Architecture (SOA). The previous articles introduced SOA programming model concepts and Service Data Objects.

Business processes

The notion of service orchestration through business process choreography would probably be familiar to a FORTRAN programmer from the 1970s. It?s simply the concept of mainline code that calls out to functions or subroutines that each implement an individual piece of a larger program. Now, in the 21st century, the subroutines are Web services. The implementation language for the mainline program is the BPEL for Web Services (see Resources for more information on BPEL). The execution environment is the Business Process Choreography container in IBM WebSphere® Business Integration Server Foundation. And the program can weave together many long-running tasks that may span multiple enterprises to realize a business function.

Figure 1. A simple business process
simple business process

Figure 1 shows a simple BPEL process for an in-house travel approval and booking process, which involves a program to check the request data, a human task for the actual management approval, and a B2B interaction with a partner to perform the actual booking.

Without reiterating the many references and tutorials on BPEL (see Resources), the following list summarizes a few of its features and extensions provided by IBM?s implementation of BPEL in WebSphere Business Integration:

  • Long-running business processes that can interact with multiple partners. All interactions are performed through standard, stateless Web services calls. Correlation is used to address specific instances using application level data, such as the travel approval request of a person based on employee serial number. Compensation capabilities are provided to (partially) undo the effects of a process when necessary, for example, when a travel request is canceled after a flight has already been booked.
  • Incorporation of people into processes. It's common that some business process steps are performed by humans (such as in approval or exception handling workflows). These include complex context-aware situations of assigning work to people, such as the four eyes principle, which dictates that a second approval step can be performed by any approver except the first approver. These requirements are met by using human tasks as process steps. The Business Process Choreography engine and the IBM WebSphere Studio Application Developer Integration Edition tool provide support for human tasks.
  • Embedding of processes into Java™ 2 Platform, Enterprise Edition (J2EE), and use of Java as a first-class language from within a process, in addition to XPath (which is standard in BPEL). While any Java functionality is out of scope for BPEL, IBM and BEA Systems, Inc. are proposing Java extensions for BPEL in an effort called BPELJ. These extensions allow programmers to implement activities in a process with Java snippets, use Java as an expression language where BPEL allows expressions, and manipulate the work data within a process using Java.
  • Quality of service extensions needed for production systems, such as the ability to fine-tune transaction boundaries, gracefully repair error situations, or produce audit logs.
  • Integration with WebSphere. The process choreography engine is integrated with the transaction engine and Activity Service in WebSphere. Processes involving humans make use of the WebSphere user directory and security. BPEL processes are deployed as part of the WebSphere application deployment. Administration of business processes is integrated into the WebSphere administration console.

You can use the visual business process editor in the IBM Rational® and WebSphere tool suite to build BPEL processes. Importing service interfaces into an asset view lets you invoke external services from your BPEL process. The tool suite also has a visual debugger to debug your processes, including the ability to debug parallel branches of long-running processes, and to interact with human-facing activities through appropriate user interfaces. The tool suite also allows testing BPEL processes, and deploying them as services.


Business state machines

A workflow process is analogous to an action or verb -- for example, CreatePurchaseOrder or BookTravel -- that may take multiple steps and paths, invoking many Web services, Java classes or Enterprise JavaBeans (EJBs).

If a workflow process is a verb, then a business state machine is a noun representing a thing, such as a purchase order, trouble ticket, or insurance policy application. Here, a verb -- such as CreatePurchaseOrder or BookTravel -- is an operation upon the thing. An operation on the business state machine can result in the invocation of any service, such as a BPEL process or Java code specified inline with the state machine.

Neither approach -- processes or state machines -- is superior. Rather, both are functionally equivalent service abstractions. Choose whichever one is a good abstraction for the task at hand.

A business state machine is graphically specified by a state transition diagram that shows its states, possible transitions between the states with the events that trigger them, and the resulting operations. Figure 2 is a flow chart representing a simple state machine for a PurchaseOrder.

Figure 2. A business state machine representing a purchase order
business state machine

The nodes (rectangles) represent possible states for the PurchaseOrder and may be Created, Ready, InApproval, Purchased, Canceled, Shipped, Delivered, or Archived. The arcs (arrows) represent events that can occur, causing the PurchaseOrder to transition from one state to another.

A business state machine can be implemented by a BPEL process. In that case, an event is merely an operation on the portType of a Web Services Description Language (WSDL)-described process. The current state (stored in a variable) determines which events (operations) are active. The runtime throws an exception if a caller attempts to invoke an invalid operation. You can also query the state machine?s current state to determine an operation?s validity.

When an event occurs (for example, when an operation is called or a timer is exceeded), the state machine transitions to a new state and performs an action associated with the transition (such as invoking an operation or method). In Figure 2, a transition is reflected by an arc with annotations for the event, an optional condition, and the action to be performed. A transition is only performed when its associated condition is true. Additional actions may be performed on state entry and exit. In Figure 2, the state machine in the Ready state has two possible events (enabled operations): purchase and Cancel. For the purchase operation, there are two possible conditions: either an approval is or is not needed.

When a caller invokes the purchase operation, the business state machine framework does the following:

  1. Determines if the operation is valid for the current state.
  2. Executes the state?s exit action, if one exists.
  3. Evaluates the condition of all transitions associated with that event. Assuming an approval is needed for this purchase, the transition into the InApproval state will be selected, while the transition to Purchased will be ignored.
  4. Executes the action associated with the transition, in this case doApprovalAction(). For example, this operation could send e-mail to a sales manager or simply invoke an operation on another SOA component, such as a BPEL flow.
  5. Enters the new InApproval state.
  6. Executes the new state?s entry action, if one exists.

You create business state machines using the Rational/WebSphere tool suite's visual business state machine editor. This tool treats business state machines and business processes similarly: They can have same relationships to external services, and their test and deployment environments are identical.


Summary

IBM's programming model for SOA offers several approaches for constructing new service-oriented applications or weaving existing applications into a service framework. This article has highlighted the business choreography approach using the Business Process Execution Language, which is similar to calling subroutines in classical procedural programming, with additional support for long-running work and parallelism. Business state machines are another programming model artifact that can be expressed using BPEL. Neither approach is superior. Choose the one that best fits the problem at hand. Future articles will introduce additional component types for the SOA developer's repertoire.

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=88644
ArticleTitle=SOA programming model for implementing Web services, Part 3: Process choreography and business state machines
publish-date=07122005