- From: Ricky Ho <riho@cisco.com>
- Date: Thu, 27 Mar 2003 13:01:06 -0800
- To: Francis McCabe <fgm@fla.fujitsu.com>
- Cc: <public-ws-chor@w3.org>
Can you elaborate your use case and any dependencies involved ? Rgds, ricky At 12:55 PM 3/27/2003 -0800, Francis McCabe wrote: >Not so. The receptionist forms a critical role as the queue manager > >On Thursday, March 27, 2003, at 12:35 PM, Ricky Ho wrote: > >>There are no dependencies among different servers and so this can be >>discomposed into multiple independent bi-party conversations. >>It illustrate that in some scenarios, a multi-party conversation can be >>decomposed into multiple bi-party conversation and in other scenarios, it >>cannot. >> >>Rgds, Ricky >> >>At 12:21 PM 3/27/2003 -0800, Francis McCabe wrote: >>>The single queue/multiple server scenario is still legitimate, and it >>>also is essentially a multi-party choreography. >>> >>>Frank >>> >>>On Thursday, March 27, 2003, at 11:27 AM, Ricky Ho wrote: >>> >>>> >>>>Exactly ! If we choose to support only bi-party case, the role-binding >>>>issues also disappear. (but I'm NOT advocating that) >>>> >>>>Rgds, Ricky >>>> >>>>At 11:19 AM 3/27/2003 -0800, Stephen White wrote: >>>>>I think that the diagrams will only reflect the intent of our >>>>>approach. The discussions leading up to this was which of the two >>>>>fundamental scenarios our working group should choose. That is, would >>>>>we specify multi-party choreographies or restrict it to only bi-party >>>>>choreographies. The diagrams were presented to show an example of each >>>>>approach and then visualize the potential issues surrounding each >>>>>approach-such as the relationship between the ordering of the messages >>>>>between the 3 parties. If we decide that only bi-party choreographies >>>>>will be specified, then the multi-party diagram would not be employed >>>>>in the use cases, and there would be no issue in reading the diagram. >>>>> >>>>>-----Original Message----- >>>>>From: Francis McCabe [mailto:fgm@fla.fujitsu.com] >>>>>Sent: Thursday, March 27, 2003 10:57 AM >>>>>To: Ricky Ho >>>>>Cc: Stephen White; public-ws-chor@w3.org >>>>>Subject: Re: More about the patient/receptionist/doctor use case. >>>>> >>>>> >>>>>The doctor/patient scenario can be viewed as an example of two >>>>>fundamental scenarios: >>>>> >>>>>1. The multiple server/single queue scenario (this is how I introduced >>>>>the use case at the F2F) >>>>>2. The composite business scenario (to build a patient visit service >>>>>you need to combine a receptionist with a doctor) >>>>> >>>>>If the latter is the intent, then the diagrams are fine. If the former >>>>>is the intent, then my issues stand. >>>>> >>>>>Frank >>>>> >>>>>On Thursday, March 27, 2003, at 10:48 AM, Ricky Ho wrote: >>>>> >>>>> > I think the diagram precisely represent the text description of the >>>>> > use case I originally put up. >>>>> > We can argue whether the doctor use case really need an interleaving >>>>> > dependency. And I'd like to hear from Francis which particular >>>>> > dependencies are inappropriate. >>>>> > >>>>> > >>>>> >> One issue behind diagrams like these is that (a) they presuppose an >>>>> >> ordering relationship between messages between the receptionist and >>>>> >> the >>>>> >> patient that is dependent on message between the doctor and the >>>>> >> receptionist. This is not accurate. >>>>> >> [saw]I don't think this is an issue of the diagrams itself. The >>>>> >> diagrams were to help visualize the issues of the discussion. A >>>>> >> multi-Party choreography presupposes the ordering relationship you >>>>> >> mention. But the individual 2-party choreographies do not presuppose >>>>> >> this ordering relationship. The diagrams helped clarify the >>>>> >> difference between the two approaches (at least for me). >>>>> > >>>>> > +1 >>>>> > >>>>> >> And (b) that there is one >>>>> >> receptionist/patient interaction with every receptionist/doctor >>>>> >> interaction, again not sustainable; at least, the interleaving is not >>>>> >> so straightforward. >>>>> >> [saw]This might be an argument against a multi-party choreography or >>>>> >> we should discuss a way of representing complexities of the >>>>> >> relationships, if possible. Again, I intended the diagrams to help >>>>> >> facilitate the discussions. >>>>> > >>>>> > +1 >>>>> > >>>>> > >>>>> >> Frank >>>>> > >
Received on Thursday, 27 March 2003 16:01:15 UTC