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

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