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 Thursday, 17 April 2003 19:52:18 UTC