Re: Change of participants

> See inline ......
> I think this is the more generic principle, and we should look at this 
> as what can possibly be done in a very simple manner, and then work 
> out how much flexibility we really do want to allow. So the levels 
> would be:
>
> 1. An interaction with a role must include an identification of the 
> particular participant (most generic)
> 2. An interaction with a role must include an identification of the 
> particular participant, but the participant is associated with the 
> role ahead of the interaction (e.g. by a previous step like an 
> assignment) and need to be re-associated to switch participants
> 3. Same as above but the association can be done exactly once

mm1: This creates challenges if you have an entity that acts in a chain 
of events first as the buyer and then as the seller (such as in an 
interaction with an OEM and then to a distributor).  That's not to say 
they could not be multiple interactions as part of a larger choreography 
set.

> 4. Same as above but the association must be done before the 
> choreography is started
>
> In my experience the language has the same level of complexity for 
> #1-#3, but is simpler for #4. #1 has more flexibility but required 
> more discipline than #2, I'm not sure there's a whole lot of 
> difference between the two. #3 allows you to do two different things 
> in parallel, but does not allow you do to the same thing n times in 
> parallel.
>
> arkin
>
>
>
>

Received on Wednesday, 23 April 2003 23:52:11 UTC