- From: Assaf Arkin <arkin@intalio.com>
- Date: Mon, 09 Jun 2003 14:59:55 -0700
- To: "Burdett, David" <david.burdett@commerceone.com>
- CC: "'Jean-Jacques Dubray'" <jjd@eigner.com>, "'Yaron Y. Goland'" <ygoland@bea.com>, "'WS Chor Public'" <public-ws-chor@w3.org>
Burdett, David wrote: > JJ > > The choreography instance id problem is one that was also discussed by > ebXML. The issues, as you say were: > 1. The need to have an identifier shared between the roles (ebXML > called them parties) in the choreography so that, when a message > arrives, or is sent, the correct context could be set by the sender > and identified by the recipient. > 2. The problem that the an identifier created by the sender may not > serve as a useful identifier at the recipient as their system > separately controls the identifier used by correlation. 3. A process that participates in two choreographies needs two different identifiers correlated to its instance (or N correlations for N choreographies) > > I recall that there were several different approaches to solving this > considered, including: > 1. Each role setting their own choreography instance id > 2. The sender of the first message setting the choreography instance id > 3. Concatenating a sender and receivers choreography instance ids to > give a unique, shared id. What about the possibility that each participant just picks its own identifier and all participants communicating with it agree to use that identifier to maintain the notion of a session? If you have n participants than you have n different identifiers. You can talk to a participant only if you know its identifier (which is opaque - means nothing to you), so you can't join the choreography unless invited to join it. Would a scheme like that work? arkin > > However, the ended up choosing the second and recognizing that it > would mean that, for some implementations, mapping tables between the > "public" and private id's might be needed. > > David
Received on Monday, 9 June 2003 18:00:39 UTC