- From: Francis McCabe <fgm@fla.fujitsu.com>
- Date: Thu, 27 Mar 2003 12:21:12 -0800
- To: Ricky Ho <riho@cisco.com>
- Cc: "Stephen White" <swhite@SeeBeyond.com>, <public-ws-chor@w3.org>
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 15:21:24 UTC