Service-Oriented Composition in BPEL4WS

Rania Khalaf

IBM T.J. Watson Research Center
Hawthorne, NY 10532

Nirmal Mukhi

IBM T.J. Watson Research Center
Hawthorne, NY 10532

Sanjiva Weerawarana

IBM T.J. Watson Research Center
Hawthorne, NY 10532


The advent of Web services is enabling a move towards service--oriented computing. In order for this new computing paradigm to scale, choreography standards that enable one to aggregate or compose existing services into new services are critical. Such standards would allow third--parties to provide value--added services very much like in real--world service--oriented economies. In this paper, we examine the compositional aspects of the BPEL4WS choreography language.


Web services, service--orientated computing, choreography, WSDL, BPEL4WS

1. Introduction

Web services has emerged as a new distributed computing framework, moving to address the problem of enabling interactions between heterogeneous applications distributed over the Web in which no single party has complete control. In this approach, such applications are deployed as services adhering to the WSDL[7] component model, thereby providing online access to their functionality that can be accessed and reused by both humans and other applications.

The composition of services to form new, aggregate services is the domain of Web services choreography. Choreography languages such as BPEL4WS[10] and BPML[4] fulfill the need for modeling interaction patterns, and providing these patterns for re-use. They enable a key application of service--oriented computing: the third--party aggregation of existing services into compositions that may subsequently be offered as services themselves. The two most often cited use cases for service composition are Enterprise Application Integration (EAI) in which it defines the interactions between applications residing within the same enterprise, and Business Process Integration (BPI) in which it does so for applications spread across enterprises.

A large number of composition languages and systems have been created for wiring together objects, business processes, and components. While the requirements for such composition have been often been addressed [18], [12], [16], the current shift towards service--oriented computing creates additional requirements mainly due to the paradigm's goals of loose--coupling, on--demand interaction, quick adaptation to frequent change, and lack of control over the platform and implementation of services being used.

In this paper, we examine the compositional aspects of the Web services choreography language BPEL4WS that are most directly related to service--oriented computing. We examine how it supports flexible composition of services, making full choreographies into services, multiple composition patterns and finally lifecycle management.

The rest of this paper is organized as follows: The next section presents an overview of BPEL4WS. Section 3 presents and discusses the key compositional aspects of BPEL4WS and then discusses each of those in detail. Then, an example showing how a loan approval process may be modeled is presented to illustrate these aspects. Section 5 discusses related work and finally, section 6 concludes and discusses future directions.

2. Overview of BPEL4WS

The composition of Web services consists of providing logic around a set of interactions between the composition and the Web services that participate in it. These interactions are simply invocations to the operations offered by the services in play. One approach to providing the control and data logic is the use of workflow.

In traditional workflow systems [8],[16], [14] a workflow model presents a set of structured and elementary activities and the order of execution between them. Activities are joined by links which may define transition predicates, with each activity defining a piece of business logic.

BPEL4WS is a workflow-based composition language for Web services. It introduces several types of primitive activities: to allow for interaction with the applications being composed invoke, reply and receive activities), wait for some time (the wait activity), copy data from one place to another (the assign activity), indicate error conditions (the throw activity), terminate the entire composition instance (the terminate activity), or to do nothing (the empty activity). Data is available in global containers.

These primitive activities can be combined into more complex algorithms using structured activities. These are the ability to define an ordered sequence of steps (the sequence activity), the ability to have branching using the now common "case-statement" approach (the switch activity), the ability to define a loop (the while activity), the ability to execute one of several alternative paths (the pick activity), and finally the ability to indicate that a collection of steps should be executed in parallel (the flow activity). Within activities executing in parallel, one can indicate execution order constraints by using links.

The BPEL4WS workflow model includes the ability to scope activities and specify fault handlers and compensation handlers for scopes. A fault handler gets executed when an exception arises, for example through the execution of the throw activity; compensation handlers are triggered due to faults or through compensate activities that force compensation of a scope.

