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

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

From: Francis McCabe <fgm@fla.fujitsu.com>
Date: Thu, 27 Mar 2003 10:56:44 -0800
Cc: "Stephen White" <swhite@SeeBeyond.com>, <public-ws-chor@w3.org>
To: Ricky Ho <riho@cisco.com>
Message-Id: <DAB18325-6085-11D7-A8E3-000393A3327C@fla.fujitsu.com>

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.


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 13:56:53 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:00:57 UTC