Web Services Choreography Description Language (WS-CDL) 1.0

Authors:

Nickolaos Kavantzas (Editor)

Goran Olsson

Jeff Mischkinsky

Martin Chapman

Copyright Notice

This WS-Choreography Specification - Choreography Description Language (WS-CDL) (the "Specification") is protected by copyright and the information described therein and technology required to implement the Specification may be protected by one or more U.S. patents, foreign patents, or pending applications. The copyright owners named above ("Owners") hereby grant you a fully-paid, non-exclusive, non-transferable, worldwide, limited license under their copyrights to: (i) download, view, reproduce, and otherwise use the Specification for internal purposes; (ii) distribute the Specification to third parties provided that the Specification is not modified by you or such third parties; (iii) implement the Specification and distribute such implementations, including the right to authorize others to do the same, provided however, that you only distribute the Specification subject to a license agreement that protects the Owners' interests by including the proprietary legend and terms set forth in this Copyright Notice.

Disclaimer of Warranties

THIS SPECIFICATION IS PROVIDED "AS IS" AND IS EXPERIMENTAL AND MAY CONTAIN DEFECTS OR DEFICIENCIES WHICH CANNOT OR WILL NOT BE CORRECTED BY THE OWNERS). THE OWNERS MAKE NO REPRESENTATIONS OR WARRANTIES, EITHER EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO, WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE OR NON-INFRINGEMENT THAT THE CONTENTS OF THE SPECIFICATION ARE SUITABLE FOR ANY PURPOSE OR THAT ANY PRACTICE OR IMPLEMENTATION OF SUCH CONTENTS WILL NOT INFRINGE ANY THIRD PARTY OR COPYRIGHT OWNER PATENTS, COPYRIGHTS, TRADE SECRETS OR OTHER RIGHTS.

This document does not represent any commitment to release or implement any portion of the Specification in any product.

THIS SPECIFICATION COULD INCLUDE TECHNICAL INACCURACIES OR TYPOGRAPHICAL ERRORS, CHANGES ARE PERIODICALLY ADDED TO THE INFORMATION THEREIN; THESE CHANGES WILL BE INCORPORATED INTO NEW VERSIONS OF THE SPECIFICATION, IF ANY. THE OWNERS MAY MAKE IMPROVEMENTS AND/OR CHANGES TO THE PRODUCT(S) AND/OR THE PROGRAM(S) DESCRIBED IN THE SPECIFICATION AT ANY TIME. Any use of such changes in the Specification will be governed by the then-current license for the applicable version of the Specification.

LIMITATION OF LIABILITY

TO THE EXTENT NOT PROHIBITED BY LAW, IN NO EVENT WILL THE OWNERS OR THEIR LICENSORS BE LIABLE FOR ANY DAMAGES, INCLUDING WITHOUT LIMITATION, LOST REVENUE, PROFITS OR DATA, OR FOR SPECIAL, INDIRECT, CONSEQUENTIAL, INCIDENTAL OR PUNITIVE DAMAGES, HOWEVER CAUSED AND REGARDLESS OF THE THEORY OF LIABILITY, ARISING OUT OF OR RELATED TO ANY FURNISHING, PRACTICING, MODIFYING OR ANY USE OF THE SPECIFICATION, EVEN IF THE OWNERS AND/OR LICENSORS HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.

You will indemnify, hold harmless, and defend the Owners and their licensors from any claims based on your use of the Specification for any purposes other than those of internal evaluation, and from any claims that later versions or releases of any Specifications furnished to you are incompatible with the Specification provided to you under this license.

Restricted Rights Legend

If this Specification is being acquired by or on behalf of the U.S. Government or by a U.S. Government prime contractor or subcontractor (at any tier), then the Government's rights in the Specification and accompanying documentation shall be only as set forth in this license; this is in accordance with 48 C.F.R. 227.7201 through 227.7202-4 (for Department of Defense (DoD) acquisitions) and with 48 C.F.R. 2.101 and 12.212 (for the non-DoD acquisitions).

Report

You may wish to report any ambiguities, inconsistencies or inaccuracies you may find in connection with your evaluation of the Specification ("Feedback"). To the extent that you provide the Owners with any Feedback, you hereby: (i) agree that such Feedback is provided on a non-proprietary and non-confidential basis, and (ii) grant the Owners a perpetual, non-exclusive, worldwide, fully paid-up, irrevocable license, with the right to sublicense through multiple levels of sublicensees, to incorporate, disclose, and use without limitation the Feedback for any purpose related to the Specification and future versions, implementations, and test suites thereof.

Abstract

The Web Services Choreography Description Language (WS-CDL) is an XML-based language that describes cross-enterprise collaborations of Web Services participants by defining their common observable behavior; where ordered and synchronized message exchanges result in alignment of their shared information.

The existing Web Services specifications, based on a stateless, connected, client-server model, offer a communication bridge between the heterogeneous computational environments used to develop applications today.

The future of E-Business applications requires the ability to perform long-lived business transactions between autonomous services. Applications, exposed as Web Services, must be able to communicate and synchronize their shared state with other Web Services in a loosely coupled environment. These interactions are long-lived and must avoid resource constraints when accessing state information or relaxing consistency guarantees in the presence of potential error recovery conditions. Business collaborations between autonomous Web Service participants will be stateful and require that all participating services can act as peers while reliably communicating in an asynchronous fashion.

This specification extends the emerging stack of Web Services standards targeted for integrating applications developed in heterogeneous computation environments.

Status of this document

This specification is a draft document and may be updated, extended or replaced by other documents, if necessary. It is for review and evaluation only. The authors of this specification provide this document as is and provide no warranty about the use of this document in any case. The authors welcome feedback and contributions to be considered for updates to this document in the near future.

Table of Contents

1. Introduction

1.1 Notational Conventions

1.2 Choreography in Action

1.3. Goals and requirements of a Business Collaboration Language

1.4. Relationship with WSDL

1.5. Relationship with Business Process Languages

2. Language Concepts

2.1. Collaboration Package

2.2. Document types, Token types, Token Locator types

2.3. Coupling Collaborating Participants

2.3.1. Static Coupling: Role types and Relationship types

2.3.2. Dynamic Coupling: Channel types

2.4. Data Driven Collaborations

2.4.1. State

2.4.2. Choreography

2.4.2.1. Choreography life-line

2.4.2.2. ChoreographyRecovery

2.4.2.2.1. Backward recovery from Faults

2.4.2.2.2. Forward recovery with Compensation

2.4.3. Activities

2.4.3.1. Interacting

2.4.3.2. Declaring State

2.4.3.3. Marking the repetition of a business rule

2.4.3.4. Marking the completion of a Choreography

2.4.3.5. Defining actions with no business effect

2.4.3.6. Sleeping

2.4.3.7. Compensating

3. Choreography Example

4. Language Elements

4.1. Choreography Document Structure

       4.1.1. Choreographydocument Naming and Linking
       4.1.2. Language Extensibility and Binding
      4.1.3. Language Elements Naming Documentation

4.1.4. Types

4.2. Packaging Choreographies
4.2.1. Importing definitions

4.3. Document types

4.4. Token types and Token Locator types

4.5. Role types

4.6. Relationship types

4.7. Channel types

4.8. State Definition

4.8.1. Expressions

4.9. Choreography Definition

4.10. Activities Definition

4.10.1. Interact activity

4.10.2. Declare activity

      4.10.3. Repeat activity
      4.10.4. Complete activity
      4.10.5. Inact activity

4.10.6. Sleep activity

4.10.7. Compensate activity

5. Relationship with the Security framework

6. Relationship with the Reliable Messaging framework

7. Acknowledgements

8. References
Appendix A – WS-CDL Schema

Appendix B – WS-CDL Supplied Functions
Appendix C – Open Issues

Appendix D – WS-CDL Meta-Model

1. Introduction

For many years, organizations have being developing solutions for automating cross-enterprise, business transactions in an effort to improve productivity and reduce operating costs.

The past few years have seen the Extensible Markup Language (XML) and the Web Services framework developing as the de-facto choices for describing interoperable data and platform neutral business interfaces, enabling more open business transactions to be developed.

Web Services are a key component of the emerging, loosely coupled, Web-based computing architecture. A Web Service is an autonomous, standards-based component whose public interfaces are defined and described using XML. Other systems may interact with the Web Service in a manner prescribed by its definition, using XML based messages conveyed by internet protocols.

An architecture of layered standards is being defined that allows technical interoperability of Web Services. The current Web Service architecture is designed for simple information retrieval in a stateless message exchange is currently defined in the following foundation layers:

§ SOAP: defines the basic formatting of a message and the basic delivery options independent of programming language, operating system, or platform. A SOAP compliant Web Service knows how to send and receive SOAP-based messages.

