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?

No.  The patient doesn't care but the doctor may care.
In a multi-party choreography, this is NOT just the patient's concern, but 
also the receptionist as well as the doctor's concern.


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

Yes, but how do you express that responsibility in the choreography 
definition ?


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

I agree.  I certainly think the majority use cases are bi-party contract.

Best regards,
Ricky

Received on Tuesday, 25 March 2003 16:46:27 UTC