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

Francis McCabe wrote:

>
> Not so. The receptionist forms a critical role as the queue manager


My understanding as well. But with this understanding I don't understand 
why the use case does not depict the multi server/single queue scenario. 
Can you elaborate more on that?

arkin

>
> 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
>>>>> >
>>>>
>>>
>>


-- 
"Those who can, do; those who can't, make screenshots"

----------------------------------------------------------------------
Assaf Arkin                                          arkin@intalio.com
Intalio Inc.                                           www.intalio.com
The Business Process Management Company                 (650) 577 4700


This message is intended only for the use of the Addressee and
may contain information that is PRIVILEGED and CONFIDENTIAL.
If you are not the intended recipient, dissemination of this
communication is prohibited. If you have received this communication
in error, please erase all copies of the message and its attachments
and notify us immediately.

Received on Thursday, 27 March 2003 16:10:55 UTC