CHANGE: Additional elements on channelType definition, with supporting text

<channelType>
	....

	<session>
		<token name="qname" />+
	</session>?

	<sessionAlias>
		<token name="qname" />+
	</sessionAlias>*
</channelType>

The session element defines the set of tokens that provide the identity of the session to which the channel instance belongs. If a CDL package only has a single channelType definition, then this element is optional. Otherwise a session element is mandatory, to enable multiple channel instances to be correlated to the same choreography session.

To correlate a new instance of the channelType, to the choreography session, the first message that is sent along the channel instance MUST have appropriate token locators defined to derive the session identity.

The optional sessionAlias element(s) enable an alternative session identity to be created for the choreography session. This allows other channelTypes to be declared that use the alternative session identity to correlate instances of their channelType to the same choreography session.

The session alias will be derived from the first appropriate message that is sent on an instance of the channelType. If the alias has multiple tokens, then it is possible that the session alias will be initialized based on information from different messages. However, the alias will only be fully available for correlation against other channelTypes, once all of the tokens have been resolved.

A sessionAlias element can only be specified if the channelType has declared a session element.

The mechanism used to manage the identity of a choreography session, using the session and sessionAlias elements, is described in section XXX (Session Management).

CHANGE: New section to be located in an appropriate section of the document

x.x Session Management

This section discusses the mechanism used to correlate channel instances to a choreography session.

x.x.1 Primary session identity

The "primary" session identity is established by the first message sent on the channel instance that initiates the choreography.

After this communication has occurred, all other session identities will be related back to this "primary" session identity, either directly (using the same set of tokens), indirectly using a session alias, or by extending the set of tokens (in a hierarchical parent/child relationship).

x.x.2 Simple session management

In the simple case, one or more channel types can be associated with a common session identity. In this situation, each channelType would declare a session element that had an equivalent set of tokens, representing the same information types in the same order.

This would require each instance of the channelTypes to be initiated by a message that can provide this common session identity (e.g. an Order Id).

x.x.3 Deriving alternative session identities

In a situation where a choreography has multiple channelTypes, but it is not appropriate for each channelType to be initiated by a message that can be used to derive a common session identity, then it will be necessary to establish relationships between a group of alternative session identities that actually relate to the same choreography session instance.

This can be achieved using the sessionAlias element on the channelType, as shown in the following example.

<package>
	<channelType name="PrimaryChannelType" >
		....
		<session>
			<token name="OrderId" />
		</session>
		<sessionAlias>
			<token name="AuthorizationId" />
		</sessionAlias>
	</channelType>
	<channelType name="SecondaryChannelType" >
		....
		<session>
			<token name="AuthorizationId" />
		</session>
	</channelType>
	......
</package>

The choreography would initially make use of the 'PrimaryChannelType'. As part of the interactions that occur on this channel, it would result in the 'AuthorizationId' token being resolved, and thus establishing the alternative session identity.

After this alternative session identity has been associated with the choreography session, the choreography can then initiate an instance of the 'SecondaryChannelType', which would then be correlated with the choreography session based on this alternative session identity.

If an attempt was made to initiate a channel instance, for a channelType that had a session identity related to an alias that had not yet been resolved, then this would result in an exception. This is because it would not be possible to correlate this new channel instance to a particular choreography session. Static analysis could be used to determine if this situation may occur.

x.x.4 Multiple concurrent sub-choreographies with multiple channel instances

In CDL, it is possible to define sub-choreographies that can be composed into higher level more complex choreographies. If only a single instance of a sub-choreography is used, at any particular point in time (within the parent choreography), then the correlation of the channel instances established within that sub-choreography will be correlated to the choreography session in the same way as channel instances in the parent choreography.

However, if it is possible for the sub-choreography to be performed multiple times concurrently, within the parent choreography, then there is an issue correlating which channel instances instantiated within those sub-choreography instances belong to which sub-choreography instance. In this situation, these sub-choreography instances can be considered as separate session instances, that are "owned" by a parent choreography session instance.

Therefore, in this situation, we need to be able to firstly identify the choreography session to which a message belongs (i.e. the parent choreography), and then determine which sub-choreography instance (owned by that parent choreography) the message is associated with. This requires a hierarchical session identity scheme, that clearly shows the parent choreography's session identity, but also enables each of the sub-choreographies to be uniquely identified.

To achieve this hierarchical identity, the session element associated with the channelType definitions used by the sub-choreographies, will be a super-set of the tokens used in the parent choreography session identity. The parent's session identity tokens will be declared first, followed by the additional tokens that are used to uniquely identify the channel instances within each of the concurrent sub-choreography instances.

NOTE: The parent session identity from which the sub-choreography's channelType session identity is extended can be either the "primary" session identity, or one of the alternative session identities that have been established using the sessionAlias mechanism.

For example,

<package>
	<channelType name="CustomerChannelType" >
		....
		<session>
			<token name="OrderId" />
		</session>
	</channelType>
	<channelType name="SupplierChannelType" >
		....
		<session>
			<token name="OrderId" />
			<token name="SupplierId" />
		</session>
	</channelType>
	......
</package>

In this example, a 'CustomerChannelType' instance is used to establish an order. The choreography may then wish to deal with multiple suppliers concurrently, to determine which can fill the order within certain parameters (e.g. lowest cost within a defined delivery period). To achieve this, the parent choreography may perform a sub-choreography multiple times (once per supplier). Each of these sub-choreography instances will establish a channel of type 'SupplierChannelType'. Therefore the identity of the sub-choreography session will be defined by the identity of the parent choreography (OrderId), and the supplier id, which uniquely identifies the sub-choreography instance.

NOTE: This 'hierarchy' session identity mechanism is only required in situations where a parent choreography has multiple "concurrent" sub-choreography instances, and that sub-choreography creates more than one channel instance.