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:

• Enabling Flexible Integration: Compositions need to adapt quickly to changes in the implementations or access mechanisms of the services they choreograph. One approach to this problem is to create compositions using implementation agnostic, or abstract, descriptions of the services used. This in turn enables a choreography to match services instances to the descriptions dynamically and handle incompatibilities between services.
• Offering a choreography as a Web service:The ability to expose a choreography as a Web service has three important ramifications. It enables third-party service-providers to create and offer such choreographies, composed of publicly available services. Second, it allows enterprises to expose different choreographies of their internal services to different clients. Third, it enables recursive composition, which in turn enables inter-workflow interaction, higher levels of reuse and additional scalability [12].
• Support for multiple composition patterns:In the services composition model, it is important for service compositions to interact both with other choreographies or with clients that use the choreography logic. Traditional workflows have supported a hierarchical pattern of recursive composition in which a composition is included as an activity in the flow of control and runs from start to finish when it is reached. In the conversational pattern, choreographies may have interactions that span multiple, separate exchanges. A Web services composition model should be able to handle both patterns.
• Support for lifecycle management:Choreographies need to be modeled with support for lifecycle management to allow them to be created or destroyed as needed.

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:

• Design time binding:

  Partners may be bound to actual service instances at design time, so that when a BPEL4WS definition is processed, the actual service instance that plays the role of a particular partner is known right away. This is the least flexible scheme, but opens the possibility of precompiling stubs for interacting with the service, rather than using dynamic means for invocation or trying to generate stubs at a later point when it might be more expensive.

• Deployment time binding:

  In this case, the service instances are discovered when the BPEL4WS process is deployed. This is slightly more flexible than the design--time binding; however, a single deployment of a BPEL4WS process may result in creation of multiple instances of that process, all of which will share the same services for partner implementations.

• Runtime binding:

  This is the most flexible binding scheme, wherein the actual partner instance to be invoked is not known until necessary. Such instance information, called a service reference can be exchanged through WSDL messages, and BPEL4WS has a special facility for modeling the assignment of such a reference to a partner definition, essentially achieving the mapping when the appropriate message arrives. Runtime binding allows service instances to be looked up from an online service registry, when needed and also enables a factory pattern for services.

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:

Both of these patterns are viable ways of creating compositions: Using a strict hierarchy is a useful way of modeling complex business processes, as demonstrated by the success of workflow technology. On the other hand, conversations have an expressiveness that allows easy capture of common business interactions - the acts of negotiation, monitoring of results etc. through explicitly modeled message interactions between peer business processes or choreographies, running in different domains. It is becoming increasingly obvious that for compositions to interact one needs more flexibility, perhaps only using part of a choreography or calling one of its operations multiple times. This need is evidenced by the large amount of workflow literature citing the difficulty of inter-workflow interactions using the traditional workflow model, and presenting a more conversational model [15], [6], [27].

The Web services composition approach therefore aims to provide support for conversational interaction while still allowing hierarchical composition for models that require it. In this section we show how the recursive composition model presented in the previous section enables this combination.

3.3.1 Composition Patterns in BPEL4WS

A BPEL4WS choreography becomes a Web service by mapping operations to receive/reply activities. These operations therefore define multiple entry and exit points that enable conversational interactions. Note that BPEL4WS allows the definition of multiple ``receive'' activities corresponding to the same operation and partner, effectively allowing the same operation to be invoked by the same party at different points in the composition's execution.

Applications that want to use BPEL4WS to model a single input/single output flow such as those used in hierarchical integration can do so by defining a WSDL with a single operation, mapped to a ``receive'' activity that starts the choreography. The operation will return once the process completes.

While the capability of handling conversational interactions is useful, moving the relationship between a composition and the Web services it orchestrates from that of containment to that of a peer makes validating compositions created from other compositions more difficult. The validation of business processes following the traditional workflow approach and modeled using Petri Nets has been formalized in [2]; however a formal validation for BPEL4WS has not been defined.

An interesting composition pattern not addressed by BPEL4WS is composition through the creation of open event channels between constituent Web services.

