Service-oriented architectures (SOA) have gained much attention recently as a unifying technical architecture that can be concretely embodied with Web service technologies. SOA is a design model deeply rooted in the concept of encapsulating application logic within services that interact via a common communications framework. A key aspect of the Web service incarnation of SOA is that the Web service is viewed as a fundamental building block of an SOA-based application.

BPEL, originally called BPEL4WS (Business Process Execution Language for Web Services) is a language for describing Web service orchestration in terms of stateful, long-running interactions consisting of synchronous and asynchronous message exchanges. It supplies a notion of abstract processes to describe externally visible behavior as well as executable processes, which can be run either by some interpreter or by compiling them into some executable form. This article focuses on executable BPEL processes and presents one view on the benefits that BPEL brings to an XML Web service embodiment of SOA principles. BPEL plays an important role in SOA by providing a powerful means by which business logic can be articulated and executed at an abstraction level designed to provide the services needed for integration tasks.

Example: Travel Services
In order to illustrate what problems BPEL addresses and how it relates to SOA, we'll consider an example from the travel industry. Imagine a company offering travel services over the Web. The operations might include:

• getAvailableHotels: Takes an input of an airport code and returns a list of hotels near that airport.
• getDescription: Takes an input of a hotel identifier and returns a description.
• getRate: Takes as input a hotel identifier, the type and number of rooms, and the date and provides a quote for the rate.
• makeReservations: Takes as input the hotel identifiers, dates to reserve, and room information. Makes the reservation and returns the confirmation number.
• cancelReservation: Takes a confirmation number and cancels the reservation.

Let's consider what happens when we want to create a reusable service that represents some common scenario, such as shopping for a hotel. We will be calling several services, some of which will need to be invoked serially. For example, we need to get the list of hotels near a given airport in order to request detailed descriptions and rates for the hotels. Other services can be invoked in parallel, e.g., once we have the list of hotels, we may want to request descriptions and rates for all of them at once instead of one at a time. Some pieces may require user interaction, such as reviewing the list of options and deciding for which hotel to make the reservation.

We can envision this process as a flowchart consisting of basic activities and structural activities. Examples of basic activities include receiving messages, invoking external services, and assigning values from one message to another. Structural activities may include a sequence that performs nested activities in sequence, and a flow that performs nested activities in parallel. It turns out that this notion of activities is exactly what BPEL provides. In BPEL, the aforementioned activities are receive, invoke, assign, sequence, and flow. Fifteen such activities are defined in BPEL along with non-activity elements such as processes, partner links, variables, and correlations.

Listing 1 shows a brief snippet of how activities might be used in hotel shopping. Details such as data manipulation are omitted for clarity. The point to gain from this is that activities are represented as elements, and subactivities are represented as child elements. Therefore, the structure of XML reflects the structure of the process in an obvious way.

Structured collections of activities such as this can be used to define BPEL processes, which are in turn exposed as Web services; of course, this could also be done in a traditional programming language. So far, the primary benefit we have seen in BPEL is that the notion of interacting with Web services is built into the language. If our focus is almost exclusively on Web service orchestration, it is in some sense more natural to use a language that has these concepts built into it rather than a more general-purpose programming language. Nevertheless, this by itself is not very compelling because there are plenty of libraries that simplify the task of sending and receiving messages with protocols such as SOAP. We will expose more compelling reasons for preferring BPEL in this scenario as we go along.

A WSDL-Centric View of Web Services
Implementing our travel services in a Web service–based SOA implies a decomposition into Web services. A naive implementation of this idea would force the use of SOAP to communicate between all reusable parts of the application, gaining modularity at the expense of efficiency. However, we need not make this trade-off if we are careful about the ontological commitments we make about the notion of a Web service.

The defining technical characteristic of a service from a BPEL standpoint is that it is described in a WSDL. Every message exchange is described in a BPEL process in terms of portTypes and operations defined in the WSDL. BPEL does not assume that services are accessed via SOAP over HTTP, so when appropriate, more efficient bindings may be used. For example, the Apache Web Service Invocation Framework (WSIF) defines WSDL extensions for bindings of local Java invocations, EJBs, JMS, and Java Connection Architecture connectors.

Binding information is not accessed directly in BPEL, but is controlled through deployment configurations. This means that our hotel shopping process can be written in a way that is binding-agnostic, cleanly separating the business logic from lower-level concerns.

Message Exchange Patterns and Stateful Services
Our hotel shopping scenario requires input from the user twice: once to initiate the request with criteria for the city or airport and the dates, and once more to review the offerings and either pick a hotel or cancel the request. Because this input happens twice, the whole service cannot directly be modeled as a simple request/response pair. We have a number of options for how to model this:

1. The process provides three request/ response operations: getDescriptions AndRates(), makeReservation(), and cancel().
2. The process exposes a one-way operation to initiate the hotel from shopping. The customer provides a request/response for picking the hotel from the list of choices or canceling.
3. Each message is modeled as a one-way operation.