Re: Requirements: Decision Points Requirement Proposals

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