Outline proposal for issue 1001

Session Identity Outline Proposal 
========================

(28th February 2005) 

Introduction 
========

Currently the CDL specification is restricted in its ability to define how messages are associated with a particular channel instance, as all messages on that channel instance must have the key 'identity' field defined within its channel type. It is also not possible at present to declaratively specify how multiple instances of the same channel type, or different channel types, are associated with a single instance of the choreography within which they are defined. 

There are two situations that need to be catered for within a mechanism that binds channel instances  to a choreography session: 

1) Chaining Identity 

This is where the identity of a subsequent channel instance has no relationship with the identity of the initial channel instance that initiates the choreography session. In this situation, the only solution is for the proceeding channel instance (or the initial channel in this case) to derive the subsequent channel instance's identity before that subsequent channel instance is created. 

2) Parent/Child Relationship 

This is where a choreography session may be initiated with a channel instance (i.e. the parent channel), which then leads to multiple channel instances (generally of the same channel type) that are dividing the workload, before reporting back to the parent channel instance. In this situation, the identity of the multiple channel instances must be unique, but at the same time have some relationship with the parent channel instance, to enable them to be bound to the same choreography session. 


Possible Solution 
=============

To address the first issue, which is to remove the restriction of all messages sent on a channel instance having to include the field(s) that relate to the single channel instance identity, we propose having the ability to declare more than one 'identity' tag for the channel type. Also, as identity information will need to be shared across channel types (to support the second issue), we will infer that the identity definitions across channel types are equivalent if they have the same set of tokens in the same order.

For example, 

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

In this example, the OrderChannel will pass a sequence of messages which will be correlated to the channel instance based on one of two identity fields (order or supplierTxn). As the 'order' identity has been classified as 'primary', it means that this identity must exist within the initial message sent on the channel instance. 

The 'alternate' classification means that this identity will be determined based on the contents of a message that will be passed on this channel instance, although the relevant information may not be contained within the first message. Once this alternate identity has been initialized, it will be used as an alternate unique key related to the same channel instance. 

NOTE: To establish the association with the channel instance, the message that initializes the alternate identity must also contain the value of atleast one other identity field that is associated with that channel instance. 

The above solution extends the current CDL approach, by avoiding all messages on a channel instance having to contain a single identity field.

The second issue concerns how to bind multiple channel instances, each with different identities, to the same choreography instance. The approach that we propose is to bind channel instances, by establishing relationships between their identities. 

To achieve this we introduce the following 'usage' options for the identity elements: 

(i) usage="primary"
This means that the identity is created by the initial message on this channel instance. A channel type must have only one 'primary' identity field.

(ii) usage="derived"
This means that the associated identity has been derived from a message sent on the current channel instance, but it does not directly determine the identity of that current channel instance. Subsequently another channel instance will reference this identity value in its 'primary' identity field, and that will cause the referencing channel instance to become associated with the current
channel instance.

(iii) usage="association"
This classification is used to indicate that this channel instance is related to a previous channel instance identity. 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 named identity can either relate to another identity that
has a classification of 'primary', or that was derived (i.e. has the 'derived' classification). The initial message on the channel instance MUST contain the information to resolve this identity field.

(iv) usage="alternate"
This classification is used to establish alternative identity keys for the same channel instance. Therefore these identities are only relevant within the scope of the channel instance.


NOTE: If a channel instance is not the first within a choreography session (i.e. the initiating channel instance), then the channel instance's type must declare how it is associated with an existing channel instance, either through the use of a 'primary' identity that relates to a previously (unused) 'derived' identity, or by having an 'association' identity. 

An example of the 'chaining identities' solution would be: 

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

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

In this example, the order channel is identified by the 'order' identity, and at some point during its interactions, it will exchange a message that contains the information relevant to the 'delivery' identity. Although this identity is not relevant for the perspective of the OrderChannel, it can subsequently be used to determine the identity related to messages on the DeliveryChannel instance. However, unlike the OrderChannel which had its identity established when the first message arrived, the DeliveryChannel already has its identity defined before the first message arrives, and therefore is subscribing for a message with the correct (delivery) identity. 

An example of the 'parent/child relationship' solution would be: 

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

<channelType name="SupplierChannel" > 
   <identity name="order" usage="association" > 
      <token name="OrderId" /> 
   </identity> 
   <identity name="supplier" usage="primary" > 
      <token name="SupplierName" /> 
      <token name="OrderId" /> 
   </identity> 
</channelType> 

This example shows how a 'child' channel instance can be created per supplier (i.e. their could be multiple suppliers being used within the same choreography instance), and each of these supplier channel instances would be associated with the previously established 'order' identity, which in turn binds each supplier channel instance to the same choreography session. 

In this example we have also used a composite key (for the supplier) to ensure that the key is not only unique within the choreography session, but unique in respect of all choreography sessions. 

NOTE: This approach could also be used to define the 'chaining identities' example in a different way. The previous example assumed that the DeliveryChannel messages did not contain the information to identify the order, and therefore the delivery identity was derived from the OrderChannel (i.e. forward reference). However, if we assume that the converse maybe true, such that the delivery information is not exchanged on the Order Channel, but that the order id is sent in the first message on the delivery channel, then we could rephrase the first example in the following way: 


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

<channelType name="DeliveryChannel" > 
   <identity name="order" usage="association" /> 
      <token name="OrderId" /> 
   </identity> 
   <identity name="delivery" usage="primary" > 
      <token name="DeliveryId" /> 
   </identity> 
</channelType> 


ISSUES: 

When identities are derived, we need to make sure that the channel that is using the derived identity is associated with the same relationship? or participants?, to ensure that both participants have the same derived identities. The same applies to where a channel type references an identity with 'association' usage - to make sure that the participants using the channel type both have access to the associated identity. 

There is also an issue when channels are passed. If an "output" channel is passed from one participant to another, then the receiving participant must already have the identity information established to enable it to send and receive messages on the passed channel instance. For example, if participants A and B have a channel instance with identity OrderId=12345. If the channel is then passed from participant B to participant C, then any messages sent by participant C on that channel must conform to the identity of that channel instance, and therefore reuse an existing identity value. This means that the 'identity' token of OrderId must have previously been initialized (through a previous message exchange with participants A or B) over a channel type that had the OrderId identity marked as being derived. 

All of these issues could probably be handled with appropriate model verification.