Re: Change of participants

Ricky Ho wrote:

> Assaf, more ...
>
>
>>> I completely agree.  Do you think the number of roles is known in 
>>> advance (ie: there are a finite number of roles) ?  Can there be 
>>> varying (multiple) number of sellers within a choreography ?
>>
>>
>> I think the number of roles is known in advance. Also, the number of 
>> participants can be known in advance in many cases, because the 
>> choreography must express when/how they are bound. The choreography 
>> can be writen such that there it has two roles (say buyer and seller) 
>> and once two participants are bound there is no opportunity to rebind 
>> them. So once you start it you know the binding will not change. 
>> Another choreography can allow some participant to be late-bound but 
>> only once, yet another choreography can allow continuous rebinding 
>> until you achieve the desired outcome.
>
>
> So there is one seller (although it can be binded to different 
> participant at different time) ?  or multiple sellers at the same time 
> ?  In other words, can I start a choreography instance and buy from 
> Amazon and CDNow (both are playing the role "seller" at the same time) ?

That really depends on how you associate a participant with a role.

One way is to say, for example, the a placeOrder operation is provided 
by services acting in the role of a supplier. Each time you invoke this 
operation against some service, you are engaged with a conversation with 
that role. But when you invoke that operation you specify which 
particular participant to talk to, so you can send one message to Amazon 
and then one to CDNow engaging both participants acting for the same 
role at the same time.

Another way is to have some variable that represents a participant 
association with the role. Doing that association in fact ceates the 
binding, so if you associate it with Amazone you need to associate it 
with CDNow before you can interact with CDNow as the seller participant. 
Or you can do multiple things in paralle in two separate sub-contexts, 
where these associations are fixed throughout the context but different 
for each context.

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
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 Tuesday, 22 April 2003 21:40:31 UTC