§ WSDL: describes the static interface of a Web Service. It defines the protocol and the message characteristics of end points. Data types are defined by XML Schema specification, which supports rich type definitions and allows expressing any kind of XML type requirement for the application data.

§ UDDI: allows publishing the availability of a Web Service and its discovery from service requesters using sophisticated searching mechanims.

§ Web Services Security: ensures that exchanged messages are not modified or forged.

The existing Web Services specifications, based on a stateless, connected, client-server model, provide an interoperable data-bus for bridging heterogeneous computational environments.

The future of E-Business applications also requires the ability to perform interoperable, cross-enterprise, long-lived business transactions. That is, applications, exposed as Web Services, exchanging business documents in peer-to-peer environments should be able to communicate and synchronize their shared business knowledge with other Web Services in a loosely coupled environment. This interaction can occur over a long period of time, and must do so without resource limitations when accessing state information, or relaxing consistency guarantees.

Business collaborations between autonomous Web Service participants will be stateful. The ability to perform certain business operations as well as the way to interpret the content of each business documents may be influenced by the previous exchanges and require that all participating services act as peers and communicate in a coordinated and reliable fashion.

Extending the current Web Services stack by defining several additional layers,

enables autonomous applications to participate in peer-to-peer business transactions.

The following figure shows the emerging stack of standards associated with Web Services for integrating applications developed in heterogeneous computation environments.

The new layers defined at the top of the current Web Service stack (see Fig. 1) are:

§ Business Collaboration Languages layer: describes cross-enterprise collaborations of Web Services participants by defining their common observable behavior, where synchronized information exchanges through their shared contact-points occur, when the commonly defined ordering rules are satisfied.

§ Business Process Languages layer: describes the execution logic of Web Services based applications by defining their control flows (such as conditional, sequential, parallel and exceptional execution) and prescribing the rules for consistently managing their not observable business data.

§ Reliable Messaging layer: provides exactly-once and guaranteed delivery of business documents exchanged between participants.

§ Context, Coordination and Transaction layer: defines interoperable mechanisms for propagating context of long-lived business transactions and enables participants to meet correctness requirements.

Figure 1 Emerging Web Services Framework

1.1. Notational Conventions

1. The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [2].

2. The following namespace prefixes are used throughout this document:

Prefix	Namespace URI	Definition
wsdl	http://schemas.xmlsoap.org/wsdl/	WSDL namespace for WSDL framework.
cdl	http://www.w3.org/ws/choreography/2003/06/WSCDL	WSCDL namespace for Choreography language.
xsi	http://www.w3.org/2000/10/XMLSchema-instance	Instance namespace as defined by XSD [10].
xsd	http://www.w3.org/2000/10/XMLSchema	Schema namespace as defined by XSD [10].
tns	(various)	The “this namespace” (tns) prefix is used as a convention to refer to the current document.
(other)	(various)	All other namespace prefixes are samples only. In particular, URIs starting with “http://sample.com” represent some application-dependent or context-dependent URI [4].

3. This specification uses an informal syntax to describe the XML grammar of a WSDL document:

§ The syntax appears as an XML instance, but the values indicate the data types instead of values.

§ Characters are appended to elements and attributes as follows: "?" (0 or 1), "*" (0 or more), "+" (1 or more).

§ Elements names ending in "…" (such as <element…/> or <element…>) indicate that elements/attributes irrelevant to the context are being omitted.

§ Grammar in bold has not been introduced earlier in the document, or is of particular interest in an example.

