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

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

I agree, but I think that all the variation is more due to the fact that
humans are involved who have the (non-artificial) intelligence to cope with
the variability.

On the other hand I think that WS-CHOR focus will be on machine-to-machine
interaction where there is little intellligence and therefore doing the
choreography the same way every time is actually an advantage.

Thoughts?

David

-----Original Message-----
From: Francis McCabe [mailto:fgm@fla.fujitsu.com]
Sent: Thursday, March 27, 2003 9:11 AM
To: Stephen White
Cc: Ricky Ho; edwink@collaxa.com; jdart@tibco.com; public-ws-chor@w3.org
Subject: Re: More about the patient/receptionist/doctor use case.



Steve:
On Wednesday, March 26, 2003, at 09:30  AM, Stephen White wrote:

> I was having trouble following the use case as a text description, so 
> I made up a couple of diagrams to help me follow the example. There is 
> a diagram with a 3-party choreography (3Part_Pat-Recp-Doc.jpg) and 
> three separate diagrams of the individual 2-party choreographies 
> (within 3_2Part_Pat-Recp-Doc.jpg). I am sending in the diagrams to 
> help those like me who need to see pictures.
>

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

Frank

Received on Thursday, 27 March 2003 12:44:06 UTC