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

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