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

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 14:19:12 UTC