Business process choreography in WebSphere: combining the power of BPEL and J2EE.

Web services based on the service-oriented architecture framework serve as the foundation for modern distributed, heterogeneous applications by providing a virtual component model. (1) Not only can new components be written as Web services, but existing applications also can be provided as Web services made available through a variety of formats and protocols in a vendor-independent and language-neutral form. (1) Web services are perfectly suited as the function layer of the two-level programming model that is the characteristic of workflow-based applications. (2)

Workflow-based applications are composed of two distinct pieces: a process model that describes the sequence in which the different activities making up the process model are being carried out (programming in the large) and the individual components that implement the various activities (programming in the small). In the Web services environment, process models are described using the Business Process Execution Language for Web services (BPEL4WS), abbreviated as BPEL in the rest of the paper. (3) The implementations of the activities are specified as Web services; the actual implementation can be done in any language and programming model. Particularly compelling is the fact that in BPEL, business processes are exposed as Web services, providing for a recursive aggregation model. (4)

The purpose of the process choreographer is to manage the life cycle of business processes, to navigate through the associated process model, and to invoke the appropriate Web services. Besides the navigation and invocation capabilities, the process choreographer must provide the appropriate quality-of-service (QoS) characteristics, such as maintaining a certain response time or ensuring particular security constraints.

The Java 2 Platform, Enterprise Edition (J2EE **) environment, as implemented by IBM's WebSphere * Application Server, provides an environment for the deployment and execution of mission-critical, enterprise-level applications.

The support of Web services is now complemented with the appropriate support for BPEL. In order to run BPEL processes on a J2EE application server, BPEL artifacts must be mapped to appropriate J2EE artifacts, for example, BPEL processes need to be rendered as EJB * (Enterprise JavaBeans **) -based components. A side effect of this mapping is the capability of Java ** applications to have native access to business processes, which drives the demand for additional Java capabilities to be exposed within BPEL, such as the usage of Java as an expression language besides XPath (XML Path Language), or the ability of having Java types in addition to XML (eXtensible Markup Language) types. The extension mechanism built into BPEL can be used to add J2EE-related constructs to BPEL. Furthermore, WebSphere provides the support of people as a resource, a function that is extremely helpful in business processes to manage situations where human involvement is mandatory. The extension mechanism built into BPEL is also used to add WebSphere-related constructs.

In this paper, we describe the implementation of a BPEL-compliant engine in the WebSphere environment and the extensions that have been defined to address additional J2EE and WebSphere functions. In the next section we present the basic features of BPEL, focusing on the more advanced features of BPEL, such as long-running business processes and failure and compensation handling. In the third section we present a programming model for the J2EE and WebSphere environment that is based on BPEL. It illustrates how BPEL processes are mapped to the J2EE environment, how Java interfaces can be supported in addition to Web Services Description Language (WSDL) port types, and how Java is used as an expression language. Furthermore, it illustrates how BPEL can be extended to accommodate the support of humans as resources in a business process. In the fourth section we show how business processes are developed and then deployed in the J2EE environment. Last, in the fifth section we present the WebSphere-based infrastructure for the execution of business processes. We start with describing the functional capabilities and then have a detailed look at the QoS characteristics of the infrastructure.

Web services composition with BPEL

The BPEL specification was submitted in April 2003 to the Organization for the Advancement of Structured Information Standards (OASIS) for standardization. The submitted specification has been created jointly by IBM, Microsoft Corporation, BEA Systems, Inc., SAP AG, Inc., and Siebel Systems, Inc., and the BPEL Technical Committee at OASIS includes members from many infrastructure and application vendors throughout the industry.

In this section we describe those features of BPEL that are necessary to understand the running example we use for illustrating the key features of our engine. Comprehensive introductions to BPEL can be found in a number of papers (e.g., Reference 5). Subsequent sections continue to use that example, extend it, and map it into the J2EE world and onto the IBM J2EE application server, WebSphere.

Invoking several Web services in a certain order--control flow. The primary goal of BPEL is to specify the sequence in which a number of services can be invoked, where "sequence" includes parallel and conditional branches. The invoked services are specified using WSDL. (6)

Suppose we want to create a business process that describes the steps to book a simple journey at a travel agent. We use a simplified example in which only a trip to a single destination is possible. The rough outline of such a business process is as follows: First, the customer data about the destination has to be checked. Then, the appropriate flight segments to and from that destination are booked. Also, a hotel at the destination is booked. Finally, payment from the customer is obtained via credit card.

The outline of that business process is shown graphically in Figure 1. The flights and the hotel are actually booked only if a check of the customer data indicates that the data are satisfactory; otherwise, there will be an error. Note that the operations for booking the flights and the hotel can be performed in parallel. An excerpt of the BPEL syntax rendering that process is shown in Figure 2.

[FIGURE 1 OMITTED]

In BPEL, a step calling out to a Web service is rendered as an invoke activity. An invoke activity specifies the Web service operation that is to be called when the activity is reached during execution of the process. The concrete syntax of the invoke activity in BPEL is shown in Figure 2, line 11, where the book-Flight operation provided by an external Web service is called.

