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

Ricky,
Please find my comments inline.

> -----Original Message-----
> From: Ricky Ho [mailto:riho@cisco.com] 
> Sent: Tuesday, March 25, 2003 12:39 PM
> To: edwink@collaxa.com; jdart@tibco.com
> Cc: public-ws-chor@w3.org
> Subject: Re: More about the patient/receptionist/doctor use case.
> 
> 
> Edwin,
> 
> In your example, you haven't covered the contract of 
> collaboration between 
> the receptionist and the doctor.  After your break down, 
> there is nothing 
> saying that step (1) must happen before step (2).  It is 
> possible that a 
> doctor say "I'm available" but then no patient shows up.

I am not sure that I understand your point: 
Are you trying to say that it is important that the patient knows how
the receptionist query doctors or that once an appointment receipt has
been generated, the patient might decide not to show up and you want to
manage the appropriate timeout and release of resources?

> Look at the pre-requisite of "MedicineDelivery" service.  It 
> may not be 
> sufficient by just having the Prescription Receipt.  What if step (7) 
> hasn't happened.  the doctor hasn't told the receptionist to prepare 
> medicine so even though the patient presents the prescription 
> receipt, the receptionist is not going to delivery the medicine.

This is where I think that the notion of responsibility is important. I
expect the doctor service to do the right thing and issue a valid
prescription receipt. If the receipt end up being invalid, I can go back
to the doctor and complain.

> Similar argument in "DoctorService", the pre-requisite is not 
> sufficient.  What if the doctor hasn't been asked by the receptionist 
> before the patient shows up in his door with the appointment receipt.

Same as previous answer here. The appointment receipt is contractual
binding. The receptionist is responsible for offering that service. In
my opinion, micro managing how the service is provided creates
unecessary complexity and seems going against how business operate
today.

The point that I was trying to make is NOT that multi-party interactions
do not exist and should not be modeled. My point is that given the
business and legal contractual overhead of collaboration, most
interactions tend to orbit towards bi-party interactions. Those bi-party
interactions can be interlinked in a very loosely-coupled fashion using
"typed" contractual documents. 

Given the level of technical complexity related to defining n-party
interactions (n>2) versus bi-party interactions, it is not obvious to me
that people MUST end up using the same formalism. I think that this is
something that could be investigated further.

Edwin

Received on Tuesday, 25 March 2003 16:02:13 UTC