W3C home > Mailing lists > Public > public-ws-chor@w3.org > November 2004

Re: Correlating separate channel instances to a choreography instance

From: Gary Brown <gary@enigmatec.net>
Date: Wed, 3 Nov 2004 07:22:26 -0000
Message-ID: <001101c4c175$e29e8330$0200a8c0@LATTITUDEGary>
To: <public-ws-chor@w3.org>

After a brief discussion with Nick, it appears that this is a problem.

Therefore I would like to propose a possible approach, that I would like comments on asap.

The problem is that if a choreography (including enclosed choreographies) use multiple channel instances, whether or not these channels are to multiple participants, there is currently a problem in that there is no mechanism for associating them with a particular choreography session (instance).

The only correlation mechanism at the moment is the <identity> mechanism on the channel type, which is used to correlate messages to a channel instance.

Therefore, I would propose that we need a similar mechanism at the choreography/package level - to optionally (because it is only necessary if multiple channels are used) specify the identity tokens for a package (or root choreography). This will then become the identity for the session.

To ensure that a channel instance is bound to a choreography session, we would then need to include a rule that stated that the initial message on a channel instance must have a token locator(s) associated with it that is capable of deriving the information associated with the choreography session identity tokens.

Not all messages would need to be able to derive the choreography session identity, although this would make the routing of messages more efficient. The alternative would be to derive the channel identity and then determine the choreography session based on its relationship with the identified channel instance.

Question: with the channel type identity field, the list of tokens combine to make a unique key. However, in the case of a choreography session identity, is it reasonable to assume that each channel instance would start with a message that had a common key field (or fields) with all other initial messages on the other channel instances within a particular choreography session? Consider a customer dealing with a seller, which then may deal with a distributor. The customer/seller channel may be identified by the customer id, but this customer id (potentially) may not be passed in communications with the distributor - in which case the session may have to be identified using different tokens?

If a common identity token(s) is not suitable, to associate all channel instances to the session, then possibly we need to have a slightly different type of identity, enabling a choreography session to establish a set of identities, each one potentially matching to a field in the initial message on a channel - however, we also need to be careful to make sure that each one of these keys is unique to this session.

Comments please, so that we can decide how to proceed on this issue. The problem has previously been logged, and I believe that this is a serious enough issue to require a proposal, but we need to have a reasonable (email) discussion first to flush out any potential problems with the approach.


  ----- Original Message ----- 
  From: Gary Brown 
  To: public-ws-chor@w3.org 
  Sent: Friday, October 29, 2004 11:24 AM
  Subject: Correlating separate channel instances to a choreography instance

  Within a channelType there is the means to specify an identity, which can be used to correlate individual messages to a channel instance. The correlation can be performed based on extracting the fields (specified within the identity element of the channel type) from the message payload, or if the optional identity element is not specified in the channel type, then I assume this is where a protocol header property would be used to do this correlation. 

  Is this assumption correct?

  However, there does not appear to be anyway to correlate two separate channel instances with the same choreography instance.

  This is possibly why the 'setIdentity' CDL function was put into the spec (although this was removed at the last f2f), but I am not sure this would have been a good general solution to the problem. Although this would have enabled subsequent channel variables to be initialized with their identity, based on business information from messages associated with other channel instances, it would not have worked where the correlation/identity id for a channel instance was provided by underlying protocol properties.

  Therefore I believe we need some mechanism for correlating channel instances to a choreography instance. Not sure what mechanism should be used (at present).

  Is this a problem? 
  If not how is it done in CDL today? 
  If it is a problem how could it be solved?

Received on Wednesday, 3 November 2004 07:22:47 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:01:06 UTC