Editorial changes for issue 1001

SECTION 2.3.4 ChannelTypes
======================

1) Remove:

A ChannelType MAY describe the type of the instance identity of an entity implementing the behavior(s) of a party being the target of an information exchange.


2) Amend:

A ChannelType MAY describe the type of the instance identity of one or more logical conversations between parties, where each conversation groups a set of related information exchanges.

to:

A ChannelType MAY describe the type of the instance identity of one or more logical conversations between parties, 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 session.



3) Syntax change from:

   <identity>
      <token name="qname"/>+
   </identity>?
</channelType>

to:

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



4) Replace the text from "The OPTIONAL element identity MAY ....." up until the end of the section 2.3.4:


Replace:

The OPTIONAL element identity MAY be used for describing the type of the instance identity of an entity implementing the behavior of a party and of a logical conversation between parties. The type of the instance identity and the different conversations are distinguished by a set of Tokens as specified by the name attribute of the token element within the identity element.

The following rule applies for ChannelType:

    * If two or more ChannelTypes SHOULD point to roleTypes that MUST be implemented by the same logical entity or organization, then the specified roleTypes MUST belong to the same ParticipantType. In addition, the identity elements within the Channel Types MUST have the same number of Tokens with the same informationTypes specified in the same order

The example below shows the definition of the ChannelType "RetailerChannel" that realizes a point of collaboration with a Retailer. The ChannelType identifies the roleType of the Retailer as the "Retailer". The information for locating the Retailer is specified in the reference element, whereas the instance of a process implementing the Retailer is identified for correlation purposes using the identity element. The element passing allows only a Channel of "ConsumerChannel" Type to be passed in a request information exchange through a Channel of "RetailerChannel" Type.

<channelType name="RetailerChannelType">
   <passing channel="ConsumerChannelTYpe" action="request" />

   <roleType typeRef="tns:RetailerType" behavior="retailerForConsumer"/>

   <reference>
     <token name="tns:retailerRef"/>
   </reference>

   <identity>
     <token name="tns:purchaseOrderID"/>
   </identity>
</channelType>


with:

The OPTIONAL list of identity elements MAY be used to associate a unique identity for each instance of the ChannelType. The identity is defined by a set of Tokens specified by the name attribute of the token element within the identity element. If two identity elements are specified within the same or different ChannelType elements, that have the same set of named tokens in the same order, then they are considered to represent the same identity type.

The identity element has a mandatory usage attribute which defines the purpose of the identity in the context of the ChannelType. The values for this attribute are:

(i) primary

This means that the identity is created by the initial message on an instance of this ChannelType. A channel type must have only one 'primary' identity field. For example,

<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.


(ii) alternate

This classification is used to establish an alternative identity for a ChannelType instance. 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.

For example, 

<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 in the conversation, a message will be exchanged containing the 'TxnId' field. Once this message has occurred, subsequent messages on this channel instance can be correlated based on either the primary 'OrderId' field, or the alternate 'TxnId' field. 


(iii) derived

This means that the identity will be derived from a message sent on the current channel instance (conversation), but it does not directly determine the identity of that current channel instance. Subsequently another channel instance (of the same or different Channel Type) will reference this identity value in its 'primary' identity field, and that will cause the referencing channel instance to become correlated with the current channel instance in the same choreography session.

An example of the 'derived' identity would be: 

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

<channelType name="DeliveryChannel" > 
 <identity usage="primary" > 
  <token name="DeliveryId" /> 
 </identity> 
</channelType> 

In this example, the 'OrderChannel' channel instance is identified by the 'OrderId', and at some point during its conversation, it will exchange a message that contains the 'DeliveryId' information. Although this identity is not relevant from the perspective of the 'OrderChannel', it can subsequently be used to determine the identity of the 'DeliveryChannel' channel instance, and consequently bind the 'DeliveryChannel' instance to the same choreography session as the original 'OrderChannel' channel instance.


(iv) association

This classification is used to indicate that this channel instance is correlated to a previous channel instance identity, and therefore the same choreography session. The identity with this classification is not used to determine the identity of the current channel instance, only to establish the association with a previous channel instance within the same choreography session. The identity can either relate to another identity definition (in another Channel Type) that has a classification of 'primary'/'alternate', or that was derived (i.e. has the 'derived' classification). The initial message in the channel instance MUST contain the information to resolve this identity field.

An example of the 'association' identity type would be: 

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

<channelType name="SupplierChannel" > 

 <identity usage="association" > 
  <token name="OrderId" /> 
 </identity> 

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

This example shows how a choreography can contain a single 'OrderChannel' channel instance, and zero or more 'SupplierChannel' channel instances correlated with it based on an 'association' to the identity established for the 'OrderChannel' channel instance.