RE: Change of participants

Ricky,

all I have done is extract requirements from the minutes. 
I'm not really the requirements gatekeeper here (that would be the
requirements doc editors),
and how we deal with these requirements is up to the group.

Saying that I will add me 2p worth!
I tend to agree that we should expand this particular one to separate
the concepts of role from participant, 
where participant is the actual instance being bound to (one or more)
roles.
I also think that we should allow the choreography designers to decide
what invariants are placed on an instance of a choreography in trems of
wich roles can be rebound, whether all roles have to be bound at all
time etc, what the starting binding are etc. In the particalur case the
Dale points out, that is really a design decision by at to whether the
buyer is aware of the shipper i.e. it could be designed as a three-role
choreograpghy, or as two two-role ones, with the seller linking the two.


Martin.

> -----Original Message-----
> From: public-ws-chor-request@w3.org 
> [mailto:public-ws-chor-request@w3.org] On Behalf Of Ricky Ho
> Sent: Thursday, April 17, 2003 4:52 PM
> To: Dale Moberg; public-ws-chor@w3.org
> Subject: RE: Change of participants
> 
> 
> 
> I'm thinking (2a) means "role rebinding" within the lifecycle of a 
> choreography instance.
> You're thinking (2a) means one party bind to different roles 
> in different 
> choreography instances.
> 
> Any clarification, Martin ?
> 
> Rgds, Ricky
> 
> At 04:19 PM 4/17/2003 -0700, Dale Moberg wrote:
> >Let me expand the use case a little and then ask you a question. 3.
> >-----Original Message-----
> >From: Ricky Ho [mailto:riho@cisco.com]
> >Sent: Thursday, April 17, 2003 2:44 PM
> >To: Dale Moberg
> >Subject: RE: Change of participants
> >
> >
> >Embedded ...
> >
> >At 01:22 PM 4/17/2003 -0700, Dale Moberg wrote:
> > >Consider three role-occupant types, manufacturer, distributor, 
> > >retailer. And two roles, buyer and seller.
> > >
> > >Consider SC choreography
> > >
> > >1. Buyer(Retailer) sendsPO Seller(Distributor).
> > >2. Buyer(Distributor) sendsPO Seller(Manufacturer).
> >3. Seller(Manufacturer) sendsPOConfirm Buyer(Distributer)
> >4. Seller(Distributer) sendsPOConfirm Buyer(Retailer)
> >
> >You may augment this with a fourth role-occupant-type, 
> shipper, if you 
> >will, and shipper can dropship to retailer.
> >
> >This is an integrated unit of business activity. It is 
> arbitrary to me 
> >to assert that this is 2, not 1 choreographies. If you do, you must 
> >provide some criteria for making this boundary call. And that is 
> >probably going to be harder than treating multiparty with role 
> >switching.
> >
> >
> >
> >There are TWO independent choreography instances here.  The 
> distributor 
> >is playing a "buyer" role in instance1 and a "seller" role 
> in instance2 
> >at the
> >same time.  He hasn't change his role w.r.t the choreography 
> instance.
> >
> >My understanding of 2a is as follows ...
> >Think about a buyer, seller, shipper role.
> >
> >1) Buyer (bind to Ricky) send a PO to Seller (bind to Amazon)
> >2) Amazon decide the shipper (bind to Fedex)
> >3) Fedex has lost the shipment and so Amazon use UPS to deliver the 
> >shipment again (shipper rebind to UPS)
> >
> >
> >
> > >The distributor "changes" roles during the choreography. 
> Perhaps this 
> > >is an aspect to 2a.
> > >
> > >Not having been reading this list too carefully, perhaps that is a 
> > >use case in the multiparty-multirole choreography class. 
> But possibly 
> > >something more trivial is meant, that is, Something like JCPenny's 
> > >and Sears can both use the same choreography for retailers.
> > >
> > >
> > >From,
> > >Non ws-chor participant.
> > >
> > >
> > >
> > >-----Original Message-----
> > >From: Ricky Ho [mailto:riho@cisco.com]
> > >Sent: Thursday, April 17, 2003 1:10 PM
> > >To: Martin Chapman; public-ws-chor@w3.org
> > >Subject: Change of participants
> > >
> > >
> > >
> > >For point 2a, is this related to multi-party choreography 
> ?  I can't 
> > >imagine a use case of participant change in a bi-party 
> choreography.
> > >
> > >In multi-party choreography, we need to look into the 
> constraints of 
> > >such changes.  For example, in a buyer/seller/shipper 
> choreography, I 
> > >see "changing a shipper" can still be the same 
> choreography instance. 
> > >But I
> > >
> > >have a hard time to understand if the "seller" can be 
> changed, even 
> > >harder if the "buyer" is changed.
> > >
> > >So I'm thinking a stricter one ...
> > >1) For a choreography to start, there needs to be at least 
> two roles 
> > >being binded.
> > >2) These two initial role binding cannot be changed
> > >
> > >as well as a looser one ...
> > >1) For a choreography to start, there needs to be at least 
> one role 
> > >(the
> > >
> > >initiator) being binded.
> > >2) The initiator role binding cannot be changed.
> > >
> > >Comments ?
> > >
> > >Rgds, ricky
> > >
> > >At 12:04 PM 4/17/2003 -0700, Martin Chapman wrote:
> > >
> > > >As per my action point here is a list of proposed requirements 
> > > >extracted from the minutes of the tues 8 April con call.
> > > >
> > > >1. A Choreography should be independent of message formats
> > > >
> > > >2. A Choreography may have run time changes:
> > > >    a. the actual participants can vary
> > > >    b. the actual choreography can vary [ed: I think we 
> ruled this 
> > > >out but have listed it for completeness]
> > > >
> > > >3. It should be possible to query the state of a Choreography
> > > >
> > > >4. Error/fault handling and compensation features need 
> to be able 
> > > >to be
> > >
> > > >expressed in the language.
> > > >
> > > >5. Choreographies should be composable (into a hierarchy)
> > > >
> > > >
> > > >Martin.
> > > >
> > > >_________________________________________________________________
> > > >Martin Chapman                                 500 Oracle Parkway
> > > >Consulting Member of Technical Staff           Ms 4op990
> > > >Oracle                                         Redwood Shores,
> > > >P: +1 650 506 6941                             CA 94065
> > > >e: martin.chapman@oracle.com                   USA
> 
>

Received on Friday, 18 April 2003 11:55:37 UTC