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 [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"<?xml" contain enough information to conform to this specification; other examples are fragments and require additional information to be specified in order to conform.

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

Where there is any discrepancy between the text of this specification, the fragments of informal schema and the full formal schema in the appendix then it is an error in the specification. Should such an error come to light please notify W3C. While awaiting resolution, the text takes priority over the formal schema in the appendix, which takes priority over the informal schema fragments.

1.2 Purpose of the Choreography Description LanguageWS-CDL

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

For the collaboration to work successfully, the rules of engagement between all the interacting partiesparticipants 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 partiesparticipants and responsibilities of each, is missing.

The Web Services ChoreographyWS-CDL specification is aimed at being able to precisely describe collaborations between any type of partyparticipant regardless of the supporting platform or programming model used by the implementation of the hosting environment.

Using the Web Services ChoreographyWS-CDL specification, a contract containing a "global" definition of the common ordering conditions and constraints under which messages are exchanged, is produced that describes, from a global viewpoint, the common and complementary observable behavior of all the partiesparticipants involved. Each partyparticipant can then use the global definition to build and test solutions that conform to it. The global specification is in turn realized by combination of the resulting local systems, on the basis of appropriate infrastructure support.

The advantage of a contract based on a global viewpoint as opposed to anyoneany one 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 sequences in which each business or system exchanges information with others. This means that, as long as the "observable" sequences do not change, the rules and logic followed within a domain of control (endpoint) can change at 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 Choreographychoreography as determined by the common or global view. It is the intent of CDLWS-CDL that the conformance of each implementation to the common view expressed in CDLtherein 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-CDLWS-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 interactions, and their common ordering and constraint rules under which the interactions occur. They then generate a Choreography Description LanguageWS-CDL based representation. In this example, a Choreographychoreography specifies the interactions between services across business entities ensuring interoperability, while leaving actual implementation decisions in the hands of each individual company:

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

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

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

1.3 Goals

The primary goal of a Choreography Description Languagethe WS-CDL specification is to specify a declarative, XML based language that defines from a global viewpoint the common and complementary observable behavior specifically, the information exchanges that occur and the jointly agreed ordering rules that need to be satisfied.

More specifically, the goals of the Choreography Description LanguageWS-CDL specification are to permit:

• Reusability. The same Choreographychoreography definition is usable by different partiesparticipants 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 partiesparticipants or processes by describing how they should cooperate

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

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

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

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

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

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

• Exception Handling. Choreographies can define how exceptional or unusual conditions that occur while the Choreographychoreography is performed are handled

• Transactionality. The processes or partiesparticipants that take part in a Choreographychoreography can work in a "transactional" way with the ability to coordinate the outcome of the long-lived collaborations, which include multiple participants, each with their own, non-observable business rules and goals

• Specification Composability. This specification willis intended to work alongside andand/or complement other specifications such as the WS-Reliability [WSRM], WS-Composite Application Framework (WS-CAF) [WSCAF], WS-Security [WSS], Business Process Execution Language for WS (WS-BPEL) [WSBPEL], ebXML Business Process Specification Schema [ebBP20], [BPSS11], etc.

1.4 Relationship with XML and WSDL

The WS-CDL specification depends on the following specifications: XML 1.0 [XML], XML-Namespaces [XMLNS], XML-Schema 1.0 [XMLSchemaP1], [XMLSchemaP2] and XPointerXPath 1.0 [XPTRF]. Support for including and 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 1.1 as constrained by WS-I Basic Profile [Action: add references][BP11] is a normative part of the WS-CDL specification.

1.5 Relationship with Business Process Languages

A Choreography Description LanguageWS-CDL is not an "executable business process description language" or an implementation 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 LanguageWS-CDL does not depend on a specific business process implementation language. Thus, it can be used to specify truly interoperable, collaborations between any type of partyparticipant 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 implementedWS-CDL may couple with other languages such as those that add further computable semantic definitions.

Each participant, adhering to a WS-CDL collaboration representation, could be implemented using completely different mechanisms such as:

• Applications, whose implementation is based on executable business process languages [XLANG], [WSFL], [WSBPEL], [BPML], [XPDL]

• Applications, whose implementation is based on general purpose programming languages [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,participants, it can be assumed that all partiesparticipants are reasonably well synchronized on second time boundaries. However, finer grained time synchronization within or across parties,participants, or additional support or control are undefined and outside the scope of the WS-CDL specification.

2 Choreography Description Language Model This section introduces1.7 Authoritative Schema

In the Web Services Choreography Description Language (WS-CDL) model. 2.1event of any ambiguity or differentiation between the WS-CDL fragments and the appendix with the full schema, the full schema takes precedence.

2.2.13.1 Choreography Package

A Choreography Packagechoreography package aggregates a set of WS-CDL type definitions, provides a namespace for the definitions and through the use of XInclude [XInclude], MAY syntactically include WS-CDL type definitions that are defined in other Choreography Packages.choreography packages.

The syntax of the package construct is:

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

   <informationType/>*
   <token/>*
   <tokenLocator/>*
   <roleType/>*
   <relationshipType/>*
   <participantType/>*
   <channelType/>*

   Choreography-Notation*
</package>

The Choreography Package contains:choreography package contains the following WS-CDL type definitions:

• Zero or more Information TypesinformationTypes

• Zero or more Tokenstokens and Token Locatorstoken locators

• Zero or more Role TypesroleTypes

• Zero or more Relationship TypesrelationshipTypes

• Zero or more Participant TypesparticipantTypes

• Zero or more Channel TypeschannelTypes

• Zero or more Package-level Choreographiespackage-level choreographies

The top-level attributes name , author , and version define authoring properties of the Choreographychoreography document.

The targetNamespace attribute provides the namespace associated with all WS-CDL type definitions contained in this Choreography Package.choreography package. WS-CDL type definitions included in this Package,package, using the inclusion mechanism, MAY be associated with other namespaces.

The elements informationType , token , tokenLocator , roleType , relationshipType , participantType and channelType MAY be used as elements by all the Choreographieschoreographies defined within this Choreography Package. 2.2.2choreography package.

3.2 Including WS-CDL Type Definitions

WS-CDL type definitions or fragments of WS-CDL type definitions can be syntactically reused in any WS-CDL type definition by using XInclude [XInclude]. The assembly of large WS-CDL type definitions from multiple smaller, well-formed WS-CDL type definitions or WS-CDL type definitions fragments is enabled using this mechanism.

Inclusion of fragments of other WS-CDL type definitions SHOULDshould be done carefully in order to avoid duplicate definitions (Variables,(variables, blocks, etc.). A WS-CDL processor MUST ensure that the document is correct before processing it. The correctness may involve XML well-formedness as well as semantic ;checks, such as unicity of Variable definitions, ofa single root Choreography, etc.conforming WS-CDL document [Conforming Document]. It MAY verify that the document conforms to the provided schema [WS-CDL Schema].

The example below shows some possible syntactic reuses of ChoreographyWS-CDL type definitions.

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

2.2.33.3 WS-CDL document Naming and Linking

WS-CDL documents MUST be assigned a name attribute of type NCNAME that serves as a lightweight form of documentation.

The targetNamespace attribute of type URI MUST be specified.

The URI MUST NOT be a relative URI.

A reference to a definition isMUST be made using a QName."QName".

Each definitionWS-CDL type definition has its own name scope.

Names within a name scope MUST be unique within athe WS-CDL document.

The resolution of QNamesa "QName" in WS-CDL is similar to the resolution of QNamesa "QName" as described by the XML Schemas specification [XMLSchemaP1].

2.2.43.4 Language Extensibility

and BindingTo support extending the WS-CDL language, this specification allows the use of extensibility elements and/or attributes defined in other XML namespaces.namespaces inside any WS-CDL language element.

Extensibility elements and/or attributes MUST use an XML namespace different from that of WS-CDL.

All extension namespaces used in a WS-CDL document MUST be declared.

Extensions MUST NOT changecontradict the semantics of any element or attribute from the WS-CDL namespace.

2.2.53.5 Semantics

Within a WS-CDL document, descriptions allow the recording ofmay reference semantic definitions and other documentation. The OPTIONAL description sub-element is allowed inside any WS-CDL language element. Descriptions MAY be text or document references defined in multiple different human readable languages. Where machine processable, WS-CDL parsers are not required to parse the contents of the description .sub-element.

The information provided by the description sub-element will allow forreference the recording of semanticsdescriptions in any or all of the following ways:areas:

• Text. This will be in plain text or possiblyPlain text, HTML and should be briefor other non-encoded text formats may apply (e.g. text/plain, text/html, text/sgml, text/xml, etc.).

• Document Reference. This willMAY contain a URI to a document that more fully describes the componentcomponent.

• Machine Oriented Semantic Descriptions. This willMAY contain machine processable definitions in languages such as RDF [RDF] or OWL Descriptions that are text[OWL]. This description MAY contain a URI.

The semantics of any element or document references canattribute from the WS-CDL namespace SHOULD remain unchanged and MUST NOT be defined in multiple different human readable languages. 2.3contradicted.

4.1 RoleType

A roleType enumerates potential observable behavior a party exhibitsparticipant can exhibit in order to collaborate with other parties.interact. For exampleexample, the "Buyer" Role TyperoleType is associated with the purchasing of goods or services and the "Supplier" Role TyperoleType is associated with providing those goods or services for a fee.

The syntax of the roleType construct is:

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

The attribute name is used for specifyingto specify a distinct name for each roleType element declared within a Choreography Package.choreography package.

Within the roleType element, thea behavior element specifies a subset of the observable behavior a partyparticipant exhibits. A Role TyperoleType MUST contain one or more behavior elements. The attribute name within the behavior element is used for specifyingto specify a distinct name for each behavior element declared within a roleType element.

The behavior element defines an OPTIONAL interface attribute, which identifies a WSDL interface type. A behavior without an interface describes a Role TyperoleType that is not required to support a specific Web Service interface.

2.3.2 Relationship Types4.2 RelationshipType

A Relationship TyperelationshipType identifies the Role TypesroleTypes and Behaviors,behaviors, where mutual commitments between two partiesMUST be made for themcollaborations to collaborate successfully.be successful. For exampleexample, the Relationship TypesrelationshipTypes between a Buyer"Buyer" and a Seller"Seller" could include:

• A "Purchasing" Relationship Type,relationshipType, for the initial procurement of goods or services, and

• A "Customer Management" Relationship TyperelationshipType to allow the Supplier"Supplier" to provide service and support after the goods have been purchased or the service provided

Although Relationship TypesrelationshipTypes are always between two Role Types, ChoreographiesroleTypes, choreographies involving more than two Role TypesroleTypes are possible. For exampleexample, if the purchase of goods involved a third-party Shipper"Shipper" contracted by the Supplier"Supplier" to deliver the Supplier's"Supplier's" goods, then, in addition to the "Purchasing" and "Customer Management" Relationship TypesrelationshipTypes described above, the following Relationship TypesrelationshipTypes might exist:

• A "Logistics Provider" Relationship TyperelationshipType between the Supplier"Supplier" and the Shipper,"Shipper", and

• A "Goods Delivery" Relationship TyperelationshipType between the Buyer"Buyer" and the Shipper"Shipper"

The syntax of the relationshipType construct is:

<relationshipType  name="ncname"> <role type="qname"name="NCName">
   <roleType typeRef="QName" behavior="list of  ncname"?NCName"? />
    <role type="qname"<roleType typeRef="QName" behavior="list of  ncname"?NCName"? />
</relationshipType>

The attribute name is used for specifyingto specify a distinct name for each relationshipType element declared within a Choreography Package.choreography package.

A relationshipType element MUST have exactly two Role TypesroleTypes defined. Each Role TyperoleType is specified by the typetypeRef attribute within the roleroleType element. The "QName" value of the typeRef attribute of the roleType element MUST reference the name of a roleType.

Within each roleroleType element, the OPTIONAL attribute behavior identifies the commitment of a partyparticipant as an XML-Schema list of behavior types belonging to this Role Type.roleType. If the behavior attribute is missing then all the behaviors belonging to this Role TyperoleType are identified as the commitment of a party. 2.3.3 Participant Types A Participant Type identifies a set of Role Types that MUST be implemented byparticipant. If the same logical entity or organization. Its purposebehavior attribute is present then the behaviors listed MUST be a proper subset of those belonging to groupthis roleType.

4.3 ParticipantType

A participantType groups together thethose parts of the observable behavior that MUST be implemented by the samea participant . A logical entity or organization.organization MAY be represented by more than one participantType within a choreography.

The syntax of the participantType construct is:

<participantType  name="ncname"> <role type="qname"name="NCName">
   <roleType typeRef="QName" />+
</participantType>

The attribute name is used for specifyingto specify a distinct name for each participantType element declared within a Choreography Package.choreography package.

Within the participantType element, one or more roleroleType elements identify the Role TypesroleTypes that MUST be implemented by this Participant Type.participantType. Each Role TyperoleType is specified by the typetypeRef attribute of the roleroleType element. The "QName" value of the typeRef attribute of the roleType element MUST reference the name of a roleType. A specific Role TyperoleType MUST NOT be specified in more than one participantType element.

An example is givenshown below where the "SellerForBuyer" Role TyperoleType belonging to a "Buyer-Seller" Relationship TyperelationshipType is implemented by the Participant TypeparticipantType "Broker" which also implements the "SellerForShipper" Role TyperoleType belonging to a "Seller-Shipper" Relationship Type:relationshipType.

<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"<roleType typeRef="tns:Buyer" />
     <role type="tns:SellerForBuyer"<roleType typeRef="tns:SellerForBuyer" />
</relationshipType>
<relationshipType name="Seller-Shipper">
     <role type="tns:SellerForShipper"<roleType typeRef="tns:SellerForShipper" />
     <role type="tns:Shipper"<roleType typeRef="tns:Shipper" />
</relationshipType>

<participantType name="Broker">
    <role type="tns:SellerForBuyer"<roleType typeRef="tns:SellerForBuyer" />
    <role type="tns:SellerForShipper"<roleType typeRef="tns:SellerForShipper" />
</participantType>

2.3.4 Channel Types4.4 ChannelType

A ChannelchannelType realizes a point of collaboration between partiesparticipantTypes by specifying where and how information is exchanged between collaborating parties.exchanged. Additionally, Channel informationchannelType instance information, captured within channel variables, can be passed among partiesparticipants in information exchanges. The ChannelschannelType instances exchanged MAY be used in subsequent Interactioninteraction activities. This allows the modeling of both static and dynamic message destinations when collaborating within a Choreography.choreography. For example, a Buyer"Buyer" could specify ChannelchannelType instance information to be used for sending delivery information. The Buyer"Buyer" could then send the Channelthis channelType instance information to the Seller"Seller" who then forwards it to the Shipper."Shipper". The Shipper"Shipper" could then send delivery information directly to the Buyer"Buyer" using the ChannelchannelType instance information originally supplied by the Buyer."Buyer".

A Channel TypechannelType MUST describe the Role TyperoleType and the referencetype of a party,participant reference, conveying the information needed to address the participant being the target of an information exchange, either a receiver of a request action or a sender of a reply action, which is thenused for determining where and how to send or receive information to or intofrom the party.participant.

A Channel TypechannelType MAY specify the instance identity of an entity implementingdescribe the behavior(s)type of a party, beingthe targetinstance identity of an information exchange. A Channel Type MAY describeone or more logical conversations between parties,participants, where each conversation groups a set of related information exchanges. The channelType instance identity can be used to correlate multiple conversations (channel instances) within the same choreography instance.

One or more Channel(s)channelType instances MAY be passed around from one partyparticipant to another in an information exchange. A Channel TypechannelType MAY be used to:

• Restrict the number of times a Channelan instance of this Channel TypechannelType can be used

• Restrict the type of information exchange that can be performed when using a Channelan instance of this Channel TypechannelType

• Restrict the Channel Type(s)channelTypes that will be passed through a Channelan instance of this Channel TypechannelType

• Enforce that a passed Channelchannel instance is always distinctunique

The syntax of the channelType construct is:

<channelType   name="ncname" usage="once"|"unlimited"?name="NCName"
              usage="once"|"distinct"|"shared"?
              action="request-respond"|"request"|"respond"? >

   <passing   channel="qname"channel="QName"
             action="request-respond"|"request"|"respond"?
             new="true"|"false"? />*

    <role type="qname" behavior="ncname"?<roleType typeRef="QName"  behavior="NCName"? />

   <reference>
      <token  name="qname"/>name="QName"/>
   </reference>

    <identity><identity usage="primary"|"alternate"|"derived"|"association">
      <token  name="qname"/>+ </identity>?name="QName"/>+
   <identity>*
</channelType>

The attribute name is used for specifyingto specify a distinct name for each channelType element declared within a Choreography Package.choreography package.

The OPTIONAL attribute usage is used to restrictconstrain the number of times a Channelway in which an instance of this Channel TypechannelType, can be used. The OPTIONAL attribute action is used to restrict the type of information exchangevalues that can be performed when usingused for this attribute are:

1. "once" - Once means that a Channelchannel instance of this Channel Type. The type of information exchange performed could eitherchannelType can be a request-respond exchange, a request exchange,used for one interaction, or can be passed to another roleType. When a respond exchange. The default forchannel instance of this attributechannelType is set to "request". The OPTIONAL element passing describespassed, the Channel Type(s)passer of the Channel(s)channel instance MUST relinquish control, for outputting only, of that are passed, from one partyinstance and passes control to another, when using an information exchange on a Channelthe receiver. A channel instance of this Channel Type. The OPTIONAL attribute action within the passing element defines ifchannelType MUST NOT be passed to more than one receiver at any one time.

2. "distinct" (default usage mode) - Distinct means that a Channel willchannel instance of this channelType can be used multiple times by a participantType within multiple interactions. When a channel instance of this channelType is passed, the passer of the channel instance MUST relinquish control, for outputting only, of that instance and passes control to the receiver. A channel instance of this channelType MUST NOT be passed by a participantType to more than one receiver. In this mode, a participantType MUST NOT specify two or more concurrent interactions for the same channel instance with the same operation name.

3. "shared" - Shared means that a channel instance of this channelType can be used multiple times by multiple participantTypes within multiple interactions. When a channel instance of this channelType is passed, the participantType passing the channel instance MUST NOT relinquish control. In this mode, a participantType MUST NOT specify two or more concurrent interactions for the same channel instance with the same operation name.

The OPTIONAL attribute action is used to restrict the type of information exchange that can be performed when using a channel instance of this channelType. The type of information exchange performed could either be a request-respond exchange, a request exchange, or a respond exchange. The default value for this attribute is "request".

The OPTIONAL element passing describes the channelTypes of the channel instances that are passed from one participant to another when using an information exchange on a channel instance of this channelType. The OPTIONAL attribute action within the passing element, defines when a channel instance MUST be passed, either during a request exchange, during a response exchange or both. The default value for this attribute is set to"request". The OPTIONAL attribute new within the passing elementelement, when set to "true""true", enforces a passed Channelchannel instance to be always distinct.unique. If the element passing is missingmissing, then this Channel TypechannelType MAY be used for exchanging informationinformation, but MUST NOT be used for passing Channelschannel instances of any Channel Type.channelType.

The element roleroleType is used to identify the Role TyperoleType of a party,participant, being the targettype of the target of an information exchange, which is then used for statically determining where and how to send or receive information to or intofrom the participant. Each roleType is specified by the party.typeRef attribute of the roleType element. The "QName" value of the typeRef attribute of the roleType element MUST reference the name of a roleType defined in the choreography package. Within the roleType element, the OPTIONAL attribute behavior identifies a specific observable behavior, belonging to the roleType that is used for describingthe target of an information exchange. If the behavior attribute is missing, then any one of the behavior types belonging to this roleType MAY be the target of an information exchange.

The element reference is used to specify the type of a party,participant reference, conveying the information needed to address the participant being the target of an information exchange, which is thenused for dynamically determining where and how to send or receive information to or intofrom the party.participant. The referencetype of a partyparticipant reference is distinguished by a Tokentoken, as specified by the name attribute of the token element within the reference element.

The OPTIONAL elementlist of identity elements MAY be used to associate a unique identity for identifying aneach instance of an entity implementingthe behavior of a party and for identifying a logical conversation between parties.channelType. The identity and the different conversations are distinguishedis defined by a set of Tokens astokens specified by the name attribute of the token element within the identity element. The following rule applies for Channel Type:If two or more Channel Types SHOULD point to Role Types that MUST be implemented by the same logical entity or organization, then the specified Role Types MUST belong to the same Participant Type. In addition, theidentity elements are specified within the Channel Types MUSTsame or different channelType elements, and they have the same numberset of Tokens withnamed tokens in the same informationTypes specified inorder, then they are considered to represent the same orderidentity type.

The example below showsidentity element has a mandatory usage attribute, which defines the definitionpurpose of the Channel Type "RetailerChannel" that realizes a pointidentity in the context of collaboration with a Retailer.the channelType. The Channel Type identifiesvalues for this attribute are:

1. "primary" - The 'primary' usage classification means that the Role Type ofidentity is created by the Retailer asinitial message on an instance of this channelType. A channelType must have only one 'primary' identity field.

   An example for using this attribute is shown below.

   <channelType name="OrderChannel">
     …
     <identity usage="primary">
       <token name="OrderId" />
     </identity>
   </channelType>
   

   This means that all messages (requests and responses) exchanged on this "OrderChannel" must contain the 'OrderId' field.

2. "alternate" - The 'alternate' usage classification means that an alternative identity for a channelType instance can be established. The alternate identity can be initialized based on any message within the channel instance's conversation (i.e. it does not have to be the first). If it is not the first message, then the message must also contain either the channel instance's primary key, or another previously initialized alternate identity, to bind the identity to the channel instance. Once the alternate identity has been bound to the channel instance, subsequent messages that only contain that alternate identity will be correlated to the channel instance.

   An example for using this attribute is shown below.

   <channelType name="OrderChannel">
     …
     <identity usage="primary">
       <token name="OrderId" /> 
     </identity> 
     <identity usage="alternate"> 
       <token name="TxnId" />
     </identity>
   </channelType>
   

   In this example, an "OrderChannel" channel instance will be identified initially by the value of the 'OrderId' field. However, at some point i