SOA programming model for implementing Web services, Part 3: Process choreography ...

Page 1 of 5

SOA programming model for implementing Web

services, Part 3: Process choreography and
business state machines
Level: Introductory

Matthias Kloppmann ([email protected]), Senior Technical Staff Member, IBM Software Group
Donald Ferguson, Ph.D. ([email protected]), Fellow, IBM
Marcia Stockton ([email protected]), Senior Technical Staff Member and Master Inventor, IBM Software Group

12 Jul 2005

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.

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

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,

http://www.ibm.com/developerworks/library/ws-soa-progmodel3/ 2/19/2008
SOA programming model for implementing Web services, Part 3: Process choreography ... Page 2 of 5

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

http://www.ibm.com/developerworks/library/ws-soa-progmodel3/ 2/19/2008
SOA programming model for implementing Web services, Part 3: Process choreography ... Page 3 of 5

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

http://www.ibm.com/developerworks/library/ws-soa-progmodel3/ 2/19/2008
SOA programming model for implementing Web services, Part 3: Process choreography ... Page 4 of 5

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

Read the first two articles in this series, "Part 1: Introduction to the IBM SOA programming model" (developerWorks,
June 2005) and "Part 2: Simplified data access using Service Data Objects" (developerWorks, June 2005).

Learn more about BPEL and how it works with Web services by reading "Business Process Execution Language for
Web Services (BPEL4WS) v1.1" (developerWorks, May 2003).

Learn more about business process choreography in "WebSphere Application Server Enterprise Process
Choreographer: Concepts and Architecture" (developerWorks, October 2002) and "Business process choreography in
WebSphere: Combining the power of BPEL and J2EE" from the IBM Systems Journal.

Read more about BPELJ in "BPELJ: BPEL for Java technology" (developerWorks, March 2004).

Visit the developerWorks SOA and Web services zone for extensive how-to information, tools, and project updates on
SOA and Web services technologies.

Get involved in the developerWorks community by participating in developerWorks blogs.

Browse all the SOA and Web services articles and free SOA and Web services tutorials available from
developerWorks.

About the authors

Matthias 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 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 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.

The following terms are trademarks of International Business Machines Corporation in the United States, other countries, or both:

DB2®

IBM®

Lotus®

http://www.ibm.com/developerworks/library/ws-soa-progmodel3/ 2/19/2008
SOA programming model for implementing Web services, Part 3: Process choreography ... Page 5 of 5

Rational®

Tivoli®

WebSphere®

Java and all Java-based trademarks are trademarks of Sun Microsystems, Inc. in the United States, other countries, or both. Other
company, product, or service names may be trademarks or service marks of others.

http://www.ibm.com/developerworks/library/ws-soa-progmodel3/ 2/19/2008