BPEL provides several ways to aggregate activities. One very simple possibility is to use a sequence, which performs all contained activities sequentially. In our example, we have used a flow, which allows for the parallel execution of its contained activities, and the additional specification of ordering constraints using links. A link between two activities [A.sub.1] and [A.sub.2] specifies that [A.sub.2] can start only when [A.sub.1] has been completed. Links can have associated transition conditions, predicates evaluated at runtime that determine whether a link is actually followed or not. In our example, if the customer data were found to be satisfactory, both the links to the steps for booking the flight and the hotel are followed, whereas the link to the error step is not ("dead-path elimination"--see Reference 7).

BPEL provides additional constructs to describe the control flow of processes, such as switch activities for a structured way of making decisions, and while activities to perform iterations. The example uses a while activity to iterate over all flight segments, as shown in Figure 2, line 10.

Providing a composition as a Web service. A BPEL process is made available to potential exploiters as a Web service, too, implementing one or more operations of one or more port types. In business-to-business scenarios, entire conversations between participating partners are driven by processes. BPEL allows the capture of the signatures of the Web services involved in such conversations by means of a BPEL-provided WSDL extension: partner link types. A partner link type describes the interaction between two Web services by means of the roles each of the partners is playing and the interfaces each of the partners is providing.

The travel booking process interacts with a number of Web services. Each interaction is described by a partner link of a specific type. There is the interaction with the traveler (line 2), where the process provides operations of a port type called TravelAgentPT (book and cancel, not visible in the example), and expects the traveler to provide operations contained in the port type TravelerCallbackPT (with rcvTravelData and rcvErrorData operations, again not visible). Also, the process interacts with an airline reservation system to invoke operations of the flight reservation port type (line 3).

On some occasions, one role of a partner link type is empty because only one partner provides operations for the other one to call. No bilateral communication can happen in such a case, only a simple invocation (unilateral communication). In the example, the partner link between the travel booking process and the airline reservation system is of that nature, where the latter only provides operations and the former only invokes those operations. Thus, partner links allow for a uniform rendering of all kinds of interactions between two Web services, whether they are inbound only, outbound only, or truly bilateral.

A business process declares that it actually implements a Web service operation by means of a receive activity that defines the port type and operation on which the request is received from a specific partner. If the implemented operation happens to be a request-response operation, an associated reply activity at a later point in the process is responsible for delivering the result, which can also be a fault. In the example in Figure 2, the section from line 6 to line 9 shows how the travel booking process provides the book operation, with its two possible outcomes of a good or a fault result. On invocation of the book operation, the request reaches the receive activity in line 6. The createInstance attribute in the receive activity controls whether or not a new process instance should be created upon receipt of that message. Following the receive activity, invocation of the customer check takes place in line 7. Thereafter, the reply to the book operation is sent, returning a good result if the check succeeded (line 8) or a fault otherwise (line 9). The final result of the process, the travel schedule, is eventually delivered asynchronously at a later time using a callback provided by the traveler side, which the process calls using a standard invoke activity. (See the send schedule activity, shown in Figure 1.)

As we have seen until now, besides ordering of activities, the BPEL description of a business process is only concerned with the signatures of the involved services, that is, their port types, operations, and message types, which are referenced through the notion of partner links. Binding of actual services to those partner links, described by their endpoint references (8) is mostly outside the scope of BPEL. This binding can be done during modeling of the business process, or at deployment time, or even at runtime, for example, through lookups in a UDDI (Universal Description, Discovery, and Integration) directory.

There is one exception where endpoint references can appear in BPEL. Given that resolution of a concrete partner link's endpoint reference might be part of the business logic, BPEL allows the dynamic computing of such endpoint references and their assignment to a partner link as part of the business process model by means of assign activities (described later). Endpoint references may also be exchanged between business process instances by sending them either explicitly as a message part or implicitly as message context, for example, in a SOAP (Simple Object Access Protocol) header.

Handling Web service messages--data flow. Data are passed between BPEL activities using variables. Variables are typed either by complete WSDL messages that allow for the storage of an entire input or output message of a Web service operation, or by XML schema types that allow for the storage of individual entities that are relevant for the business process. Variables are scoped either by the business process itself (providing for global variables) or by a BPEL scope (a group of activities that forms an activity in itself, providing for local variables).

When a process is instantiated through a receive activity, the supplied data are stored in a variable. For each invoke operation that is part of the process, the input message of the invocation originates from a variable, and the result of the invocation is written back to another variable. Thus, data flows through the process by writing and reading variables.

BPEL provides assign activities to update variables from within a process. Through assign activities, results of one or more service invocations can be used for the invocation of a subsequent service invocation by creating the input message it requires. Figure 3 shows the assign activities needed to prepare data for the first few activities of the travel booking process, and also shows the concrete data flow implemented by the assign activity preparing the data for the reply activity.

As a special case, assign activities can also be used to assign partner link endpoint references to variable fields and variable fields containing endpoint references to partner links, providing the ability to treat endpoint references as data where needed. In the travel booking process, as part of the invocation of the book operation, the traveler could pass an end-point reference to a third party that should receive the final schedule information, rather than the traveler himself. An explicit assign step in the process would then retrieve the message field containing the endpoint reference and assign it to the appropriate partner link through which the process sends out the final schedule.

Long-running processes and correlation. An instance of a business process represents the complete course of action needed to perform a concrete set of interactions with one or more …