RE: More about the patient/receptionist/doctor use case.

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 14:28:05 UTC