RE: Change of participants

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 Tuesday, 22 April 2003 23:04:44 UTC