Web Services Choreography Description Language Version 1.0

1.1 Notational Conventions

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].[RFC2119].

The following namespace prefixes are used throughout this document:

This specification uses an informal syntax to describe the XML grammar of a WS-CDL 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/><element. . ./> or <element>)<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; othersother examples are fragments and require additional information to be specified in order to conform.

An XSD schemas areis provided as a formal definition of WS-CDL grammar (see Section 9).11).

1.2 Purpose of the Choreography Description Language

Business or other activities that involve multipledifferent organizations or independent processes are engaged in a collaborative fashion to achieve a common business goal, such as Order Fulfillment.Fulfillment.

For the collaboration to work successfully, the rules of engagement between all the interacting parties must be provided. Whereas today these rules are frequently written in English, a standardized way for precisely defining these interactions, leaving unambiguous documentation of the parties and responsibilities of each, is missing.

The Web Services Choreography specification is targeted foraimed at being able to precisely describing peer-to-peerdescribe collaborations between any type of party regardless of the supporting platform or programming model used by the implementation of the hosting environment.

Using the Web Services Choreography specification, a contract containing a "global" definition of the common ordering conditions and constraints under which messages are exchangedexchanged, is produced that describesdescribes, from a global viewpointviewpoint, the common and complementary observable behavior of all the parties involved. Each party can then use the global definition to build and test solutions that conform to it. The mainglobal specification is in turn realized by combination of the resulting local systems, on the basis of appropriate infrastructure support.

The advantage of a contract withbased on a global definition approachviewpoint as opposed to anyone endpoint is that it separates the overall "global" process being followed by an individual business or system within a "domain of control" (an endpoint) from the definition of the sequencesequences in which each business or system exchanges information with others. This means that, as long as the "observable" sequence doessequences do not change, the rules and logic followed within thea domain of control (endpoint) can change at will.will and interoperability is therefore guaranteed.

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 within a collaboration can be clearly defined and agreed to, jointly. Each entity may then implement its portion of the Choreography as determined by the common or global view. It is the intent of CDL that the conformance of each implementation to the common view expressed in CDL is easy to determine.

The figure below demonstrates a possible usage of the Choreography Description Language.

Figure 1: Integrating Web Services based applications using WS-CDL

In Figure 1, Company A and Company B wish to integrate their Web Services based applications. The respective business analysts at both companies agree upon the services involved in the collaboration, their interactionsinteractions, and their common ordering and constraint rules under which the interactions occur andoccur. They then generate a Choreography Description Language based representation. In this example, a Choreography specifies the interoperability andinteractions between services across business entities,entities ensuring interoperability, while leaving actual implementation decisions in the hands of each individual company:

• Company "A" relies on a WS-BPEL [18][WSBPEL] solution to implement its own part of the Choreography