In BPEL4WS, entities interacting with the composition, including the Web services being composed, are viewed as partners. Each partner may support some functionality described using WSDL[7] port types. The relation between the composition and a partner is defined in terms of two roles, one of which is played by the composition and the other by the partner. Partners are mapped to actual service instances by the runtime system; the BPEL4WS definition only refers to the abstract functionality that is supported by them.

Within the BPEL4WS model, data is accessed and manipulated using XML standards. Transformations within assign activities are expressed using XSLT and XPath languages. The use of XML as the format for data and XML schema as the associated type system follows from the use of these standards in the WSDL specification.

Another use for compositions is to describe abstract processes. These are formal descriptions of business agreements between multiple enterprises. Workflow or compositional languages are a useful way of defining such agreements. Typically, they define a set of business operations to be performed in a particular order, and the role played by each enterprise in the overall process. The BP-EL4WS specification defines a restricted syntax suitable for expressing such abstract processes. In this paper we focus only on executable processes.

An interesting feature of BPEL4WS is its support for two distinct styles of process modeling: the graph--oriented style, involving definition of a composition using graph primitives (nodes and edges), and the ``algebraic'' style derived from process calculi, in which complex control constructs (such as the compound activities above) result in implicit control flow. Each of these alone provides sufficient expressibility. Supporting both styles gives the designer maximum flexibility to develop a model in the most intuitive way.

3. Compositional Aspects of BPEL4WS

BPEL4WS offers a simple yet powerful set of composition primitives. In this section we introduce various aspects of BPEL4WS's composition constructs. The language's composition functionality can be characterized by the following:

The next four sections examine each of these in detail.

3.1 Enabling Flexible Integration

Flexible integration is a core principle in the Web services approach, supported by the consistent separation of abstract functionality from implementation and instance specific information, such as location and data and protocol bindings. Flexible integration involves the ability to offer the same service over multiple access mechanisms and allow service users to access different implementations of the same abstract functionality transparently. Flexible integration mechanisms also need to include facilities for data adaptation to address wiring of Web services that have different ways of representing data with the same semantics. The following sections describe how the principle of flexible integration is maintained in the creation of BPEL4WS processes.

3.1.1 Composing in the Abstract

The key enabler of flexible integration in BPEL4WS lies in its use of established, open Web services and XML standards. Compositions in BPEL4WS are created purely using the abstract descriptions of the participating services. As mentioned earlier, BPEL4WS composes services by aggregating interaction activities that invoke operations on its partners and/or receive invocation requests from them. These activities do not specify an implementation or a running instance, instead they refer to the definition of a partner as an implementor of certain WSDL portTypes, the portType in question, and the WSDL operation being targeted. Contrast this with a composition where invocations to services are, for example, specified by referring to a specific SOAP endpoint. While this will perform the required action, it requires changing the composition if one needs to access the service over a different supported protocol or use an implementation at a different location.

Data handling is also treated in the abstract, defined using WSDL message definition and the declared types of their parts. The result is the ability to use XPath for ubiquitous declaration of data manipulation and access. The mappings to the actual data format to be used are defined in the WSDL bindings of the services, separate from the message definitions, again allowing implementation relevant information to be changed at any time without affecting the composition.

3.1.2 Dynamic Binding to Partner Instances

Partners used in a choreography need to eventually get mapped to actual service instances that support the required functionality. The BPEL4WS language leaves the way this mapping is achieved open to implementors. Here, we list some of the possible schemes to illustrate the flexibility gained through expressing the choreography using abstract partner definitions:

3.1.3 Adapting Components

The choreography of services necessarily implies that interactions need to take place between existing, incompatible components. Such incompatibilities include differences between the message structures they consume and produce and the access mechanisms they support. Therefore, composition frameworks must be able to perform some adaptation between components to enable their interaction.

