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.
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, 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.
A workflow process is analogous to an action or verb -- for example,
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
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
Figure 2. A business state machine representing a purchase order
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):
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:
- Determines if the operation is valid for the current state.
- Executes the state?s exit action, if one exists.
- Evaluates the condition of all transitions associated with that event. Assuming an approval is needed for this purchase, the transition into the
InApprovalstate will be selected, while the transition to
Purchasedwill be ignored.
- 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.
- Enters the new
- 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.
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.
- 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.
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.