3.4 Handling Lifecycle Management

We have seen how a Web service choreography defined using BPEL4WS can be exposed as a Web service. There are two facets of the interaction with this service that are not obvious:

• How do the messages that are sent to the exposed Web service arrive at the correct instance of the choreography? and>
• How are choreography instances managed?

To address the first issue, messages exchanged with choreographies defined using BPEL4WS may contain specially tagged fields used for correlation. These fields may actually contain application data, but it is common in most business interactions for a combination of such data fields to acts as an identifier for a particular interaction. For example, messages exchanged between a customer and a purchasing system will usually contain a customer ID and transaction ID. Interactions with an online registration system at a university require the use of a student ID, and so on. BPEL4WS exploits this common pattern to map messages to choreography instances without requiring the exchange of an instance ID of any sort - while that approach would solve the problem, it adds an extra component to data exchanges that would not otherwise be needed.

When a partner interacts with a BPEL4WS choreography, the message sent to the BPEL4WS service endpoint is required to have correlation information. If this correlation information does not map to a known choreography instance, a new one is created for this interaction. Of course, only messages of certain types may create an instance. In the definition of the choreography, the designer can define the message whose receipt results in creation of a new instance, assuming they contain correlation information that doesn't already map to some instance. Thus, in the BPEL4WS model lifecycle management is implicit. This addresses the second issue. The partner has no knowledge of the specifics of the actual service instance he is interacting with.

Thus, BPEL4WS choreography instances are created implicitly, they execute according to the defined logic, awaiting message exchanges where appropriate. Messages contain the require correlation information that identifies the instance implicitly. Once the execution is complete, the instance dies automatically.

The last four sections have presented the compositional aspects of BPEL4WS that were introduced in section 3. The next section concretely illustrates these aspects by describing a sample choreography for processing bank loan applications.

4. Composition Example

We present an example choreography scenario and show how it is modeled in the BPEL4WS language.

Here, a customer requests a bank for a loan. The bank passes a subset of the customer information on to a credit rating agency that comes back with a credit report. The bank bases its decision on this data and responds to the customer, quoting an interest rate for the desired loan. The customer can then confirm the acceptance based on those terms or reject it.



Example scenario

• The customer's interaction with the bank exhibits conversational features. The two parties have a conversation encompassing two separate interactions - the loan processing itself and the loan acceptance or rejection.
• We see the need for mapping the loan request from the customer into a credit rating request for the credit agency - this minor data transformation needs to be performed by the bank.
• We see the need for mapping the loan request from the customer into a credit rating request for the credit agency - this minor data transformation needs to be performed by the bank.
• We see how the bank builds on the existing credit rating service to offer a new, value--added service of producing an interest quote for a loan request. This demonstrates the power of the service--oriented paradigm and the new kinds of software markets it creates.

Appendix A shows the BPEL syntax for implementing a simplified business process for a bank. This is a choreography created by wiring together two services - the credit rating agency Web service and the bank's internal loan service that contains the logic for deciding on an interest rate based on a credit rating. The choreography itself is exposed as a Web service with two operations. A customer interacts with the choreography by invoking these operations. The customer's social security number acts as the correlation field for matching messages with an instance of the choreography. Note that this restricts a single customer to having one outstanding loan request at a time.

5. Related Work

Workflow management systems have been successfully used to integrate heterogeneous enterprise systems, and have formed the basis of some Web services composition approaches such as WSIF [13]. In this section we present some of the prior art in workflow composition and then go over a number of the proposed Web services composition standards.

The design of a ``CORBA workflow'' model attracted much attention in the past years, due to the suitability of CORBA for integrating distributed, heterogeneous artefacts. The resulting interaction models supported require tighter coupling than in the Web services model, a direct consequence of its CORBA base [22],[20].

Wheater, Shrivastava, and Ranno describe such a system in [25]. Compositions are created by aggregating tasks, each of which corresponds to a workflow activity with given input and output sets. Recursive composition is enabled by creating compound tasks. The joinFlow system, proposed by the Workflow Management Coalition [1], exhibits the same characteristics.

