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.

Conversation Identification and Message Correlation
One way to perform correlation is to insert explicit conversation identifiers into each message to identify the conversation in which that message is participating. Sometimes that works fine, and there are provisions for message identifiers and conversation identifiers in both JMS and in WS-Addressing. At other times, however, this is unnecessarily restrictive.

For example, someone sending a message might not know what conversation identifier to use, or even whether there is an existing conversation or if a new conversation must be created. BPEL handles these cases by introducing the concept of correlation and allowing processes to define correlations with respect to message contents. In the hotel shopping case, we may have an explicit identifier that is passed around, or we might key in on a collection of application-specific properties such as a tuple, consisting of customer name, date, and city. The flexibility to orchestrate services using both explicit and implicit conversation identifiers is a powerful tool in modeling extended conversations.

Long-Running Processes
Let's return to the options for message-exchange patterns to model our hotel shopping scenario. A key factor in making the decision about how to model this is the expected time involved for each stage of the process. If the user is at the browser and is waiting for a response after putting in the request, the synchronous messaging models may be fine. The rationale might be that maintaining HTTP connections is reasonable for the short duration that the user is waiting. However, a different usage scenario might have the user feedback happen via e-mail with a response time measured in days instead of seconds. In this case, the model that treats each message as a single one-way service seems most appropriate.

Once we open our process up to a longer-running life cycle, a number of interrelated issues comes to the forefront. One is synchronous versus asynchronous messaging. Asynchronous messaging is more appropriate for longer-running processes because it doesn't require connections to be maintained for unreasonable amounts of time or use unreasonable amounts of resources in maintaining connections. A traditional method of achieving this is through an enterprise messaging system, often accessed through some vendor-neutral API such as the Java Messaging Service (JMS). Enterprise-quality message queues from companies such as IBM and Tibco provide reliable and persistent messaging and are often already in place in larger enterprises. However, the cost and complexity of these systems often serves as a barrier to entry, particularly for smaller enterprises. In recognition of this obstacle, some vendors such as Sonic Software are providing newer enterprise-messaging systems touted as being built from the ground up to support lower cost, as well as being easier to configure and deploy for Internet and firewall-friendly environments.

An alternative approach to asynchronous messaging is SOAP over HTTP with a callback specified through some addressing mechanism such as WS-Addressing. This is appealing from the standpoint of being lightweight and built on Web service standards, but it poses a reliability obstacle that is addressed by JMS and circumvented in synchronous request/response patterns. Standards such as WS-ReliableMessaging and WS-Reliability will address this obstacle, but keep in mind the infrastructure that implements these specifications is still required to achieve reliability. This infrastructure will often be available from the same vendors that are providing the enterprise messaging systems.

Another issue that lurks behind the notion of long-running processes is process persistence. The longer a given process is expected to run, the more critical it is that processes persist across power cycles. For a 500 millisecond transaction, a transaction that fails can simply be retried. When processes span weeks and months, persistence is essential. A major benefit of implementing a long-running process as a BPEL process is that the persistence of the process can be provided by the BPEL engine, greatly simplifying the business logic.

Endpoint Management
In our travel services scenario, one of the items most subject to change is the endpoint of the various services. A desirable feature of SOA is that these endpoints are dynamically and remotely manageable. Several technologies are relevant here. WSDL provides static endpoints, which are useful but limiting. A common practice is to separate the interface WSDL, which excludes the endpoint, and the implementation WSDL, which includes it. This allows for more dynamic endpoint resolution, such as that dynamically established via the ReplyTo field in WS-Addressing or in JMS. There are also cases in which multiple endpoints are valid, but some endpoints are preferable to others for efficiency reasons. For example, if multiple Java services are running in a single JVM, it will be more efficient for them to invoke each other directly in memory rather than via sending messages over socket connections. The key abstraction that BPEL offers in this is the notion of a partner link. Partner links may be specified at deployment time or at runtime. Because partner links are a first-class concept in BPEL and can be manipulated directly in processes, BPEL provides a full solution to endpoint management from the simple static deployment to the dynamic resolution that may depend on multiple factors, including technical considerations as well as business logic.

Transactions
There was one operation in our hotel service that seems innocuous, but hints at something more far-reaching: the cancel operation. The implication of this operation is that sometimes activities can be undone. Transactions are too big a topic to cover in detail here, but I will highlight a distinction between two types of transactions as they relate to BPEL and SOA.

The first type of transaction is an atomic transaction. Readers familiar with relational database management systems will be familiar with this type of transaction and the associated ACID semantics (Atomicity, Consistency, Isolation, Durability). Distributed systems that require ACID semantics normally achieve these properties by way of a two-phase commit protocol. The WS-AtomicTransaction specification defines one way of performing this type of transaction with Web service technologies.

In atomic transactions, data integrity comes at the cost of locking resources for the duration of the transaction. This can be fine for short-lived transactions, but for long-running business transactions, which may even run for months, resource locking is impractical. This motivates the need for another class of transactions that is more appropriate for long-running business activities.

This second class of transactions is sometimes called long-running transactions, or may be called a business activity. A defining characteristic is that instead of tying up resources with a locking-based protocol such as two-phase commit, the approach is to define compensation activities that can undo previous actions. Resources are not locked for the duration of the transaction, and state information can be shared across distributed resources even though the business activity is incomplete. The WS-BusinessActivity specification defines protocols along these lines based on Web service technologies.

WS-AtomicTransaction and WS-Business Activity together supercede the previously proposed WS-Transaction specification. These specifications are not yet widely accepted, and BPEL does not currently depend directly on either of them. However, the distinction between the types of transactions is an important one and BPEL does support this distinction. Some BPEL activities are explicitly specified in terms of ACID semantics (for example, assign activities are atomic, and scopes may be designated as serializable, which means they correspond to a serializable isolation level). BPEL also makes explicit provisions for the long-running transactional model through compensations and compensation handlers. Compensation handling is integrated with a fault-handling mechanism for consistent behavior in the presence of faults.

Benefits of BPEL
We have seen a number of properties common to many business process applications, including long-running processes; a need for reliable, asynchronous communication; heavy usage of Web service technologies; endpoint management; process persistence; and the ability to manage both atomic transactions as well as long-running business transactions. Although any of these properties can be achieved by writing code in a general-purpose programming language, the primary benefit of using BPEL is that it provides abstractions and infrastructure that are particularly suited to this class of applications.

This view of how BPEL derives its benefits can be contrasted with a portrayal that is sometimes found in the media, namely that the benefit of BPEL is that it provides such a high level of abstraction that business analysts can compose and run executable business processes by pointing and clicking in modeling environments. The view presented here is not that BPEL enables analysts to write software, but that the abstractions BPEL provides allow engineers to implement flexible solutions more effectively.

Summary
Service-oriented architectures are emerging as the design model of choice in integrating extended enterprises. BPEL plays an important role in SOA by providing powerful means by which business logic can be articulated and executed at an abstraction level designed to provide the services needed for integration tasks.