W3C home > Mailing lists > Public > public-ws-chor@w3.org > June 2003

Re: Requirements: Decision Points Requirement Proposals

From: Assaf Arkin <arkin@intalio.com>
Date: Mon, 09 Jun 2003 14:59:55 -0700
Message-ID: <3EE5035B.60908@intalio.com>
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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Saturday, 18 December 2010 01:00:21 GMT