These systems present a traditional workflow model with a single entry, single exit flow of control, limiting the possible interactions it can support. The interaction of multiple workflows is handled by systems such as the ones below.

In [6], the interaction between different workflows is enabled using a pub/sub event mechanism. Send and Request event nodes, defined on top of existing workflow systems to mark points in the flow where an event must be broadcast or waited for, enable workflows to interact. The [27] system describes an agent-based architecture to enable coordination between workflows running within different enterprises. It addresses dynamic discovery of providers and the complexities of protocol translation, and allows workflows to interact as peers. [15] describes the need for conversational interaction between enterprise services and presents a system that layers on top of an advance workflow system to provide support for multi-enterprise processes and service management. In the model presented in this paper, a Web services composition itself becomes a Web service, whereas in the above systems Workflows and components are treated as different kinds of entities.

In addition to BPEL4WS, a number of standards for Web services composition have been proposed. These include WSFL[11] which uses a flat graph of activities and XLANG [21] which uses structural constructs for defining processes and does not have an explicit linking mechanism. WSCI [3] describes public processes. Other industry efforts include BPML [4]. [19], which predates BPEL4WS, provides a detailed comparison of the different aspects of a number of these specifications.

6. Conclusion

In this paper we have examined the key compositional aspects of BPEL4WS and explained what role it plays in choreography. We identified flexible integration, support for multiple interaction patterns, the ability to offer the choreography as a service and support for lifecycle management as the major characteristics of composition that will enable a choreography language such as BPEL4WS to fuel the service--orientation movement.

While BPEL4WS covers many styles of composition, there are other composition aspects that are not currently covered. These include support for event propagation style composition, final or application composition, and the use of glue code [24]. We are currently working to address some of these aspects.

Acknowledgement

The authors acknowledge the contribution of many stimulating discussions on the composition of Web services with our colleagues in the Component Systems Group at IBM Research, in particular Francisco Curbera, Matthew Duftler and William Nagy.

