Chapter 14. Modeling Business Processes: BPEL

The architecture presented thus far has illustrated how you can use Web services specifications in different combinations to create secure, reliable, transacted interactions between distributed, heterogeneous applications. Services can be offered with different views both within an organization and between organizations. Domain-specific interfaces (Web Services Description Language [WSDL 1.1] portTypes) can be standardized, such as for ticketing in the airline industry. This provides a universal plug point and shorter time to market for providers of compliant service implementations and a highly competitive and diverse set of offerings for consumers who are looking for a particular functionality. From this point on, the previously defined standards can be seen as infrastructure. These standards and specifications enable the creation of numerous services in the network and the mechanisms to discover and interact with them. To move beyond the "publish, discover, interact" model, it's required to have the ability to define logic over a set of service interactions. This not only enables you to compose a set of services, but it also enables the definition of the interaction protocol of a single service by specifying an ordering of its operations.

This is where the Web services Business Process Execution Language comes into the picture. First known as BPEL4WS but soon to be renamed as WS-BPEL, this specification is more commonly known as BPEL. It is an extensible workflow-based language that aggregates services by choreographing service interactions. The aggregation is recursive, such that the process exposes WSDL interfaces to those that interact with it, and the corresponding services may be used in other choreographies. Designed to work in a highly dynamic environment in which services might change frequently, a BPEL process is intentionally decoupled from particular instances of the services it choreographs. BPEL layers neatly at the top of the WS specifications stack, directly using WSDL interfaces to define the functionality it offers to and requires from the services that are being composed, and for defining its interactions with them. You can access and manipulate data belonging to the choreography using XPath [XPath], and you can copy and exchange the endpoints of composed services in the form of WS-Addressing endpoint references [WS-Addressing]. With the modularity of the framework, you can add additional aspects to BPEL processes. For example, you can use WS-Policy and WS-PolicyAttachments to attach quality-of-service policies to different levels of the process and the related WSDLs, and you can use different bindings to carry out the interactions.

To understand how to use BPEL, read through the following example. A client wants to purchase service packs for a set of computers. Service packs are bundled support services, such as on-site repair, hardware warranties, and so on. Someone needs to validate the order before the client can proceed with the purchase. The validation consists of checking several things, such as whether the requested service packs are available in the client's context (geographical location, order date, and so on), whether they are compatible with the given machine(s), and whether they are compatible with the other service packs that are being requested. This example is derived from an IBM business application created by the Exploratorium Group at IBM's TJ Watson Research Center. It is further explained as a case study in Chapter 16, "Case Study: Ordering Service Packs."

You create a BPEL process to solve this problem. The BPEL process can accept the request for purchase order validation as a call to the Web service that it exposes. You then break up this request into smaller pieces, each sent to a separate specialized Web service that can validate a particular aspect. After that, you create the reply to the validation request based on the responses from the services that are called. The reply contains the results of validation for all the service packs you requested. You then return this reply to the caller. After that, the BPEL process can accept a purchase request to buy these service packs. The process then calls services to bill the client and update the client's profile to reflect the purchase.

The next two sections present the motivation for and a brief history of BPEL. Then the chapter discusses the architectural concepts of the language, illustrating how BPEL creates business processes. The chapter then moves on to the runtime aspects of BPEL, such as navigation and instance management. Finally, the chapter explores the future directions of the language.