Black box processes? (WAS: Definition of Choreography)

Paul Prescod wrote,
> For example, here's what WSCI says:
>
> "In this example (taken from Section 5.4.1.2), the Travel Agent
> service describes how some operations must be performed in sequential
> order; first, the Travel Agent indicates an intention to cancel the
> reservation by sending a cancellation request to the airline. It,
> then, waits for receipt of a cancellation confirmation from the
> airline. Last, it notifies the traveler that the reservation has been
> cancelled."
>
> The interesting thing is that the two people interacting with this
> service DON'T care about all of that. The travel agent service must
> negotiate how to send cancellations and cancellation receipts with
> the airline. Sure.
>
> And the customer needs to negotiate how confirmation and cancellation
> notifications will be interchanged with the travel agent. Sure.
>
> But the airline doesn't and shouldn't care about the travel agent's
> communication protocol with the customer and the customer shouldn't
> care about the travel agent's communication protocol with the
> airline. To each participant, those are implementation details that
> should be hidden inside of the travel agent service.

I don't think it's at all as clear cut as that.

If the process goes smoothly, then yes, each side can, and probably 
should, treat the other as a black box. But suppose it doesn't? Suppose 
the customer has cancelled but not yet received an ack back (and more 
importantly, not been credited with a refund). After a while she'll 
contact the agent asking for an explanation. She might be satisfied 
with "The airlines comms link has failed" as a response, but would 
probably be less than satisifed with "There's been an unspecified 
failure: you don't need to know the details".

More generally, attributing blame in a fine-grained way in a failed 
process is going to require that the details of that process be 
exposed, or at least expos*able* in some appropriate context (eg. to an 
adjudicator).

It's tempting to say that the travel agent hasn't done a good enough job 
of encapsulating the airline from the customer, and that the customer- 
agent interface should have been specified so that those interactions 
are robust in the face of airline comms failures. That might be 
possible in some cases, but in general it won't be: perhaps the agent 
isn't in a position to refund the customer without first being refunded 
by the airline.

And that particular implementation detail might be a reason for a 
customer to choose one agent over another: if she wants to be assured 
of a speedy refund even if the airline fails she might choose to pay a 
premium to an agent which cuts the airline out of the part of the 
refund process that she sees (eg. by maintaining sufficient contingency 
funds to cover refunds). But she isn't going to be able to make that 
choice without knowing something about the agent-airline interaction 
and the internals of the agent.

If we accept that process failures are inevitable (which I think we 
should in open systems) then we should accept that implementation 
details should show through interfaces in at least some contexts: when 
choosing which process (ie. which travel agent) to commit to; when 
adjudicating following a failure.

OO dogma aside, the maxim that implementations should depend on 
interfaces and not vice versa has never told the whole story: 
interfaces and implementations are mutually constraining, and each 
leaves its marks on the other.

Cheers,


Miles

Received on Monday, 21 October 2002 06:21:07 UTC