• Company "B", having greater legacy driven integration needs, relies on a J2EE [25][J2EE] solution incorporating Java and Enterprise Java Bean Components or a .NET [26][C#S] solution incorporating C# to implement its own part of the Choreography

Similarly, a Choreography can specify the interoperability and interactions between services within one business entity.

1.3 Goals

The primary goal of a Choreography Description Language is to specify a declarative, XML based language that defines from a global viewpoint the common and complementary observable behavior, where messagebehavior specifically, the information exchanges occur,that occur and whenthe jointly agreed ordering rules arethat need to be satisfied.

Some additionalMore specifically, the goals of this definition languagethe Choreography Description Language are to permit:

• Reusability. The same Choreography definition is usable by different parties operating in different contexts (industry, locale, etc.) with different software (e.g. application software)

• Cooperation. Choreographies define the sequence of exchanging messages between two (or more) independent parties or processes by describing how they should cooperate

• Multi-Party Collaboration. Choreographies can be defined involving any number of parties or processes

• Semantics. Choreographies can include human-readable documentation and semantics for all the components in the Choreography

• Composability. Existing Choreographies can be combined to form new Choreographies that may be reused in different contexts

• Modularity.Modularity. Choreographies can be defined using an "inclusion" facility that allows a Choreography to be created from parts contained in several different Choreographies

• Information Driven Collaboration. Choreographies describe how parties make progress within a collaboration, when recordingsthrough the recording of exchanged information and changes to observable information changesthat cause ordering constraints to be fulfilled and progress to be made

• Information Alignment. Choreographies allow the parties that take part in Choreographies to communicate and synchronize their observable information

• changes and the actual values of the exchanged information as wellException Handling. Choreographies can define how exceptional or unusual conditions that occur while the Choreography is performed are handled

• Transactionality. The processes or parties that take part in a Choreography can work in a "transactional" way with the ability to coordinate the outcome of the long-lived collaborations, which include multiple, often recursive collaboration units,multiple participants, each with its owntheir own, non-observable business rules and goals

• Specification Composability. This specification will work alongside and complement other specifications such as the WS-Reliability [22],[WSRM], WS-Composite Application Framework (WS-CAF) [21],[WSCAF], WS-Security [24],[WSS], Business Process Execution Language for WS (WS-BPEL) [18],[WSBPEL], etc.

1.4 Relationship with XML and WSDL

ThisThe WS-CDL specification depends on the following specifications: XML 1.0 [9],[XML], XML-Namespaces [10],[XMLNS], XML-Schema 1.0 [11, 12][XMLSchemaP1], [XMLSchemaP2] and XPointer [XPTRF]. Support for including and XPath 1.0 [13].referencing service definitions given in WSDL 2.0 [WSDL20] is a normative part of the WS-CDL specification. In addition, support for including and referencing service definitions given in WSDL 2.0 [7]1.1 as constrained by WS-I Basic Profile [Action: add references] is a normative part of thisthe WS-CDL specification.

1.5 Relationship with Business Process Languages

A Choreography Description Language is not an "executable business process description language" [16, 17, 18, 19, 20]or an implementation language [23].language. The role of specifying the execution logic of an application will be covered by these [XLANG], [WSFL], [WSBPEL], [BPML], [XPDL], [JLS], [C#S] and other specifications.

A Choreography Description Language does not depend on a specific business process implementation language. Thus, it can be used to specify truly interoperable, peer-to-peercollaborations between any type of party regardless of the supporting platform or programming model used by the implementation of the hosting environment. Each party, adhering to a Choreography Description Language collaboration representation, could be implemented using completely different mechanisms such as:

• Applications, whose implementation is based on executable business process languages [16, 17, 18, 19, 20][XLANG], [WSFL], [WSBPEL], [BPML], [XPDL]

• Applications, whose implementation is based on general purpose programming languages [23, 26][JLS], [C#S]

• Or human controlled software agents

1.6 Time Assumptions

Clock synchronization is unspecified in the WS-CDL technical specification and is considered design-specific. In specific environments between involved parties, it can be assumed that all parties are reasonably well synchronized on second time boundaries. However, finer grained time synchronization within or across parties, or additional support or control are undefined and outside the scope of the WS-CDL specification.

2.1 WS-CDL Model Overview

WS-CDL describes interoperable, peer-to-peer collaborations between parties. In order to facilitate these collaborations, services commit onto mutual responsibilities by establishing Relationships. Their collaboration takes place in a jointly agreed set of ordering and constraint rules, whereby messages areinformation is exchanged between the parties.

The ChoreographyWS-CDL model consists of the following notations: Participants, Rolesentities:

• Participant Types, Role Types and RelationshipsRelationship Types - InWithin a Choreography, information is always exchanged between Participantsparties within the sameor across trust boundaries Types, Variables and Tokens - Variables contain information about commonlyboundaries. A Role Type enumerates the observable behavior a party exhibits in order to collaborate with other parties. A Relationship Type identifies the mutual commitments that must be made between two parties for them to collaborate successfully. A Participant Type is grouping together those parts of the observable behavior that must be implemented by the same logical entity or organization

• Information Types, Variables and Tokens - Variables contain information about commonly observable objects in a collaboration, such as the messagesinformation exchanged or the observable information of the Roles involved. Tokens are aliases that can be used to reference parts of a Variable. Both Variables and Tokens have Types that define the structure of what the Variable contains or the Token containsreferences

• Choreographies - A Choreography allows definingChoreographies define collaborations between interacting peer-to-peerparties:

  • Choreography Composition allows the creation of new Choreographies by reusing existing Choreography definitionsLife-line - The Choreography Life-line expresses the progression of a collaboration. Initially, the collaboration is started at a specific business process,established between parties, then work is performed by following the Choreographywithin it and finally the Choreography completes,it completes either normally or abnormally

  • Choreography Recovery consists of: ChoreographyException BlockBlocks - describes how to specifyAn Exception Block specifies what additional interactions should occur when a Choreography behaves in an abnormal way

  • Choreography Finalizer BlockBlocks - A Finalizer Block describes how to specify whatadditional interactions that should occur to reversemodify the effect of an earlier successfully completed ChoreographyChoreography, for example to confirm or undo the effect

• Channels - A Channel realizes a point of collaboration between parties by specifying where and how information is exchanged

• WorkUnitsWork Units - A Work Unit prescribes the constraints that must be fulfilled for making progress and thus performing actual work within a Choreography

• Activities and Ordering Structures - Activities are the lowest level components of the Choreography that perform the actual work. Ordering Structures combine activities with other Ordering Structures in a nested structure to express the ordering conditions in which the messages ininformation within the Choreography areis exchanged

• Interaction Activity - An Interaction is the basic building block of a Choreography, which results in an exchange of messagesinformation between parties and possible synchronization of their observable information changes and the actual values of the exchanged information

• Semantics - Semantics allow the creation of descriptions that can record the semantic definitions of every singlecomponent in the model

2.2 ChoreographyWS-CDL Document Structure

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

<package  
   name="ncname" 
   author="xsd:string"?
    version="xsd:string"version="xsd:string"?
   targetNamespace="uri"
    xmlns="http://www.w3.org/2004/10/ws-chor/cdl/">xmlns="http://www.w3.org/2004/12/ws-chor/cdl">
   informationType*
   token*
   tokenLocator*
   roleType*
   relationshipType*
   participantType*
   channelType*
   Choreography-Notation*
</package>

<choreography name="newChoreography" root="true">
...
   <variable name="newVariable" informationType="someType"
             role="randomRome"/>
   <xi:include href="genericVariableDefinitions.xml" />
   <xi:include href="otherChoreography.xml"
               xpointer="xpointer(//choreography/variable[1]) />
... 
</choreography>

2.3 Collaborating Parties

The WSDL specification [7][WSDL20] describes the functionality of a service provided by a party based on a stateless, client-server model. The emerging Web Based applications require the ability to exchange messagesinformation in a peer-to-peer environment. In these types of environments a party represents a requester of services provided by another party and is at the same time a provider of services requested from other parties, thus creating mutual multi-party service dependencies.

A WS-CDL document describes how a party is capable of engaging in peer-to-peercollaborations with the same party or with different parties.

The Role Types, Participant Types, Relationship Types and Channel Types define the coupling of the collaborating parties.

<roleType name="ncname">
   <behavior name="ncname" interface="qname"? />+
</roleType>

<relationshipType name="ncname">
   <role type="qname" behavior="list of ncname"? />
   <role type="qname" behavior="list of ncname"? />
</relationshipType>

<participantType name="ncname">
   <role type="qname" />+
</participantType>

<roleType name="Buyer">
   . . .
</roleType>
<roleType name="SellerForBuyer">
    <behavior name="sellerForBuyer" interface="rns:sellerForBuyerPT"/>
</roleType>
<roleType name="SellerForShipper">
    <behavior name="sellerForShipper" interface="rns:sellerForShipperPT"/>
</roleType>
<roleType name="Shipper">
   . . .
</roleType>
<relationshipType name="Buyer-Seller">
    <role type="tns:Buyer" />
    <role type="tns:SellerForBuyer" />
</relationshipType>
<relationshipType name="Seller-Shipper">
    <role type="tns:SellerForShipper" />
    <role type="tns:Shipper" />
</relationshipType>
<participantType name="Broker">
   <role type="tns:SellerForBuyer" />
   <role type="tns:SellerForShipper" />
</participantType>

<channelType  name="ncname"
              usage="once"|"unlimited"?
              action="request-respond"|"request"|"respond"? >
   <passing  channel="qname"
             action="request-respond"|"request"|"respond"?
              new="xsd:boolean"?new="true"|"false"? />*
   <role  type="qname"  behavior="ncname"? />
   <reference>
      <token  type="qname"/>name="qname"/>
   </reference>
   <identity>
      <token  type="qname"/>+name="qname"/>+
   </identity>?
</channelType>

<channelType name="RetailerChannel">
   <passing channel="ConsumerChannel" action="request" />
   <role type="tns:Retailer" behavior="retailerForConsumer"/>
   <reference>
     <token  type="tns:retailerRef"/>name="tns:retailerRef"/>
   </reference>
   <identity>
     <token  type="tns:purchaseOrderID"/>name="tns:purchaseOrderID"/>
   </identity>
</channelType>

2.4 Information Driven Collaborations

Parties make progress within a collaboration,collaboration when recordings of exchanged information are made, and changes to observable information changesoccur, that then cause ordering constraints to be fulfilled. A WS-CDL document allows defining information within a Choreography that can influence the observable behavior of the collaborating parties.

Variables capture information about objects in the Choreography, such as the messagesinformation exchanged or the observablesobservable information of the Roles involved. TokenTokens are aliases that can be used to reference parts of a Variable .Variable. Both Variables and Tokens have Information Types that define the type of information the Variable contains or the Token contain.references.

<informationType  name="ncname"; type="qname"? | element="qname"?name="ncname" 
                 type="qname"?|element="qname"? 
                 exceptionType="true"|"false"? />

Example1: The informationType "purchaseOrder" refers to the WSDL 1.1 Message type "pns:purchaseOrderMessage"
   <informationType name="purchaseOrder" type="pns:purchaseOrderMessage"/>

Example2: The informationType "customerAddress" refers to the WSDL 2.0 Schema element "cns:CustomerAddress"
   <informationType name="customerAddress" element="cns:CustomerAddress"/>

Example 3: The informationType "intType" refers to the XML Schema type "xsd:int"
   <informationType name="intType" type="xsd:int"/>

Example 4: The informationType "OutOfStockExceptionType" is of type Exception Type and refers to the WSDL 2.0 fault name "cwns:OutOfStockExceptionType"
   <informationType name="OutOfStockExceptionType"         
                    type="cwns:OutOfStockExceptionType" exceptionType="true"/>

<variableDefinitions>
   <variable   name="ncname"
        informationType="qname"|channelType="qname"informationType="qname"?|channelType="qname"?
       mutable="true|false"?
       free="true|false"?
        silentAction="true|false"? roleType="qname"?silent="true|false"?
       roleTypes="list of qname"? />+
</variableDefinitions>