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

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 15:55:32 UTC