Pillar 1: Asynchronous Conversations
Support for asynchrony is essential for enabling "business quality" Web services that need to take part in integration scenarios. Asynchrony is also mandatory for allowing optimal use of "business time" (e.g., allowing for user intervention within the course of an executing business flow or deferred batch processing for better distribution of processing load). Asynchrony improves scalability by decoupling requests for service from their corresponding responses, thereby avoiding a cascade of execution bottlenecks from spreading throughout the application. Asynchrony also enables uninterrupted execution when services are temporarily unavailable and when clients are disconnected or offline.

The basic interaction pattern involves a business flow initiating a request to an asynchronous Web service. The Web service can take an arbitrarily long time to complete its execution upon receiving a request. Once execution is completed, the service replies to the sender of the request. In order to carry out this interaction, certain information needs to be exchanged between the sender (business flow) and the receiver (async service). The sender needs to provide the receiver with a reply-to address (so that the receiver knows where to send the reply, i.e. invoke a callback once ready).

The sender also needs to provide the receiver with a correlation ID. Post execution, the correlation ID is sent from the receiver to the sender so that the reply from the receiver can be associated with the correct originating request on the sender side. This basic pattern can be extended to a multi-step interaction when the business flow needs to invoke the service through more than one entry point or vice versa.

The formalism for asynchronous conversations includes WS-Addressing, WS-ReliableMessaging, and BPEL Service Link. WS-Addressing specifies correlation and callback information. WS-Addressing provides transport-neutral mechanisms for addressing Web services and messages by defining XML elements to identify Web service endpoints and to secure end-to-end endpoint identification in transmitted messages.

WS-ReliableMessaging allows messages to be delivered reliably between interacting Web services in the presence of software component, system, or network failures. Its primary goal is to create a modular mechanism for reliable message delivery. BPEL Service Link defines the callback interface.

Pillar 2: Flow Coordination
Business flows in real-world application scenarios may include rather complex interaction patterns (see Figure 3). The ATP process involves the chemical manufacturing company, its applications, and related service providers. The interactions between the business flow and the services include sequencing of activities as well as running such sequences in parallel and joining their execution using a join pattern. The business flow includes both synchronous as well as asynchronous invocations of services and demonstrates exception handling during its long-running execution. (See Listing 1 for the BPEL code of this example).

 

Flow coordination is comprised of the WSDL interface, XML variables, partners, flow activities, and compensation handlers. BPEL4WS relies heavily on WSDL descriptions of the services involved in order to refer to exchanged messages, the operations being invoked, and the portTypes they belong to.

The ATP process uses a WSDL interface to integrate, for example, into a customer portal. XML variables are containers for data exchanged between the interacting services. Partners are external services which participate in the business process. Flow activities are basic and structured commands that define the rules and sequences for interacting with each service. Flow activities will be explained later. Compensation handlers are rules for undoing parts for the business flow in case of exceptions.

The ATP process includes XML variables such as the credit rating, production schedule, and inventory status. These variables are used for exchanging data with the partners (external services), which include a credit check mainframe application fronted by MQSeries, a production plans SAP application, and an inventory check SAP application. The XML variables are used for holding the data used for requests sent to a partner and for replies received from a partner. They are also used to store intermediate information, such as the combined planning information sent to the supplier hub.

Compensation handlers are used within a business process, where it might be necessary to undo one of the steps that have already been successfully completed. Compensation handlers define these undo steps at the level of a predefined scope. A compensation handler contains one activity which is run when a scope needs to be compensated. Since activities can share XML variables, completing scopes with associated compensation handlers need to save a snapshot of the data when the scope is completed. This data is used by the handler in case it is invoked (e.g., upon encountering an exception at some later point in time). Compensation handlers become ready to run once the scope they're associated with is completed successfully.

BPEL Activities
BPEL4WS is divided into basic and structured activities. Basic activities are the simplest form of interaction with the world outside the business flow. They are not sequenced and comprise individual steps to interact with a service, manipulate the exchanged data, or handle exceptions encountered during execution.

