Section 14.1. Motivation for BPEL

14.1. Motivation for BPEL

The composition of objects, software components, and even business processes is well understood, and developers have created numerous proposed languages and systems over the years. However, none of these languages or systems is geared to operate in a SOA environment. SOA demands a new approach that can handle, in a first class manner, its mainstays of loosely coupled entities; on-demand interactions; frequent change of such parameters as location, availability, and quality of service; and lack of control over the platform and implementation of services that are being composed.

In such an environment, many requirements are identified for a composition model that can perform the following:

• Flexible integration The composition model must be sufficiently rich to express business scenarios that partners might exchange. More importantly, it should rapidly adapt to changes in the services that it is interacting with.

• Recursive composition Offering a process as a standard Web service enables third-party composition of existing services, the ability to provide different views on a composition to different parties, interworkflow interaction, and increased scalability and reuse.

• Separation and composeability of concerns In keeping with the composeability of the Web services framework, the business/service-composition logic should be decoupled from the supporting mechanisms such as quality of service, messaging frameworks, and coordination protocols. Such information should be capable of being layered on or attached to different parts of the process definition if necessary.

• Stateful conversations and lifecycle management A workflow should have a clearly defined lifecycle model, in which it can carry multiple stateful long-running conversations with the services that it is interacting with.

• Recoverability Business processes (especially long-running ones) need to provide built-in fault handling and compensation mechanisms to deal with expected errors that might arise during execution. For example, if a credit card number is invalid, the process would ask for a new one instead of aborting entirely.

BPEL was designed to natively address these requirements. While laying out BPEL's core architectural concepts, this chapter will refer back to this list of requirements and highlight how and where BPEL addresses them.

14.1.1. A Brief History

BPEL emerged as a combination of two prior, competing XML languages for composition: the IBM Web Service Flow Language (WSFL) and Microsoft XLANG [XLANG]. Although similar in their goals, each language had a different composition approach.

In WSFL [WSFL], the flow model is a business process described as a directed graph of activities (the nodes of the graph) and control connectors (the edges of the graph). Nodes and edges of the graph are annotated with attributes, such as transition conditions, that determine the execution of the model. WSFL also provides the possibility to define a global model, in which you can specify the overall partner interactions. A global model is a simple recursive composition metamodel that allows you to describe the interactions between existing Web services and to define new Web services as a composition of existing ones.

XLANG provides a notation "for the specification of message exchange behavior among participating Web services" so that you can achieve "automation of business processes based on Web services." To achieve this objective, the major constructs of XLANG include sequential and parallel control flow definitions, long-running transactions with compensation, custom correlation of messages, exception handling, and dynamic service referral. An XLANG service description extends a WSDL service description with the behavioral aspects of the service. It allows the user to specify a set of ports in a service section of a WSDL document and extend it with a description of, for example, the sequence in which the operations that the ports provide are to be used.

In BPEL, you create the processes by using a combination of the graph-oriented style of WSFL and the algebraic style of XLANG. BPEL also allows you to recursively compose Web services into new aggregated Web services.

The first version of the BPEL4WS specification was released in 2002. Version 1.1, released in 2003, was submitted to OASIS for standardization. The group is set to produce the next version, renamed WS-BPEL version 2.0, as its first output. At the time of this writing, however, the standardization process was not yet complete, leaving WS-BPEL 2.0 in flux. As a result, this chapter uses for its reference the last stable version of the specification, BPEL4WS v1.1 [BPEL4WS]. The changes proposed so far for version 2.0 have little impact on the architectural concepts described in this chapter.