Appendix A: Composition Example

 
<!-- BPEL4WS syntax for the bank's Web Service orchestration shown in -->
<!-- figure 3 -->
<!-- This orchestration definition is only part of the required information; -->
<!-- for actually executing this we would need to definitions of the -->
<!-- partner web services used, definitions of message types, and so on -->
<process name="loanApprovalProcess" 
         targetNamespace="http://mybank.com/loanprocessing"
         suppressJoinFailure="yes"
         xmlns="http://schemas.xmlsoap.org/ws/2002/07/business-process/"
         xmlns:lns="http://loans.org/wsdl/loan-approval"
         xmlns:loandef="http://tempuri.org/services/loandefinitions" 
         xmlns:creditagency="http://creditcompany.com/services/creditagency">
  
  <!-- define the data containers used in the orchestration -->
  <containers>
    <container name="customerRequest" 
               messageType="loandef:customerRequestMessage"/>
    <container name="creditRequest" 
               messageType="creditagency:creditRequestMessage"/>
    <container name="creditRating" 
               messageType="creditagency:creditRatingMessage"/>
    <container name="loanTerms" 
               messageType="loandef:loanTermsMessage"/>
    <container name="customerDecision" 
               messageType="loandef:customerDecisionMessage"/>
  </containers>

  <!-- define the partners involve din the orchestration -->
  <partners>
    <!-- the customer who invokes this orchestration as a web service -->
    <partner name="customer" 
             serviceLinkType="lns:loanApprovalLinkType"
             myRole="approver"/>
    <!-- the credit agency service who provides the customer's credit rating -->
    <partner name="creditAgencyService" 
             serviceLinkType="lns:creditAgencyLinkType"
             partnerRole="creditAgency"/>
    <!-- the loan determination service that decides the terms of the loan -->
    <!-- based on the credit rating -->
    <partner name="loanTermDeterminationService" 
             serviceLinkType="lns:loanTermLinkType"
             partnerRole="loanTermDecider"/>
  </partners>

  <sequence>
    <!-- receive loan request message from customer -->
    <!-- note the initiation of the correlation set based -->
    <!-- on the customer's social security number -->  
    <receive name="receiveLoanRequest" partner="customer" 
             portType="lns:loanApprovalPT" 
             operation="approve" container="customerRequest"
             createInstance="yes">
     <correlations>
       <correlation set="SSN" initiation="yes">
     </correlations>
    </receive>
    <!-- map the necessary data into the message type required by the -->
    <!-- credit agency service -->
    <assign name="mapData">
      <copy>
        <from container="customerRequest" part="SSN"/>
        <to container="creditRequest" part="SSN"/>
      </copy>
    </assign>
    <!-- get the credit rating by invoking the credit agency service -->
    <invoke name="getCreditRating" partner="creditAgencyService" 
            portType="creditAgency:creditRatingPT" 
            operation="checkCredit"
            inputContainer="creditRequest"  
            outputContainer="creditRating">
    </invoke>
    <!-- get the terms of the loan by invoking the loan determination -->
    <!-- service -->
    <invoke name="getLoanTerms" partner="loanTermDeterminationService" 
            portType="loandef:loanTermDeterminationPT" 
            operation="getLoanTerms"
            inputContainer="creditRating"  
            outputContainer="loanTerms">
    </invoke>
    <!-- reply to the customer with the loan terms -->
    <reply name="replyLoanResponse" partner="customer" 
             portType="lns:loanApprovalPT" 
             operation="approve" container="loanTerms"
    </reply>
    <!-- receive a decision from the customer regarding -->
    <!-- acceptance or rejection of the loan terms -->
    <!-- rote the use of the correlation token initiated earlier -->
    <!-- to correlate this incoming message -->
    <receive name="receiveCustomerDecision" partner="customer" 
             portType="lns:loanApprovalPT" 
             operation="confirm" container="customerDecision">
     <correlations>
       <correlation set="SSN" initiation="no">
     </correlations>
    </receive>
    <!-- respond with the customer decision as a confirmation -->
    <!-- of receipt -->
    <reply name="replyLoanResponse" partner="customer" 
             portType="lns:loanApprovalPT" 
             operation="confirm" container="customerDecision"
    </reply>
  </sequence>
</process>

References

[1] Workflow Management Facility Joint Revised Submission by the Object Management Group (OMG), Document bom/98-06-07, July 1998

[2] Wil M. P. Van Der Aalst: Workflow Verification: Finding Control-Flow Errors Using Petri-Net-Based Techniques, Proceedings of the Business Process Management 2000, number LNCS 1806, pages 161-183, Springer-Verlag, 2000

[3] A. Arkin and S. Askary and S. Fordin and W. Jekeli and K. Kawaguchi and D. Orchard and S. Pogliani and K. Riemer and S. Struble and P. Takaci-Nagy and I. Trickovic and S. Zimek: Web Service Choreography Interface 1.0, 2002 http://wwws.sun.com/software/xml/developers/wsci/

[4] Assaf Arkin: Business Process Modeling Language - BPML1.0 Last Call Working Draft, 2002 http://www.bpmi.org/bpml-spec.esp

[5] Arindam Banerjee and Claudio Bartoloni and Dorothea Beringer and Venkatesh Choppella and Kannan Govindarajan and Alan Karp and Harumi Kono and Mike Lemon and Gregory Pogissiants and Shamik Sharma and Scott Williams: Web Services Conversation Language (WSCL) 1.0, March 2002, http://www.w3.org/TR/wscl10/

[6] Fabio Casati and Angela Discenza: Modeling and Managing Interactions among Business Processes, Journal of Systems Integration, 10(2), April 2001.

[7] Erik Christensen and Francisco Curbera and Greg Meredith and Sanjiva Weerawarana: Web Services Description Language (WSDL) 1.1, March 2001 http://www.w3.org/TR/wsdl

[8] Workflow Management Coalition: Process Definition Interchange Process Model, Document Number WfMC TC-1016-P, Version 1.1, 1999 http://www.wfmc.org