§ <-- extensibility element --> is a placeholder for elements from some "other" namespace (like ##other in XSD).

§ The XML namespace prefixes (defined above) are used to indicate the namespace of the element being defined.

§ Examples starting with <?xml contain enough information to conform to this specification; others examples are fragments and require additional information to be specified in order to conform.

XSD schemas are provided as a formal definition of WS-CDL grammar (see Appendix A).

1.2. Choreography in Action

A choreography defines the rules and interactions of a collaboration between two or more business entities. Choreography is described from the perspectives of all parties (common view), and defines the complementary observable behavior between participants of a collaboration.

A common view, in essence, defines the shared state of the interactions between business entities. This common view can be used to determine specific deployment implementations for each individual entity.

In real-world scenarios, corporate entities are often unwilling to delegate control of their business processes to their integration partners. Choreography offers a means by which the rules of participation for a collaboration can be clearly defined and agreed to, jointly. Each entity may then implement its portion of the choreography as determined by their common view.

The example below serves as one example of Choreography in Action:

Figure 2

In Figure 2, Company A and Company B wish to integrate their business processes. The respective Business Analysts at both companies agree upon the rules and processes involved for the collaboration. Using a tool that can serve as a basis for the collaboration, Company A and Company B agree upon their interactions and generate a WS-CDL representation.

The WS-CDL representation can then, in the case of Company A, be used to generate a BPEL [18] workflow template. Company B, having greater legacy driven integration needs, relies on a J2EE [26] solution incorporating Java and EJBs.

In this example, Choreography specifies the interoperability and interactions between business entities, while leaving actual implementation decisions in the hands of each individual company.

1.3. Goals and requirements of a Business Collaboration Language

In a peer-to-peer environment, combining existing autonomous services to facilitate their collaboration requires defining the complementary observable behavior of the Web Services participants, where their shared state is aligned using explicit rules mutually agreed by all the participating roles.

The goal of a Business Collaboration Language for Web Services is to specify a declarative, XML and WSDL 1.2 based language that describes cross-enterprise collaborations of Web Services participants by defining their common observable behavior, where synchronized information exchanges through their shared contact-points occur, when the commonly defined ordering rules are satisfied.

The following is a list of the core requirements for a Business Collaboration Language for Web Services:

Describe cross-enterprise collaborations from a common viewpoint perspective; instead of a participant perspective. A global, peer-to-peer, compositional model reflects the collaborations between a set of participants at the same level by describing the common behavior for all participants.

Compose collaborations to form new collaborations that are reused in different business contexts.

Enable verification that a business process participating in a business collaboration is conforming to a common contract, as specified by the Business Collaboration Language.

Specify the mutual responsibilities, in terms of the business operations, committed by the collaboration participants in order to accomplish a common business goal.

Specify the shared collaboration contact-points to facilitate communication and synchronization between participants. Prescribe the allowed type of information exchanged between the Web Services participating in the composition and restrict their usage. Group a set of related message exchanges between participants to construct one or more logical conversations within a collaboration.

Specify the common, explicitly specified, business rules for aligning the shared business state and enable the communication and synchronization between the participants. The rules specify:

§ On which shared collaboration contact-point(s), what business information (one or more business messages including business documents and/or collaboration contact-points) business roles must exchange in a synchronized fashion

§ When these common observable actions must occur (by specifying ordering constraints, concurrent abilities, and data dependencies on sharedbusiness information)

§ What is the shared business information that results from these collaborations.

Plan for exceptional conditions and their consequences during the collaboration, and provision for forward recovery plans.

Allow user level annotations that provide the human-readable documentation of the business rules listed above.

Support from a Web Services Reliable Messaging framework, enabling exactly-once and guaranteed delivery of business documents exchanged between participants (details are provided in section 6 of this document).

Assert when Web Service participants are capable of managing their collaborations in a transactional way; to precisely define the transaction boundaries and the common observable compensation behavior. Coordinate the outcome of the long-lived collaborations, which include multiple, often recursive collaboration units, each with its own business rules and goals.

Describe semantics of the Web Services.

Describe the policies and the faults that result when these policies are not followed:

§ authorizing a participant to be engaged in a business transaction.

§ signing a business document for non-repudiation purposes.

1.4. Relationship with WSDL

The WS-CDL specification depends on the following specifications: XML 1.0 [9], XML-Namespaces [10], XML-Schema 1.0 [11, 12] and XPath 1.0 [13]. In addition, support for importing and referencing service definitions given in WSDL 1.2 [7] is a normative part of the WS-CDL specification.

1.5. Relationship with Business Process Languages

WS-CDL is not an "executable business process description language" [16, 17, 18, 19, 20] or an implementation language [23]. The role of specifying the execution logic of an application will be covered by these specifications; by enabling the definition of the control flows (such as conditional, sequential, parallel and exceptional execution) and the rules for consistently managing their unobservable business data.

WS-CDL does not depend on a specific business process implementation language. Thus, it can be used to specify trully interoperable collaborations between any type of Web Service participant regardless of the supporting platform or programming model used by the implementation of the hosting environment.

Typically, the respective Business Analysts define in WS-CDL the common observable behavior of all participants engaged in the business collaboration. Each participant could be implemented by completely different languages such as:

§ Web Services applications, whose implementation is based on executable business process languages like [16, 17, 18, 19, 20].

§ Web Services applications, whose implementation is based on languages like [23] or collaboration frameworks like [24].

§ Or human controlled software agents.

2. Language Concepts

This section introduces the Web Services Choreography Description Language (WS-CDL) definitions to address the Business Collaboration Language requirements as defined in section 1.

2.1. Collaboration Package

A WS-CDL document describes interoperable, cross-enterprise collaborations that allow participants to perform business transactions. In order to facilitate these collaborations, services commit on mutual responsibilities by establishing business relationships. Their collaboration takes place in a commonly agreed set of constraints, whereby documents are exchanged in a synchronized fashion between the participants.

A Choreography allows constructing compositions of Web Service participants by explicitly asserting their common observable behaviors, where synchronized information exchanges through their shared contact-points occur, when the commonly defined ordering rules are satisfied.

A WS-CDL Package contains a set of one or more Choreographies and a set of one or more collaboration type definitions, allowing the various types whose use may be wider than a single Choreography to be defined once. The collaboration Package contains:

§ One or more Document types

§ One or more Token types and Token Locators types

§ One or more Role types

§ One or more Relationship types

§ One or more Channel types

§ One or more Interaction types

§ Zero or more, package-level Choreographies

2.2. Document types, Token types, Token Locator types

A WS-CDL document allows defining relevant parts of the exchanged documents that can influence the observable behavior of a collaboration.

A Document type allows specifying the type of the document exchanged between participants.

A Token type facilitates naming and typing of business document fragments.

A Token Locator type specifies the rules of how to select these fragments within a business document.

Document types are used for defining the types of documents used within a Choreography definition. By introducing this abstraction, a Choreography definition avoids referencing only abstract message types, as described by WSDL, but instead can reference other data types as defined by the XML Schema specification.

Token types reference a document fragment within a Choreography definition and Token Locator types provide a query mechanism to select them. By introducing these abstractions, a Choreography definition avoids depending on specific message parts, as described by WSDL, or a specific query string, as specified by XPATH, but instead the parts or the query string can change without affecting the Choreography definition.

2.3. Coupling Collaborating Participants

The WSDL specification describes the functionality of a service provided by a participant based on a stateless, connected, client-server model. The emerging Web Based applications require the ability to exchange business documents also in a peer-to-peer environment. In these type of environment a participant represents a requester of services provided by another participant and is at the same time a provider of services requested from other participants, thus creating mutual multi-participant service dependencies.

A WS-CDL document describes how a Web Service participant is capable of engaging in collaborations with the same participant or with different participants by specifying both their static and dynamic couplings.

2.3.1. Static Coupling: Role types and Relationship types

Role and Relationship types statically identify the collaboration contact-points of Web Service participants.

A Role specifies the observable behavior, in terms of the business operations, a participant MUST exhibit in order to collaborate with other participants. Within a Role, a Behavior type specifies a subset of the observable behavior a participant MUST exhibit in order to collaborate with other participants under their mutually agreed commitments. A Web Service participant exposes its Behavior type as the Web Service interface type it supports.

A Relationship specifies the mutual commitments, based on the Role types and the Behavior type required, that two participants oblige to provide in order to participate in a common business transaction.

2.3.2. Dynamic Coupling: Channel types

A Channel dynamically identifies the collaboration contact-point of interacting Web Service participants and the long-lived logical conversations performed within their common business transactions.

A collaboration contact-point MAY describe the WSDL service type of a participant, and the business process type implementing that participant. The different service types of a participant and the business process types within a participant, are distinguished by a set of token values designated by a particular Channel.

A collaboration contact-point MAY describe one or more logical conversations between different participants, within a collaboration,.Each conversation groups a set of related document exchanges. The different conversations are distinguished by a set of token values, designated by a particular Channel.

A Channel MAY restrict the usage of the collaboration contact-points shared between two Web Services participants by specifying the number of times that a collaboration contact-point can be used.

A Channel MAY prescribe the types of the collaboration contact-points allowed to be exchanged between the Web Services participants, when using this channel.

2.4. Data Driven Collaborations

2.4.1. State

A WS-CDL document allows declaration of the business information shared between participants engaged in stateful, long-lived business transactions, where performing certain collaborations requires the ability to depend upon the exchanges of previous business documents.

State captures the business information shared by the participants in order to fulfill their common business goals. The information captured is:

§ Business documents.

§ Channels.

The state information MUST be available before it can be referenced.

A WS-CDL document makes the state information available to a participant, by declaring it (using the features of XML data types, WSDL message types and XPATH expressions).

A WS-CDL document aligns shared state information and makes it available to two interacting participants within a Choreography, byperforming a synchronized interaction through a common Channel.

2.4.2. Choreography

A WS-CDL document explicitly prescribes the rules, agreed between Web Service participants, that govern the ordering of exhanged messages and the provisioning of alternative patterns of behavior. The operational semantics of these rules are based on the data-driven computational model, where availability of shared state information causes a rule to be triggered and its guarded subsequent actions to be enabled.

A Choreography defined at the Package level is called a base Choreography, and does not share its context with other base choreographies. A Choreography defined within another Choreography is called an enclosed Choreography. A Package MUST contain exactly one base Choreography, that is explicitly marked as the root Choreography. The root Choreography is the only base Choreography that MAY be initiated. The root Choreography is enabled when it is initiated. All non-root base Choreographies MAY be enabled only inside a root Choreography.

A Choreography facilitates recursive composition, where combining two or more Choreographies can form a new enclosing Choreography that may be re-used in different business contexts.

A Choreography MUST contain at least one Relationship type, enumerating the observable behavior this Choreography requires its participants to provide. One or more relationships MAY be defined within a Choreography, modeling multi-participant collaborations.

A Choreography acts as a name scoping context as it restricts the visibility of state information. State defined in a Choreography is visible in this Choreography and all its enclosed Choreographies, forming a Choreography Visibility Horizon. Restricting the visibility of state information allows aligning activities that are generating, and exchanging state information between participants to be isolated from activities belonging to different Visibility Horizons.

A Choreography MUST contain at least one Reaction.

A Reaction prescribes the explicit rules for enforcing the constraints that preserve the consistency of the business transactions commonly performed by the Web Service participants.

A Reaction provides the environment within which two or more business actions can be enabled sequentially or concurrently. When enabled concurrently, actions are not constrained to be enabled in a specific order.

A Reaction allows an application to recover from faults that are the result from abnormal business actions and also to compensate for completed business actions that need to be logically rolled back.

A Reaction specifies the data dependencies that must be satisfied before enabling one or more business actions, by expressing intereston the availability of state information that already exists or will be created in the future.

A Reaction MUST contain exactly one Relationship type, enumerating the observable behavior this Reaction requires its two participants to provide. The specified Relationship type MUST be already defined within its immediately enclosing Choreography Relationship type.

A Reaction is enabled when the Choreography it belongs to is enabled. Enabled Reactions are matched when the required, zero, one or more state information become available. Availability of some state information does not mean that a Reaction matches immediately. Only when all state information required by a Reaction become available in the appropriate Visibility Horizon does matching succeed. State information available in a Choreography MAY be matched with a Reaction that will be registered in the future. The matching of state information with Reactions MAY enable one, or more concurrent Choreographies.

A Choreography MAY containmore than one Reaction, thus allowing choosing between alternative collaboration paths. A Reaction MAY belong to a Reaction Group. One or more Reactions MAY belong to the same Reaction Group. Within a Choreography, one or more Reaction Groups MAY be specified. When two or more Reactions are matched within the same Reaction Group then only one Reaction is allowed to make progress by enabling its own actions. The lexicographical order of the Reactions belonging to the same Reaction Group, determines which Reaction makes progress. All matched Reactions that belong to different Reaction Groups are allowed to make progress by enabling their own actions.

A Reaction completes successfully when all its enclosed business actions complete successfully. A Reaction that completes successfully MUST be re-enabled and considered again for matching if an action inside the Reaction marked it for repetition.

2.4.2.1. Choreography life-line

A Choreography expresses the progression of a business transaction. Initially, the business transaction MUST be started, then work MAY be performed within it and finally it MUST complete. These different phases are designated by explicitly marked business operations within the Choreography and its semantics.

A root Choreography is initiated when the first interaction, marked as the Choreography initiator, is performed. Two or more interactions MAY be marked as initiators, indicating alternative initiation actions. In this case, the first action will initiate the Choreography and the other actions will enlist with the already initiated Choreography. An interaction designated as a Choreography initiator MUST be the first action performed in a Choreography. If a Choreography has two or more Reactions with interactions marked as initiators, then these are mutually exclusive and the Choreography will be initiated when the first interaction occurs and the remaining Reactions will be disabled. All the interactions not marked as initiators indicate that they will enlist with an already initiated Choreography.

A Choreography completes successfully when there no more enabled Reaction(s) within it.

2.4.2.2. Choreography Recovery

An Exception Choreography MAY be defined as part of an enclosing Choreography to recover from exceptional conditions that may occur in that Choreography. A Compensation Choreography MAY be defined as part of an enclosing Choreography to provide the compensation actions that semantically rollback the completed enclosing Choreography.

2.4.2.2.1. Backward recovery from Faults

When a Choreography encounters an exceptional condition it MAY need to act on it.

An ExceptionChoreography is a Choreography defined as part of an enclosing Choreography for the purpose of handling the exceptional conditions occurring on that Choreography. A Choreography MAY define exactly one ExceptionChoreography.

An ExceptionChoreography MUST specify one or more Exception Reactions. An Exception Reaction expresses interest on fault state information that MAY become available. When an Exception Reaction matches, it enables the appropriate activities for recovering from the fault.

The fault state information is a result of:

§ A fault occurring while performing an interaction between collaborating participants.

§ A timeout occuring while an interaction between collaborating participants was not completed within a specified time period.

Exception Reactions are enabled when the Exception Choreography is enabled.The Exception Choreography MAY be enabled only once for an enclosing Choreography. Exception Reactions enabled in an enclosing Choreography MAY behave as the default mechanism to recover from faults for all its enclosed Choreographies.Exception Reactions enabled in an enclosed Choreography MAY behave as a refined mechanism to recover from faults for any of its enclosing Choreographies.

If a fault occurs, then the faulted Choreography completes unsuccessfully and its Compensation Choreography is not enabled. The actions, including enclosed Choreographies, enabled within the faulted Choreography are completed abnormally before an Exception Reaction can be matched.

If a fault is not matched by an Exception Reaction defined within the Choreography in which the fault occurs, then the fault will be recursively propagated to the parentException Choreography until a match is successful. If a fault is matched by an Exception Reaction then the actions of the matched Reaction are enabled.

The actions within the Exception Choreography MAY use state information visible in the Visibility Horizon of its enclosing Choreography as they stand at the current time.

The actions of an Exception Choreography MAY also fault. The semantics for matching the fault and acting on it are the same as described in this section.

2.4.2.2.2. Forward recovery with Compensation

When a Choreography encounters an exceptional condition it MAY need to revert the actions it had already completed, by providing compensation actions that semantically rollback the effects of the completed actions.

A Compensation Choreography is a Choreography defined as part of an enclosing Choreography for the purpose of reverting the effects of that Choreography. A Choreography MAY define exactly one Compensation Choreography.

A Compensation Choreography MUST specify exactly one Compensation Reaction. A Compensation Reaction expresses interest on state information that MAY become available by a compensation command targetted to the enclosing Choreography. The compensation command is issued by the Exception or the Compensation Choreography of the parent of the enclosing Choreography. When a Compensation Reaction matches, it enables the appropriate compensation actions.

A CompensationChoreography is enabled only after its enclosing Choreography completes successfully. The Compensation Choreography may be enabled only once for an enclosing Choreography.

The actions within the Compensation Choreography MAY use state information visible in the Visibility Horizon of its enclosing Choreography as they were at the time the enclosing Choreography completed or as they stand at the current time.

The actions of the Compensation Choreography MAY fault. The semantics for matching the fault and acting on it are the same as described in the previous section.

2.4.3. Activities

The Activities describe the detailed actions of a business transaction as follows:

2.4.3.1. Interacting

An Interact activity represents the atomic unit of work for communicating and synchronizing two participants. Two participants make progress by interacting and align their shared information by performing synchronized information exchanges through a common Channel.

An interaction is initiated when a participant playing the requesting role sends a service request, through a common Channel, to a participant playing the accepting role.The interaction is continued when the accepting participant, sends zero or one response(s) back to the requesting participant.

The state information that SHOULD be aligned and made available to the two interacting participants MUST be explicitly modeled in WS-CDL as a state alignment interaction between them.

After they interact, both participants progress at the same time, in a lock-step fashion and the state information in both participants is aligned. Their state alignment comes from the fact that the requesting participant has to know that the accepting participant has received the message and the other way around, the accepting participant has to know that the requesting participant has sent the message before both of them progress. The mechanism of how this is accomplished is implementation specific.

An interact activity forms the atom of composition, where multiple interacts are combined to form a Choreography, which can be used in different business contexts. A business collaboration that does not have atomic semantics, SHOULD be modeled as several interactions between participants instead of one interaction.

The Channel through which an interaction occurs is used to determine whether to enlist the interaction with an already initiated Choreography or to initiate a new Choreography. Within a Choreography, two or more related interactions MAY be grouped to form a logical conversation. The Channel through which an interaction occurs is used to determine whether to enlist the interaction with an already initiated conversation or to initiate a new conversation.

An interaction completes normally when the request and the response (if there is one) complete successfully. In this case the business documents and Channels exchanged during the request and the response (if there is one) result in the shared state being aligned between the two participants.

An interaction completes abnormally if faults occur:

§ The time-to-complete timeout identifies the time an interaction takes to complete. If this timeout occurs, after the interaction was initiated but before it completed, then a fault is generated.

§ A fault signals an exceptional condition during the management of a request or within a participant when accepting the request.

In this case the business documents and channels exchanged do not result in any new state alignment between these participants, rather the shared state remains the same as if this interaction had never occurred:

§ A requesting participant completes the current interaction. The requesting participant may create a new interaction to recover from this failure as part of the same Choreography or of a completely new Choreography.

§ An accepting participant completes the current interaction.

2.4.3.2. Declaring State

The Declare activity allows creating new state information by generating business documents and Channels.

2.4.3.3. Marking the repetition of a business rule

The Repeat activity marks a Reaction for repetition if it completes successfully.

2.4.3.4. Marking the completion of a Choreography

The Complete activity models completion of a Choreography.

2.4.3.5. Defining actions with no business effect

The Inact activity models the performance of a business action that has no business effect to any of the collaborating participants.

2.4.3.6. Sleeping

The Sleep activity models the suspension of any business action for a specified period of time.

2.4.3.7. Compensating

The Compensate activity models issuing a compensate command from a parent Choreography to the Compensation Choreography of an enclosed Choreography.

3. Choreography Example

This example depicts a multi-party choreography illustrating a simple purchase sequence. The choreography involves four parties; a Buyer, Seller, Credit Checking Service and Inventory Service.

The Seller, upon receiving the Purchase Order from the buyer, initiates 3 interactions:

§ one with the Buyer to acknowledge the receipt of the Purchase Order

§ one with the Credit Checking Service to check the credit of the Buyer

§ one with the Inventory Service to check the inventory of the product ordered by the Buyer.

The Seller waits for the response from both the Credit Checking Service and Inventory Service. If both responses are positive, the order is processed and the Purchase Order Response is sent.

If either of the responses from Credit Checking Service or Inventory Service are negative, then a Purchase Order Reject message is sent to the Buyer.

In the example below, the main choreography involves 3 relationships:

§ Buyer-Seller

§ Seller-Credit Checking Service

§ Seller-Inventory

Within this main choreography, we have 3 sub-Choreographies, one for each relationship. The various reacts with guards on them reflect the ordering of the activities.

The react 'purchaseDocAvailibility' has a guard on 'purchaseOrderDocAtSeller' that triggers when a Purchase Order document is received by the Seller.

Similarly, the react with the guard 'creditApprovalInventoryApproval' is triggered when the query on 'CreditCheckResponseDocAtSeller' and 'InventoryResponseDocAtSeller' result in positive answers from the Credit Checking Service and Inventory Service.

WSDL Definitions

<definitions name="PurchaseOrderDefs"

targetNamespace="urn:purchaseOrder:purchaseOrderDefs"

xmlns:tns="urn:purchaseOrder:purchaseOrderDefs"

xmlns:xsd="http://www.w3.org/2001/XMLSchema"

xmlns="http://schemas.xmlsoap.org/wsdl/">

<types>

<xsd:complexType name="purchaseOrderType">

<xsd:element name="CID" type="xsd:string"/>

<xsd:element name="Order" type="xsd:int"/>

</xsd:complexType>

</types>

<types>

<xsd:complexType name="purchaseOrderAckType">

<xsd:element name="CID" type="xsd:string"/>

<xsd:element name="Order" type="xsd:int"/>

</xsd:complexType>

</types>

<types>

<xsd:complexType name="purchaseOrderResponseType">

<xsd:element name="CID" type="xsd:string"/>

<xsd:element name="Order" type="xsd:int"/>

</xsd:complexType>

</types>

<types>

<xsd:complexType name="purchaseOrderRejectType">

<xsd:element name="CID" type="xsd:string"/>

<xsd:element name="Order" type="xsd:int"/>

<xsd:element name="reason" type="xsd:string"/>

</xsd:complexType>

</types>

<types>

<xsd:complexType name="inventoryCheckRequestType">

<xsd:element name="productID" type="xsd:int"/>

<xsd:element name="productQty" type="xsd:int"/>

</xsd:complexType>

</types>

<types>

<xsd:complexType name="inventoryCheckResponseType">

<xsd:element name="productID" type="xsd:int"/>

<xsd:element name="productQty" type="xsd:int"/>

</xsd:complexType>

</types>

<types>

<xsd:complexType name="creditCheckRequestType">

<xsd:element name="CustomerID" type="xsd:int"/>

<xsd:element name="SSN" type="xsd:string"/>

</xsd:complexType>

</types>

<types>

<xsd:complexType name="creditCheckResponseType">

<xsd:element name="CustomerID" type="xsd:int"/>

<xsd:element name="SSN" type="xsd:string"/>

</xsd:complexType>

</types>

</message>

</message>

</message>

</message>

</message>

</message>

</message>

</message>

</definitions>

Buyer Service

<definitions name="BuyerService"

targetNamespace="urn:purchaseOrder:buyerService"

xmlns:pons="urn:purchaseOrder:purchaseOrderDefs"

xmlns="http://schemas.xmlsoap.org/wsdl/">

</operation>

</operation>

</operation>

</interface>

</definitions>

Seller Service

<definitions name="SellerService"

targetNamespace="urn:purchaseOrder:sellerService"

xmlns:pons="urn:purchaseOrder:purchaseOrderDefs"

xmlns="http://schemas.xmlsoap.org/wsdl/">

</operation>

</interface>

</operation>

</interface>

</operation>

</interface>

</definitions>

Credit Service

<definitions name="CreditService"

targetNamespace="urn:purchaseOrder:creditService"

xmlns:pons="urn:purchaseOrder:purchaseOrderDefs"

xmlns="http://schemas.xmlsoap.org/wsdl/">

</operation>

</interface>

</definitions>

Inventory Service

<definitions name="InventoryService"

targetNamespace="urn:purchaseOrder:inventoryService"

xmlns:pons="urn:purchaseOrder:purchaseOrderDefs"

xmlns="http://schemas.xmlsoap.org/wsdl/">

</operation>

</interface>

</definitions>

Choreography Example

<package

name="purchaseOrderChoreography"

version="1.0"

targetNamespace="urn:purchaseOrder:purchaseOrderChoreography"

xmlns:pons="urn:purchaseOrder:purchaseOrderDefs"

xmlns:bns="urn:purchaseOrder:buyerService"

xmlns:sns="urn:purchaseOrder:sellerService"

xmlns:cns="urn:credit:creditService"

xmlns:ins="urn:inventory:inventoryService"

xmlns:wsrf="http://www.wsref.com"

xmlns="http://www.w3.org/ws/choreography/2003/06/CDL"

xmlns:wsdl="http://schemas.xmlsoap.org/wsdl">

<import namespace=”http://otn.oracle.com/”

location=”http://otn.oracle.com/ws/choreo/sample”/>

</importDefinitions>

<documentType name="purchaseOrderDocType"

messageType="pons:purchaseOrderMsg"/>

<documentType name="purchaseOrderAckDocType"

messageType="pons:purchaseOrderAckMsg"/>

<documentType name="purchaseOrderRejectDocType"

messageType="pons:purchaseOrderRejectMsg"/>

<documentType name="purchaseOrderResponseDocType"

messageType="pons:purchaseOrderResponseMsg"/>

<documentType name="creditCheckRequestDocType"

messageType="pons:creditCheckRequestMsg"/>

<documentType name="creditCheckResponseDocType"

messageType="pons:creditCheckResponseMsg"/>

<documentType name="inventoryCheckRequestDocType"

messageType="pons:inventoryCheckRequestMsg"/>

<documentType name="inventoryCheckResponseDocType"

messageType="pons:inventoryCheckResponseMsg"/>

<tokenType

name="purchaseOrderID" type="xsd:int"/>

<tokenLocator tokenName="sns:purchaseOrderID"

documentType ="purchaseOrderDocType"

part="PO"

query="/PO/Order"/>

<tokenLocator tokenName="sns:purchaseOrderID"

documentType ="purchaseOrderResponseDocType"

part="PO"

query="/PO/Order"/>

<tokenType

name="customerID" type="xsd:int"/>

<tokenLocator tokenName="sns:customerID"

documentType ="creditRequestDocType"

part="Credit"

query="/CreditCheck/CustomerID"/>

<tokenLocator tokenName="sns:customerID"

documentType ="creditResponseDocType"

part="Credit"

query="/CreditCheckResponse/CustomerID"/>

<tokenType

name="productID" type="xsd:int"/>

<tokenLocator tokenName="sns:productID"

documentType ="inventoryRequestDocType"

part="Inventory"

query="/InventoryCheck/ProductID"/>

<tokenLocator tokenName="sns:productID"

documentType ="inventoryResponseDocType"

part="Inventory"

query="/InventoryCheckResponse/ProductID"/>

<tokenType

name="buyerRef" type="anyURI"/>

<tokenType

name="warehouseRef" type="anyURI"/>

<tokenType

name="creditRef" type="anyURI"/>

<tokenType

name="inventoryRef" type="anyURI"/>

</roleType>

<!-- The role seller has 3 interfaceTypes one for buyer, one for

credit and one for inventory-->

<behaviorType name="sellerForBuyer"

interfaceType="sns:SellerPOPT"/>

<behaviorType name="sellerForCredit"

interfaceType="sns:SellerCreditPT"/>

<behaviorType name="sellerForInventory"

interfaceType="sns:SellerInventoryPT"/>

</roleType>

</roleType>

</roleType>

</relationshipType>

</relationshipType>

</relationshipType>

</reference>

</identity>

</channelType>

</reference>

</identity>

</channelType>

</reference>

</identity>

</channelType>

</reference>

</identity>

</channelType>

</reference>

</identity>

</channelType>

</reference>

</identity>

</channelType>

<!-- these state definitions define states which are used across

buyer/seller, seller/credit and seller/inventory choreographies

-->

<stateType name="purchaseOrderDocAtSeller"

documentType="purchaseOrderDocType"

roleType="Seller"/>

<stateType name="creditCheckResponseDocAtSeller"

documentType="creditCheckResponseDocType"

roleType="Seller"/>

<stateType name="inventoryCheckResponseDocAtSeller"

documentType="inventoryCheckResponseDocType"

roleType="Seller"/>

<stateType name="seller-channel-for-buyer"

channelType="purchaseOrderCHT"/>

</stateDefinitions>

<react name="programPurchaseOrder"

relationshipType=”BuyerSellerBinding”>

<choreography

name="buyerSellerChoreography”>

<relationship=”BuyerSellerBinding"/>

<stateType name="purchaseOrderAckDoc"

documentType="purchaseOrderAckDocType"/>

<stateType name="purchaseOrderDocAtBuyer"

documentType="purchaseOrderDocType"

roleType="Buyer"/>

<stateType name="purchaseOrderResponseDoc"

documentType="purchaseOrderResponseDocType"/>

<stateType name="purchaseOrderRejectDoc"

documentType="purchaseOrderRejectDocType"/>

<stateType name="buyer-channel"

channelType="purchaseOrderResponseCHT"/>

</stateDefinitions>

<react name="purchaseOrder"

relationshipType=”BuyerSellerBinding”>

<!-- This is the first interact, hence we assume that

the buyer and seller

have negotiated and know the seller-channel-for-buyer -->

<interact name="createOrderInteract"

onChannel="seller-channel-for-buyer"

operation="createOrder"

initiateChoreography="true">

<participate relationship="BuyerSellerBinding"

fromRole="Buyer"

toRole="Seller"/>

<align state="purchaseOrderDocAtBuyer"

with-state="purchaseOrderDocAtSeller"/>

<align state="buyer-channel"

with-state="buyer-channel"/>

</interact>

<!-- This is not a response, but just an acknowledgement

-->

<interact name="createOrderAckInteract"

onChannel="buyer-channel"

operation="createOrderAck">

<participate relationship="BuyerSellerBinding"

fromRole="Seller"

toRole="Buyer"/>

<align state="purchaseOrderAckDoc"

with-state="purchaseOrderAckDoc"/>

</interact>

<!-- this is a sub choreography of buyerSellerChoreography

because we want to share the scope of buyer-channel

between the two -->

<choreography

name="sellerResponseChoreography">

<relationship=”BuyerSellerBinding"/>

<!-- The group name ApproveOrReject indicates that

all the reacts that belong to this group are

mutually exclusive. When one is fired, the

others are disabled.-->

<react name="creditApprovalInventoryApproval"

group="ApproveOrReject"

relationshipType=”BuyerSellerBinding”

guard= "cdl:getState(CreditCheckResponseDocAtSeller, \“/Customer/Credit\”) [text() = 'success'] && cdl:getState(InventoryResponseDocAtSeller, \“/Order/Inventory\”) [text()='available']">

<interact name="createOrderResponse"

onChannel="buyer-channel"

operation="createOrderResponse">

<participate relationship="BuyerSellerBinding"

fromRole="Seller"

toRole="Buyer"/>

<align state="purchaseOrderResponseDoc"

with-state="purchaseOrderResponseDoc"/>

</interact>

</react>

</choreography>

<!-- this is a sub choreography of buyerSellerChoreography

because we want to share the scope of buyer-channel

between the two. -->

<choreography

name="sellerRejectChoreography">

<relationship=”BuyerSellerBinding"/>

<react name="creditInventoryRejection"

group="ApproveOrReject"

relationshipType=”BuyerSellerBinding”

guard= "cdl:getState(CreditCheckResponseDocAtSeller, \“/Customer/Credit\”)[text='failedToApprove'] || cdl:getState(InventoryResponseDocAtSeller, \“/Order/Inventory\”)[text= 'notAvailable']">

<interact name="createOrderReject"

onChannel="buyer-channel"

operation="createOrderReject">

<participate relationship="BuyerSellerBinding"

fromRole="Seller"

toRole="Buyer"/>

<align state="purchaseOrderRejectDoc"

with-state="purchaseOrderRejectDoc"/>

</interact>

</react>

</choreography>

</react>

</choreography>

<stateType name="creditCheckRequestDoc"

documentType="creditCheckRequestDocType"/>

<stateType name="creditCheckResponseDocAtCredit"

documentType="creditCheckResponseDocType"

roleType="Credit"/>

<stateType name="seller-channel-for-credit"

channelType="tns:creditCheckResponseCHT"/>

</stateDefinitions>

<!-- When purchaseOrderDocAtSeller is available at seller,

this react is enabled -->

<react name="purcaseDocAvailibility"

relationshipType=”SellerCreditBinding”

guard="purchaseOrderDocAtSeller">

<interact name="creditCheck"

onChannel="credit-channel"

operation="checkCredit"

initiateChoreography="true">

<participate relationship="SellerCreditBinding"

fromRole="Seller"

toRole="Credit"/>

<align state="creditCheckRequestDoc"

with-state="creditCheckRequestDoc"/>

<align state="seller-channel-for-credit"

with-state="seller-channel-for-credit"/>

</interact>

<interact name="creditCheckResponse"

onChannel="seller-channel-for-credit"

operation="creditResponse">

<participate relationship="SellerCreditBinding"

fromRole="Credit"

toRole="Seller"/>

<align state="creditCheckResponseDocAtCredit"

with-state=" creditCheckResponseDocAtSeller"/>

</interact>

</react>

</choreography>

<!-- Choreography to check inventory of the products ordered

by the buyer -->

<stateType name="inventoryCheckRequestDoc"

documentType="inventoryCheckRequestDocType"/>

<stateType name="inventoryCheckResponseDocAtInventory"

documentType="inventoryCheckResponseDocType"

roleType="Inventory"/>

<stateType name="seller-channel-for-inventory"

channelType="inventoryCheckResponseCHT"/>

</stateDefinitions>

<!-- When purchaseOrderDocAtSeller is available at seller,

this react is enabled. -->

<react name="purcaseDocAvailibility"

relationshipType=”SellerInventoryBinding”

guard="purchaseOrderDocAtSeller">

<interact name="inventoryCheck"

onChannel="inventory-channel"

operation="inventoryCredit"

initiateChoreography="true">

<participate relationship="SellerInventoryBinding"

fromRole="Seller"

toRole="Inventory"/>

<align state="inventoryRequestDoc"

with-state="inventoryRequestDoc"/>

</interact>

<interact name="inventoryResponse"

onChannel="seller-channel-for-inventory"

operation="inventoryResponse">

<participate relationship="SellerInventoryBinding"

fromRole="Inventory"

toRole="Seller"/>

<align state="inventoryResponseDocAtInventory"

with-state="inventoryResponseDocAtSeller"/>

</interact>

</react>

</choreography>

</react>

</choreography>

</package>

4. Language Elements

This section describes the WS-CDL language constructs in detail. We first introduce some principles and notions that apply to all or most of the language elements.

4.1. Choreography Document Structure

A WS-CDL document is simply a set of definitions. The WS-CDL definitions are named constructs that can be referenced. There is a package element at the root, and individual Choreography type definitions inside.

4.1.1. Choreography document Naming and Linking

WS-CDL documents can be assigned an optional name attribute of type NCNAME that serves as a lightweight form of documentation. Optionally, a targetNamespace attribute of type URI may be specified. The URI MUST NOT be a relative URI. A reference to a definition is made using a QName. Each definition type has its own name scope. Names within a name scope MUST be unique within a WS-CDL document. The resolution of QNames in WS-CDL is similar to the resolution of QNames described by the XML Schemas specification [11].

4.1.2. Language Extensibility and Binding

If desired to extend the WS-CDL language, this specification allows inside a WS-CDL document the use of extensibility elements and/or attributes defined in other XML namespaces.

Extensibility elements MUST use an XML namespace different from that of WS-CDL. All extension namespaces used in a WS-CDL document MUST be declared. An extension namespace is declared by using the following syntax:

  <extension namespace="anyURI"/>*

Extensions MUST NOT change the semantics of any element or attribute from the WSCDL namespace.

4.1.3. Language Elements Naming and Documentation

WS-CDL uses the optional cdl:description attribute as a textual description for documentation purposes. This attribute is allowed inside any WS-CDL language element. The information provided by the description attribute MAY reflect the semantics of the definition if RDF is used, in which case its contents MUST be validated against a particular schema and MAY be processed mechanically by computer programs.

WS-CDL uses the required cdl:name attribute for providing a name that can be used to reference any language construct. This attribute is allowed inside any WS-CDL language element. Language construct definitions MUST have distinct names.

4.1.4. Types

The XSD type system is used to define the types in a message or state definition regardless of whether or not the resulting wire format is actually XML, or whether the resulting XSD schema validates the particular wire format.

4.2. Packaging Choreographies

The package construct allows aggregating a set of business related collaborations, where the elements documentType, tokenType, tokenLocator, roleType, relationshipTypeand channelTypeare shared by all choreographies. The targetNamespace attribute provides the namespace associated with all definitions contained in this Package. Choreography definitions imported to this Package may be associated with other namespaces. The top-level attributes name, author, version, and description define authoring properties of the Choreography document.

The syntax of this construct is:

       <package

        name="ncname"

        author=”xsd:string”?

        version=”xsd:string”

        description=”xsd:string”?

        targetNamespace="uri"

        xmlns=”http://www.w3.org/ws/choreography/2003/06/WSCDL/”>

           importDefinitions+

           documentType+

           tokenType+

           tokenLocator+

           roleType+

           relationshipType+

           channelType+

        ChoreographyNotation*

    </package>

4.2.1. Importing definitions

The importDefinitions notation allows reusing Choreography types defined in another Choreography document such as Token types, Token Locator types, Document types, Role types, Relationship types, Channel types, Choreographies. In addition, WSDL documents can be imported and their definitions reused. The namespace and location attributes provide the namespace names and document location that contain additional Choreography definitions that MUST be imported into this Package.

The syntax of this construct is:

4.3. Document types

The documentType construct specifies the type of documents exchanged between participants. The attributes wsdl:messageType, xsd:type, and xsd:element describe the document to be a WSDL message type, an XML Schema simple type, or an XML Schema element respectively. The document is of one of these types exclusively.

The syntax of this construct is:

<documentType name="ncname"
wsdl:messageType="qname"?

xsd:type=”qname”? xsd:element=”qname”? />

4.4. Token types and Token Locator types

The tokenType construct describes the naming and typing of document fragments. The named fragments are called Token types.

The syntax of this construct is:

       <tokenType  name="ncname"  type="qname" />

The tokenLocator construct defines a locator for selecting a document fragment within a document as a token using the part and the query attributes.

The attribute tokenName identifies the token that the locator refers to.

The attribute documentType identifies the type on which the query is performed to locate the token.

The optional attribute part identifies the part of the document, if any, on which the query is performed to locate the token.

The attribute query defines the query that accesses the token in the document.

The syntax of this construct is:

       <tokenLocator  tokenName="qname"

             documentType="ncname"

             part="ncname"?

             query="XPath-expression" />

4.5. Role types

The roleType construct allows the definition of the observable behavior, in terms of the operations, a participant must provide.

A role is associated with one or more Web Service interface types.

The behaviorType element defines an optional interfaceType attribute, which identifies a WSDL interface type.

A roleType that defines a behaviorType without an interfaceType describes a simple client role without any Web Service interface, i.e. it never acts as an accepting role in a relationship.

The syntax of this construct is:

            <roleType  name="ncname">

           <behaviorType  name="ncname"  interfaceType="qname"? />+

       </roleType>

4.6. Relationship types

The relationshipType construct allows the definition of the observable behavior that two collaborating participants are mutually agreeing to exhibit.

A relationshipType has two role types defined.

The optional behavior attribute points to a behavior type within the role type specified by the role type attribute.

The syntax of this construct is:

    <relationshipType  name="ncname">

       <role  type="ncname"  behavior="ncname"? />

       <role  type="ncname"  behavior="ncname"? />

        </relationshipType>

4.7. Channel types

The channelTypeconstruct defines a collaboration contact-point, used for communication and synchronization between participants.

The element usage is used to restrict the number of times a channel can be used within a Choreography.

The optional element channelDefinitions prescribes the channel(s) allowed to be exchanged from one Role to another Role, when using this Channel in an interaction. In the case where the operation used to exchange the Channel is of request-response type, then the attribute direction within the channelDefinitions element defines if the Channel will be exchanged during the request or during the response. The Channels exchanged can be used in subsequent interact activities. If the element channelDefinitions is missing then this Channel can only be used for exchanging business documents.

The element role is used to statically identify the collaboration contact-point.

The element reference MAY be used for identifying the WSDL service type of a participant. The service type of a participant is distinguished by a set of Token types as specified by the token element within the reference element.

The optional element identity MAY be used for identifying a business process type implementing a participant and for identifying a logical conversation (group of related message exchanges) between participants within a Choreography. The business process type within a participant and the different conversations between participants are distinguished by a set of Token types as specified by the token element within the identity element.

The syntax of this construct is:

        <channelType  name="ncname"

           usage=“once”|”unlimited”>

           <channelDefinitions>?

               <channel  type=”ncname”

                         direction=“request”|”respond”

                         new=”true”|”false”>+

           </channelDefinitions>

           <role  type="ncname"  behavior="ncname"? />

       <reference>

          <token  name="ncname"/>+

       </reference>

       <identity>

          <token  name="ncname"/>+

      </identity>*

        </channelType>

4.8. State Definition

The stateDefinitions provides the placeholder of the Choreography state information.

The location of the stateDefinitions defines the visibility of the state information. The state information is not available until it has been aligned with an interact activity. Once aligned, it is available in the visibility horizon of the Choreography it was defined in.

The syntax is as follows:

StateNotation*

</stateDefinitions>

The StateNotation is as follows:

§ This type of state names the business documents exchanged between participants, or exceptional conditions. The attribute documentType describes the type of the document. The attribute mutable, when set to “false” describes that the state information when initialized, cannot change anymore. The attribute observable, when set to “false” describes that the method of the state information initialization with an actual value is not of relevance to other participants. The element role is used to specify where state information resides.

The syntax of this construct is:

<stateType name="ncname"

documentType=”ncname”

mutable=”true|false”

observable=”true|false”

roleType="ncname"? />

§ This type of state names the Channel information used by interacting participants to exchange information (business documents and other channels). The attribute channelType describes the type of the Channel. The attribute mutable, when set to “false” describes that the state information when initialized, cannot change anymore. The attribute observable, when set to “false” describes that the method of the state information initialization with an actual value is not of relevance to other participants. The element role is used to specify where state information resides.

The syntax of this construct is:

<stateType name="ncname"

channelType="ncname"

mutable=”true|false”

observable=”true|false”

roleType="ncname"? />

4.8.1. Expressions

Expressions are used in a declare activity to create new state information by generating it from a constant value.

Predicate expressions are used in a Reaction to specify its guard condition.

The language used in WS-CDL for specifying expressions and query or conditional predicates is XPath 1.0.

4.9. Choreography Definition

The choreography construct allows specifying compositions of Web Service participants by asserting their common observable behaviors where computation progress occurs by exchanging messages in a predetermined order.

The relationship element within the choreography element enumerates the relationships this Choreography MAY participate in.

The stateDefinitions element enumerates the state information holders, shared between roles within this Choreography and all its enclosed activities.

The root element marks a base Choreography as the root Choreography of a Package.

A Choreography hasone or more react elements.

A react element expresses interest on of state information before enabling its enclosed activities identified by the ActivityNotation. The relationshipType attribute within the react element enumerates the relationship this react MUST participate in. A guard attribute describes the interest on the availability of zero or more, existing or future state information. If a guard is not specified then the react always matches and the activities enclosed within the react are enabled. When the state information specified by a guard become available and the guard condition (which references the matched state) evaluates to true, then the react matches and the activities enclosed within the react are enabled. A react contains one or more activities that are all enabled when the react matches. All enclosed activities are enabled concurrently by default. The sequential attribute, when set to “true”, restricts the series of enclosed activities to be enabled sequentially.

The attribute group allows specifying that a Reaction belongs to a Reaction Group. When a react matches in a Reaction Group then all other reacts belonging to the same Reaction Group are disabled.

A Choreography MAY define a recovery block using the recover element.

Within a recovery block, one Exception Choreography MAY be defined as part of the Choreography to recover from exceptional conditions that may occur in that enclosing Choreography. Within a recovery block, one compensation Choreography MAY be defined as part of the Choreography to provide the compensation activities for that enclosing Choreography.

The ChoreographyNotation is as follows:

§ Define a root or a base Choreography. A base Choreography MAY be enclosed within another Choreography using the other type of ChoreographyNotation.

The syntax of this construct is:

<choreography name="ncname"

root=”true”|”false”?>

<relationship type="ncname">+

stateDefinitions?

<react name="ncname"

group="ncname"?

sequential=”true”|”false”?

relationshipType="ncname"

guard=“xsd:boolean XPath-expression”? >

ActivityNotation+

</react>+

ChoreographyNotation

</exception>?

ChoreographyNotation

</compensation>?

</recover>?

</choreography>

§ Compose recursive Choreographies to form new Choreographies. Within the compose element the choreographyName references a base, non-root Choreography defined in the same or in a different Package.

The syntax of this construct is:

<choreography name="ncname"

root=”true”|”false”>

</choreography>

4.10. Activities Definition

An ActivityNotation is a ChoreographyNotation or an activity.

An activity describes the detailed actions of a business transaction

as follows:

4.10.1. Interact activity

The interact construct allows a Role to interact with another Role by requesting an observable operation offered by that Role. The interaction materializes when a requester Role sends state information and an accepter Role simultaneously receives the state information through a shared Channel as described by the onChannel attribute.

The attribute operation specifies a one-way or a request-response WSDL operation.

An interact activity can be marked as a Choreographyinitiator when theinitiateChoreography attribute is set to “true”.

Within the participate element, the relationship attribute specifies the Relationship this Choreography participates in and the fromRole and toRole attributes specify the requesting and the accepting Roles respectively.

The time-to-complete attribute identifies the time an interaction MUST take to complete.

The align element with the state and with-state attributes, specifies the shared state information that must be atomically aligned and made available to the two interacting participants, as specified by the fromRole and toRole attributes and the relationship attribute within the participate element, when the interact activity completes normally. In the case where the operation is of request-response type, then the attribute direction within the align element defines if the Channel will be aligned during the request or during the response.

The syntax of this construct is:

<interact name="ncname"

onChannel="ncname"

operation="ncname"

time-to-complete="xsd:duration"

initiateChoreography="true"|"false">

         <participate  relationship=”ncname”

fromRole="ncname"

toRole="ncname" />

<align state="XPath-expression"

with-state="XPath-expression"

direction=“request”|”respond”? />*

</interact>

4.10.2. Declare activity

The declare construct makes the state information available to a participant using the use element, when the condition specified by the predicate attribute evaluates to true and the declare activity completes normally.

The syntax of this construct is:

<state>

<populate name="XPath-expression"

predicate=“xsd:boolean XPath-expression”? />

</state>+

</declare>

4.10.3. Repeat activity

The repeat construct allows, when the condition specified by the predicate element evaluates to true, marking the current Reaction for repetition if it completes successfully.

The syntax of this construct is:

<repeat name="ncname"

predicate=“xsd:boolean XPath-expression”? />

4.10.4. Complete activity

The complete construct allows to explicitly complete a Choreography. The scope attribute enables the partial or the full completion of a Choreography.

The syntax of this construct is:

<complete name="ncname"

scope=”partial”|”full” />

4.10.5. Inact activity

The inact construct allows the Choreography to perform an action that has no business effect on any participant.

The syntax of this construct is:

4.10.6. Sleep activity

The sleep construct allows the Choreography to sleep for a specific time period.

The syntax of this construct is:

<sleep name="ncname"

time="xsd:duration" />

4.10.7. Compensate activity

The compensate construct allows issuing a compensate command from a parent Choreography to the Compensation Choreography of an enclosed Choreography as identified by the choreography-name attribute.

The syntax of this construct is:

5. Relationship with the Security framework

Because messages can have consequences in the real world, the collaboration participants will impose security requirements on the message exchanges. Many of these requirements can be satisfied by the use of WS-Security [25].

6. Relationship with the Reliable Messaging framework

The WS-Reliability specification [22] provides a reliable mechanism to exchange business documents among collaborating participants. The WS-Reliability specification prescribes the formats for all messages exchanged without placing any restrictions on the content of the encapsulated business documents. The WS-Reliabilityspecification supports one-way and request/response message exchange patterns, over various transport protocols (examples are HTTP/S, FTP, SMTP, etc.). The WS-Reliability specification supports sequencing of messages and guaranteed, exactly once delivery. A violation of any of these consistency guarantees results in an error condition, reflected in the Choreography as an interaction fault.

Using WS-CDL, two Web Service participants make progress by interacting. After they interact, both participants progress at the same time, in a lock-step fashion. The state information alignment comes from the fact that the requesting participant has to know that the accepting participant has received the message and the other way around, the accepting participant has to know that the requesting participant has sent the message before both of them progress. There is no intermediate state, where one participant sends a messageand then it proceeds independently or the other participant receives a message and then it proceeds independently.

Implementing this type of handshaking in a distributed system requires support from a WS- Reliability protocol, where agreement among participants can be reached even in the case of failures and loss of messages.

7. Acknowledgments

Goran Olsson for defining the CDL recovery protocol.

Ashwini Surpur, Goran Olsson, and Martin Chapman for collaborating with us to define the CDL relationships with WSDL and Business Process Languages.

Ashwini Surpur for developing the CDL example.

Jun Ding for developing the CDL XML Schemas in the appendix.

Sunil Kunisetty for collaborating with us to define the CDL relationship with the reliable messaging framework.

8. References

[1] S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, Harvard University, March 1997

[2] T. Berners-Lee, R. Fielding, L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, MIT/LCS, U.C. Irvine, Xerox Corporation, August 1998.

[3] http://www.w3.org/TR/html401/interact/forms.html#submit-format

[4] http://www.w3.org/TR/html401/appendix/notes.html#ampersands-in-uris

[5] http://www.w3.org/TR/html401/interact/forms.html#h-17.13.4

[6] Simple Object Access Protocol (SOAP) 1.1 "http://www.w3.org/TR/2000/NOTE-SOAP-20000508/"

[7] Web Services Definition Language (WSDL) 1.2

[8] Industry Initiative "Universal Description, Discovery and Integration"

[9] W3C Recommendation "The XML Specification"

[10] XML-Namespaces " Namespaces in XML, Tim Bray et al., eds., W3C, January 1999"

http://www.w3.org/TR/REC-xml-names

[11] W3C Working Draft "XML Schema Part 1: Structures". This is work in progress.

[12] W3C Working Draft "XML Schema Part 2: Datatypes". This is work in progress.

[13] W3C Recommendation "XML Path Language (XPath) Version 1.0”

[14] "Uniform Resource Identifiers (URI): Generic Syntax," RFC 2396, T. Berners-Lee, R. Fielding, L. Masinter, MIT/LCS, U.C. Irvine, Xerox Corporation, August 1998.

[15] WSCI:Web Services Choreography Interface 1.0, A.Arkin et.al

[16] XLANG: Web Services for Business Process Design

[17] WSFL: Web Service Flow Language 1.0

[18] BPEL: Business Process Execution Language 1.1

[19] BPML: Business Process Modeling Language 1.0

[20] XPDL: XML Processing Description Language 1.0

[21] WS-CAF: Web Services Context, Coordination and Transaction Framework 1.0

[22] Web Services Reliability 1.0

[23] The Java Language Specification

[24] “Active Components for J2EE: A framework for building long-lived interactions in J2EE”, N. Kavantzas, et. al, Oracle technical white paper, Oracle Corporation, 2002

[25] Web Services Security

[26] J2EE: Java 2 Platform, Enterprise Edition, Sun Microsystems

A. XSD Schemas

<?xml version="1.0" encoding="UTF-8"?>

<element name="importDefinitions" type="cdl:ImportDefinitions"

maxOccurs="unbounded"/>

<element name="documentType" type="cdl:DocumentType"

maxOccurs="unbounded"/>

<element name="tokenType" type="cdl:TokenType"

maxOccurs="unbounded"/>

<element name="tokenLocator" type="cdl:TokenLocator"

maxOccurs="unbounded"/>

<element name="roleType" type="cdl:RoleType"

maxOccurs="unbounded"/>

<element name="relationshipType" type="cdl:RelationshipType"

maxOccurs="unbounded"/>

<element name="channelType" type="cdl:ChannelType"

maxOccurs="unbounded"/>

<element name="choreography" type="cdl:Choreography"

maxOccurs="unbounded"/>

</sequence>

</complexType>

</sequence>

</complexType>

</complexType>

</complexType>

</complexType>

</complexType>

<element name="behaviorType" type="cdl:BehaviorType"

maxOccurs="unbounded"/>

</sequence>

</complexType>

</complexType>

<element name="role" type="cdl:Role" minOccurs="2"

maxOccurs="2"/>

</sequence>

</complexType>

</complexType>

<element name="channelDefinitions" type="cdl:ChannelDefinitions"

minOccurs="0" maxOccurs="unbounded"/>

<element name="role" type="cdl:Role" minOccurs="1"

maxOccurs="1"/>

<element name="operation" type="cdl:Operation" minOccurs="0"

maxOccurs="unbounded"/>

<element name="reference" type="cdl:Reference" minOccurs="1"

maxOccurs="1"/>

<element name="identity" type="cdl:Identity"

maxOccurs="unbounded"/>

</sequence>

<attribute name="usage" type="string" use="optional"

default="unlimited"/>

</complexType>

<element name="channel" type="cdl:Channel"

maxOccurs="unbounded"/>

</sequence>

</complexType>

</complexType>

</sequence>

</complexType>

</complexType>

</sequence>

</complexType>

</sequence>

</complexType>

<element name="relationship" type="cdl:Relationship"

maxOccurs="unbounded"/>

<element name="stateDefinitions" type="cdl:StateDefinitions"

minOccurs="0" maxOccurs="unbounded"/>

<element name="recover" type="cdl:Recover" minOccurs="0"

maxOccurs="unbounded"/>

</sequence>

<attribute name="root" type="boolean" use="optional"

default="false"/>

</complexType>

</complexType>

</complexType>

<element name="stateType" type="cdl:StateType"

maxOccurs="unbounded"/>

</sequence>

</complexType>

<attribute name="mutable" type="string" use="optional"

default="false"/>

<attribute name="observable" type="string" use="optional"

default="true"/>

</complexType>

</sequence>

<attribute name="sequential" type="string" use="optional"

default="false"/>

</complexType>

<element name="exception" type="cdl:Exception" minOccurs="0"

maxOccurs="unbounded"/>

<element name="compensation" type="cdl:Compensation"

minOccurs="0" maxOccurs="unbounded"/>

</sequence>

</complexType>

</sequence>

</complexType>

</sequence>

</complexType>

</choice>

</group>

<element name="align" type="cdl:Align" minOccurs="0"

maxOccurs="unbounded"/>

</sequence>

<attribute name="time-to-complete" type="duration"

use="optional"/>

<attribute name="initiateChoreography" type="boolean"

use="optional" default="false"/>

</complexType>

</complexType>

<attribute name="direction" type="string" use="optional"

default="request"/>

</complexType>

</sequence>

</complexType>

</sequence>

</complexType>

</complexType>

</complexType>

</complexType>

</complexType>

</complexType>

</complexType>

</complexType>

</schema>

B. WS-CDL Supplied Functions

There are several functions that the WS-CDL specification supplies as XPATH extension Functions. These functions can be used in any XPath expression as long as the types are compatible.

xsd:dateTime getCurrentTime()

xsd:dateTime getCurrentDate()

xsd:dateTime getCurrentDateTime()

Returns the current date/time.

xsd:string createNewID()

Returns a new globally unique string value for use as an identifier.

xsd:any* getState(xsd:string stateName, xsd:string documentPath?)

Returns the information of the state with name stateName as a node set containing a single node. The second parameter is optional. When the second parameter is not used, this function retrieves from the state information the entire document. When the second parameter is used, this function retrieves from the state information, the fragment of the document at the provided absolute location path.

xsd:boolean isStateEqual(xsd:string stateName, xsd:string withStateName)

Returns true if the state with name stateName is equal to the state with name withStateName.

C. Open Issues

§ Alignment w/ WSDL 1.2

§ Alignment w/ Xpath 2.0

§ Need to ensure alignment w/ WS-Composite Application Framework

§ Need an open standard equivalent of WS-Addressing

§ How do we model an unbounded number of role instances?

§ How do we model an unbounded number of interactions between the same two role instances?

D. WS-CDL Meta-Model

The figures below describe the meta-model for the top-level entities contained within a WS-CDL document, their relationships and attributes. The WS-CDL Meta-Model is as follows: