W3C home > Mailing lists > Public > public-ws-chor@w3.org > March 2003

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

From: Ricky Ho <riho@cisco.com>
Date: Thu, 27 Mar 2003 12:35:29 -0800
Message-Id: <4.3.2.7.2.20030327123027.02a0e528@franklin.cisco.com>
To: Francis McCabe <fgm@fla.fujitsu.com>
Cc: <public-ws-chor@w3.org>

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:35:39 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Saturday, 18 December 2010 01:00:07 GMT