RE: Requirements: Decision Points Requirement Proposals

See comments below.

-----Original Message-----
From: Assaf Arkin [mailto:arkin@intalio.com]
Sent: Monday, June 09, 2003 3:00 PM
To: Burdett, David
Cc: 'Jean-Jacques Dubray'; 'Yaron Y. Goland'; 'WS Chor Public'
Subject: 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)
<DB>Maybe, but really I think that correlation identifiers should only have
to be unique within a choreography identifier. This would allow one party
that is involved in two choreographies as part of some business process, to
use the same correlation identifier in both to link them together.</DB>

>  
> 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?
<DB>In this example I *think* that you have n separate choreography
instances. Being invited to join a choreography is a separate issue, since
you can only invite yourself if you know about it and you won't know about
it unless you've been told, which reallky means you are always invited.</DB>

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 Tuesday, 10 June 2003 14:16:53 UTC