Structured activities define the order in which activities execute. They describe how a business process is created by composing the basic activities it performs into structures. These structures entail the control patterns, data flow, fault handling, external event handling, and coordination of message exchanges between process instances.

The control flow is a hybrid model halway between block structured and state transitions. It uses links to establish dependencies between block definitions and put their own constraints on how activities are set to run. Links are associated with conditions based on XPath expressions that evaluate to true or false for determining if an activity is to run or terminate (a join condition). It does not have process composition (i.e., a sub-process) but does have service composition (through use of the WSDL interface of a BPEL flow).

BPEL will drive the creation of a new generation of assembly tools that allow enterprises to implement coarse-grain processes by visually composing and tying activities and service interactions into collaborative and transactional business flows. The key benefit is developer productivity for creation of business flows but also the ability to quickly adapt to change, an essential requirement in most real-world implementations of organizations' business flows.

Pillar #3: Exception Management
According to some analysts, nearly 80% of the programming effort in automating business processes is spent in exception management. Therefore, exception management should be treated as an integral part of any specification for Web service orchestration. In contrast, most workflow and EAI/BPM solutions on the market today have implemented exception management as an afterthought. The notion of business transactions is helpful in the context of simplifying exception management across a network of loosely coupled asynchronous Web services.

The basic interaction pattern (see Figure 4) is similar to the one described for asynchronous conversations (i.e., a business flow initiating a request to an asynchronous Web service). The use case here involves an exception signaled during the business flow, before the service completes its execution. In BPEL, a local fault handler associated with the Web service, is invoked subsequent to the signaled exception. In addition, the asynchronous service is notified of the exception through a cancellation request using WS-Transaction.

 

The formalism for exception management includes the use of fault handlers and compensation handlers. Fault handlers are used when exceptions are signaled during the execution of an invoked Web service. Compensation handlers, on the other hand, reverse or undo the effect of an invocation of a Web service that completed its execution.

Exception management also includes WS-Coordination and WS-Transaction. These specifications provide cancellation requests across a network of services to ensure coordination of interacting services in case of failures, as well as guaranteeing the integrity of the overall execution.

BPEL Infrastructure
The three pillars combine to form the foundation of end-to-end business processes that call for a standards-based infrastructure for deploying and managing composite business flows (see Figure 5). The core element of this infrastructure is a BPEL server that implements the various layers of the Web service orchestration standards stack and executes flow logic that is portable and can execute in any compliant BPEL server.

 

The BPEL server supports orchestration logic provided in BPEL form for execution of business flows. Although not a mandatory requirement, a BPEL server runtime can utilize a J2EE application server for its underlying execution environment (rather than reinventing the wheel with respect to multithreading, database connection pooling, etc.). It also provides native J2EE integration by leveraging the J2EE application server runtime environment. To ensure reliability of long-running business flows involving asynchronous conversations with Web services and loosely-coupled business transactions, it uses context dehydration for executing flows. The dehydration mechanism uses a persistent store, such as a relational database, to safely store, and subsequently retrieve, flow instances.

The second important element of the infrastructure is the BPEL console, which is designed to provide ease of management for business flows deployed to the BPEL server. It offers essential monitoring and administration facilities to developers as well as operational and business users. These facilities include testing and debugging of business flows, audit trail of flow execution in both textual and graphical form, reporting and statistics, and versioning. The last capability is particularly important for long-running flows since multiple versions of the same business flow must run in parallel at times (e.g., when a new version phases in and an old version phases out).

The BPEL infrastructure should be equipped with strong support for integration. Integration capabilities are conveniently expressed through connectors that plug into the BPEL server. These connectors should support both synchronous and asynchronous interactions. Common connectors needed for enterprise computing environments include XML Web services, Java/J2EE, .NET, JMS, e-mail, and portal infrastructure (for user interaction). Such connectors should be transparent to flow logic developers and have no effect upon the portability of the BPEL code.

Conclusion
BPEL, a standard process flow grammar, provides a new foundation for integration. It empowers developers to tie transactional services, events, and user tasks into easy-to-adapt business flows. This new genre of process-driven applications moves enterprises closer to the realization of the agile real-time enterprise.