As you have read many times before, a service-oriented architecture (SOA) enables enterprise applications to be created and to communicate through the use of loosely coupled, course-grained, business-level, reusable services. Standards are in place to describe these services in a platform-independent way (through WSDL) and the message structures passed between them (XML Schema, XML, SOAP, etc). These services typically are implementations of processes corresponding to real-world business functions.

In the real world, however, most processes do not operate in isolation. Their invocation is often coordinated with the operation of other services, and rules are in place to determine which services are invoked and when. For example, an insurance service may require that you obtain a quote before purchasing a policy. This would not be evident in a WSDL document describing these services.

Even the location of services may change since the choice of the provider of a service may need to be dynamically based on some selection criteria. All of this becomes a dance between many changing service partners that requires choreography. Somehow, each dancer needs to know what to do next and how to respond to the last move in a way that their partner expects.

In the last few years many new standards have been proposed around SOA to handle these issues, alongside other thorny problems such as reliable delivery, transaction support, security, management and policy definition. This article will look at two of these: BPEL4WS, which focuses on business-process definition, and WS-Addressing, which provides dynamic transport-neutral ways of identifying service endpoints.

Take Your Partners

The Business Process Execution Language for Web Services (BPEL4WS) provides a formal specification of business processes that clearly captures, in a platform-independent way, how services comprising a particular process should interact. It is directly supported by, and utilizes many concepts from, WSDL. Where WSDL gives a stateless definition of synchronous or unrelated asynchronous messages, BPEL4WS extends this to define the ordering, rules, stateful data, fault handling, recovery options, and partner relationships governing the invocation of service operations.

Once of the key ties between WSDL and a process defined through BPEL4WS is the partner relationship. This relationship is typically a two-way conversation, with a partner being both the provider of a service used by the process and a consumer of a service provided by the process. The two-way nature of this conversation is especially important in the context of asynchronous messaging.

The partner relationship is defined through partnerLinkType and partnerLink definitions in a BPEL4WS specification for the business process and each of the parties with which it interacts. It should be noted that these parties do not have to be business partners, as in separate organizations, they will commonly be service providers in other systems within an organization, or even business components within the same system.

The partnerLinkType allows a relationship to be defined between two services (actually portTypes within a WSDL document). Each link type can have up to two roles corresponding to the consumer and provider of the service (asynchronous, or no need to reply services may have only one). For each link type, there can be many partnerLink definitions which define whether the process is playing the provider or consumer role in that particular relationship and who the actual partner is in that relationship. This allows many physical partners to be included in a single transaction type (such as obtaining quotes from many vendors).

The result of this is that the partner relationships effectively define the portTypes required to be implemented by the process and its partners for the relationship to succeed. If all parties are working to the same specification, but playing different roles, there can be no ambiguity as to the requirements of each.

To The Dance

Once partner relationships have been defined, the steps involved in executing the process need to be specified. The majority of a BPEL4WS specification consists of (nested) activities that explicitly define the control and data flow between services.

These activities can be of a variety of types and provide the means for defining the external interface to the process, communication with services within the process, conditional branching and iterations, sequential and concurrent execution, and schemes for fault handling and the provision of compensating transactions.

It is, after all, a high-level definition language for business processes supporting all the necessary syntax constructs required by a programming language. Anyone familiar with workflow environments should find BPEL4WS very familiar - splitting, joining, mutex event handling, alarms and triggers are all supported. An example BPEL4WS process for purchase order processing is shown in the following diagram:

The process is initiated on receipt of a purchase order. The three channels (for price calculation, shipping and production) are executed concurrently. Links between the channels wait for shipping information and the shipping schedule. Once all three channels are complete, the invoice is sent to the original requester.

Most of the service invocation and corresponding received messages are asynchronous. Returned asynchronous responses are tied to a particular purchase order process instance through the PO number, customer number or other simple properties included in the message information.

Decisions making and data processing rely on the expression and query languages selected by a particular BPEL4WS process. The default for both these languages is XPath, which needs to be supported by any implementation, but this can be replaced through language extensions.

As indicated above, BPEL4WS process instances can be stateful. When defining a process a set of variables can be declared that are passed between message invocations and should maintain their state when the particular instance is reentered (on receiving a callback from a previous asynchronous invocation, for example). These variables are usually coarse-grained complex types, such as a purchase order, and are defined using WSDL messages, or XML Schema.

In a typical environment, many instances of a single process may be active at any one time. When a message is received by the process, it is essential that the correct instance (and associated stateful data) is used. To maintain this statefulness between invocations, a construct known as a correlation set is employed. These utilize properties of simple types (such as string, integer, etc.) to identify the particular instance of a process that should receive a particular message. If, for example, many purchase orders were currently being processed, and a message indicating that an order had been shipped was received. The order number field of that message could be utilized to identify which, of the many orders in processing, this shipping notice was related to.

BPEL4WS process definitions are implementation independent. That is, they do not dictate the instances of services to use, or the data wire format and protocol involved. A provider of a BPEL4WS integration platform is required to enable service selection and deal with protocol and data transformation. Routing to particular services through their end-points can be achieved with extensions supplied by WS-Addressing.

Can I Have Your Number?

In the common services model utilizing WSDL, the endpoint for a service can be obtained in number of ways:

• Through the service element of the WSDL document
• Through a lookup of a binding template present in a UDDI directory
• Or informally through email, paper specification, etc.

All of the mechanisms result in a static binding of a service to an implementation endpoint. In many cases, a more dynamic model is required to cope with runtime configuration, stateful services and changing network topology.

WS-Addressing aims to solve these issues by introducing a standardized construct that represents a reference to a service endpoint. Each reference must include an address (as a URI, which means it can be a physical or logical address), can contain additional properties that help uniquely identify the reference, and optionally also specify the port type, service name and policies involved in accessing that endpoint. The references can be used as message parts or included in message headers to specify to, from, reply to, and send fault to information.

Although the specification for WS-Addressing is designed to be applicable to any service binding (i.e., any data wire format over any communication protocol), default bindings and specification on how to use the message headers are provided for SOAP.

Standardization of such message headers is essential for interoperability and simplifies design. Addressing information is always present in the same place (not a design decision), and it can be used to uniquely identify both a service and a particular instance of a service. An optional MessageID field allows replies, or faults related, to a particular message to be tracked.

Since the addressing information is contained in headers, it can also be rewritten dynamically by network nodes as a message makes its way between communicating parties. An example of this is shown in the previous diagram, where a broker performs address translation.

Putting It All Together

BPEL4WS promises to define business processes in which partners are required to collaborate in a platform- and implementation-independent way. There are two forms of BPEL4WS process: abstract and executable. Abstract processes are most useful in ensuring that all partners involved in a particular process are working to the same specification. They clearly define the public interfaces and policies that each partner must adhere to. Executable processes can be public, but are also very useful be in defining the private execution of a service.

Despite the emphasis on long-running transactions and conversation management, even the simplest business (composite) services could be defined using BPEL4WS. Since the public interface to an entire process is also described by a WSDL specification, it is easy to see how larger and more complex processes can be built from finer grained, yet still composite services.

Coupled with WS-Addressing, such business processes can be much more dynamic. Partner endpoints can be dynamically configured and all parties taking part in a process know how to relate messages to a particular process instance and each other. By introducing conformity into a technology area that previously had many ways of being defined, and could not easily be automated directly from a specification, these two standards promise to change the way organizations manage their business processing in the future.