The adaptability to different access mechanisms comes as a consequence of BPEL4WS's abstract composition principle and the multi-protocol approach of Web services [17]. The actual access protocol to be used may be chosen at runtime from those offered in a partner's WSDL bindings, thereby placing the burden of access adaptability on the module performing the invocation. In one implementation, such a module uses the Web Services Invocation Framework (WSIF) which performs invocations created against the abstract WSDL description by using pluggable providers to handle invocations over different protocols [17],[9].

In BPEL4WS, data adaptability is enabled by an assignment activity. This activity allows one to create new messages, or modify existing ones, using either parts of other messages, XPath expressions, or literal values. XPath extensions defined for BPEL4WS enable the manipulation of message data. The assignment capability therefore allows the transformation of messages received from one service such that they may be accepted as the input to operations of another.

3.1.3 Inlined logic to address incompatibilities

Sometimes, the adaptability described above isn't enough to wire together services that have minor differences. These differences may go beyond the structure of data or differing access mechanisms. We may need tiny pieces of logic to ``fill in the gaps'' between incompatible services; in other words, we need some glue code to be defined as a part of the choreography, independent of any of the Web services that are involved.

BPEL4WS currently does not address this requirement but we expect that a future version of the specification will have this feature.

3.2 Exposing a Composition as a Web Service

The current service-oriented computing paradigm and the definition of Web services compositions create the need for both the ability for recursive composition which allows a business process to be used as part of another one, and the ability to offer compositions of available services or one's own business processes themselves as services.

Interactions in a choreography can be initiated by either the participants, or by the choreography itself. This type of two--way interaction requires a full specification of all the possible input messages and all the operation invocations that the choreography may accept. These acceptable ``incoming'' interactions include interactions carried out with any of the partners at any point of the execution. The participants would also need to know where to access the choreography and what data bindings to use. This is exactly the kind of information provided by WSDL. Therefore, the solution in BPEL4WS which addresses the requirements consists of mapping the interactions in the choreography into a WSDL definition.

In the BPEL4WS composition model recursive composition is enabled by two ``input'' activities: a receive activity, representing a step in the execution where the flow waits to receive an incoming message, and an optional matching reply activity, representing the return message of a synchronous request-response operation.

Each ``receive'' includes the name of an entry point (operation) in the interface, meaning that when the operation gets invoked the receive activity will be handed the message and its execution (as an activity in the choreography) completed. The ``receive'' activity defines the data container in which the input message is to be copied once it arrives. If the operation specified by the ``receive'' is a request-response operation, then a matching ``reply'' activity must appear downstream, sending back a message of the appropriate type. The complete interface of the choreography is conceptually defined by the set of all ``receive'' and ``reply'' activities present in the flow.

In this section we have shown how BPEL4WS processes become Web services, by mapping their interaction activities to WSDL operations.

3.3 Supporting Composition Patterns

In a survey of existing technologies for creating compositions from disparate software artefacts, we have observed two common patterns for interactions between compositions and other compositions or between a composition and the software artefacts it interacts with:


Hierarchical Composition

  • Hierarchical pattern:

    A common way of modeling high level business processes in workflow systems [14] is by composing a series of activities, each of which may correspond to a lower level business process / choreography, or a task to be performed by a person or a program. Here the choreography consumes an input and produces an output. While it may be monitored or interrupted by the outside system using it, it does not support any other functional interactions. This approach is simple in that from the outside system, the orchestration's complexity is completely hidden.

  • Conversational pattern:

    In hierarchical compositions, the relationship between a choreography and other choreographies that it may reuse is that of containment. In the conversational pattern, interacting orchestrations are viewed as peers. One orchestration may make use of the other by exchanging data or control signals. However, compositions are not limited to a single exchange as they are in hierarchical systems; it is perfectly conceivable to have a conversation involving two choreographies that spans multiple, separate exchanges. This kind of interaction is described in agent architectures [26], [23] and recent specifications such as WSCL (Web Services Conversation Languages) from HP [5].

  • ConversationalComposition

    Conversational Composition