[9] Francisco Curbera and Matthew Duftler and Rania Khalaf and Nirmal Mukhi and William Nagy and Sanjiva Weerawarana: Business Process Execution Language for Web Services Java Runtime(BPWS4J), 2002 www.alphaworks.ibm.com/tech/bpws4j

[10] Francisco Curbera and Yaron Goland and Johannes Klein and Frank Leymann and Dieter Roller and Satish Thatte and Sanjiva Weerawarana: Business Process Execution Language for Web Services (BPEL4WS1.0), August 2002, Published on the World Wide Web by BEA Corp., IBM Corp. and Microsoft Corp. http://www.ibm.com/developerworks/library/ws-bpel

[11] Francisco Curbera and Frank Leymann and Dieter Roller and Sanjiva Weerawarana: Web Services Flow Language (WSFL) 1.0, May 2001, http://www-3.ibm.com/software/solutions/webservices/pdf/WSFL.pdf

[12] Francisco Curbera and Sanjiva Weerawarana and Matthew J. Duftler: On Component Composition Languages, Proceedings of the 5th International Workshop on Component-Oriented Programming, May 2000

[13] Matthew J. Duftler and Nirmal K. Mukhi and Aleksander Slominski and Sanjiva Weerawarana: Web Services Invocation Framework (WSIF), Proceedings of the OOPSLA Workshop on Object--Oriented Web Services, October 2001

[14] Dimitrios Georgakopoulos and Mark F. Hornick and Amit P. Sheth: An Overview of Workflow Management: From Process Modeling to Workflow Automation Infrastructure, Distributed and Parallel Databases, 3(2): 119-153, 1995

[15] Dimitrios Georgakopoulos and Hans Schuster and Andrzej Cichoki and Donald Baker: Managing Process and Service Fusion in Virtual Enterprises, Information Systems, 26(6):429-456, 1999

[16] F. Leymann and D. Roller}: Production Workflow, Prentice Hall, 2000

[17] Nirmal Mukhi and Rania Khalaf and Paul Fremantle: Multi-protocol Web Services for Enterprises and the Grid, Proceedings of EuroWeb 02, Oxford, UK, 2002

[18] Oscar Nierstrasz and Theo Dirk Meijler: Requirements for a Composition Language,Proceedings of the ECOOP 94 workshop on Models and Languages for Coordination of Parallelism and Distribution, LNCS 924, pages 147-161, Springer Verlag, 1995

[19] David O'Riordan: Web Services Business Strategies and Architectures chapter 10, Expert Press, 2002

[20] Clemens Szyperski: Component Software: Beyond Object-Oriented Programming, Addison-Wesley, 1999

[21] Satish Thatte: XLANG, 2001 http://www.gotdotnet.com/team/xml_wsspecs/xlang-c/default.htm

[22] Steve Vinoski: Where is Middleware?, IEEE Internet Computing, 6(2), 2002

[23] Thomas Wagner and Brett Benyo and Victor Lesser and Ping Xuan: Investigating Interactions between Agent Conversations and Agent Control Components, in Frank Dignum and Mark Greaves, editors, Issues in Agent Communication, pages 314-330, Springer-Verlag, Heidelberg, Germany 2000.

[24] Sanjiva Weerawarana and Francisco Curbera and Matthew J. Duftler and David A. Epstein and Joseph Kesselman: Bean Markup Language: A Composition Language for JavaBeans Components, Proceedings of the 6th USENIX Conference on Object--Oriented Technologies and Systems, USENIX, Jan 2001

[25] Stuart M. Wheater and Santosh K. Shrivastava and Frédéric Ranno: OPENflow: A CORBA Based Transactional Workflow System, Advances in Distributed Systems, pages 354-374, 1999

[26] T. Winograd and F. Flores: Understanding Computers and Cognition: A New Foundation for Design, Ablex Publishing, Norwood, NJ, 1986

[27] L. Zeng and B. Benatallah and P. Nguyen and A. Ngu: AgFlow: Agent-based Cross Enterprise Workflow Management System, Proceedings of the 27th Int. Conference on Very Large Databases, September 2001