Re: Change of participants

I am not convinced (at least, not yet) that this couldn't be 
accomplished by either expanding the number of allowed participants in 
the choreography, or making the set of participants open-ended (dynamic 
participation in the sense it has been discussed earlier).

E.g. if I can start an interaction and then delegate to another party to 
finish it, then perhaps the choreography should explicitly allow that 
party to "join" mid-conversation, and initiate or respond to one or more 
of the possible interactions.

Fred actually gives some good reasons why you wouldn't want to 
dynamically change the binding of a role during the scope of a 
choreography execution, security being one of them .. although depending 
on exactly how things were implemented, this might or might not be an 
actual problem. E.g. you could make "rebind role" be an explicit step in 
the process, and have it imply re-authentication.

Another comment: per my earlier remark, some business justification for 
this facility would be helpful.

--Jon

Cummins, Fred A wrote:
> Assaf, Ricky,
> 
> There is another dimension to changing participants assigned to
> roles.  The question is when can the entity behind the URI change. For
> example, it is possible that a participant wants to receive initial
> requests at one URI and redirect subsequent actions to different
> URIs, potentially depending on the nature of the request or
> the availability of resources.  The entity could be the same
> but the requests are directed to different processes or business
> units within the entity, or simply to different servers.
> 
>>From a business standpoint, the participant sending the messages
> wants to know who he is dealing with.  Is it acceptable to have his
> messages redirected to a different entity?  I think this gets us into
> questions about the content and security of the messages, and beyond
> the scope of the choreography.
> 
> A participant should be able to delegate to an "agent" to continue
> the exchange.  The delegation will require more than a simple "change
> of address."  The agent must be able to speak for the principal,
> and have appropriate credentials.
> 
> So, I think dynamic changes to a participant (i.e., URI) assigned to 
> a role should be considered something quite acceptable at the 
> discretion of the participant.  It should make no difference in the
> choreography because the role remains the same. The message structure
> and content must provide for communication of such changes along with the 
> appropriate credentials to be associated with the new URI.
> 
> Fred Cummins
> 
> 
>>-----Original Message-----
>>From: Assaf Arkin [mailto:arkin@intalio.com]
>>Sent: Tuesday, April 22, 2003 7:10 PM
>>To: Ricky Ho
>>Cc: public-ws-chor@w3.org
>>Subject: 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 Wednesday, 23 April 2003 14:12:11 UTC