Re: Black box processes? (WAS: Definition of Choreography)

Miles Sabin wrote:
>...
> 
> 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".

The details of the error message is completely unrelated to the 
design-time public specification of the service.

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

Figuring out what happened when the shit hits the fan is unrelated to 
the design-time public specification of the service.

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

That detail does not have to be exposed to the customer except for 
sociological reasons. The computer needs to know that there will be 
times where it will take time to get a refund. That should be specified. 
That this stems from the protocol interaction with the airline is 
irrelevant. When I get a Server Error 500, it is ONLY helpful for 
debugging purposes to know whether it was a SQL database or a Perl 
script that blew up.

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

That is not true. The two travel agents make QOS guarantees or choose 
not to. You pick based on those. When one Pizza company tells me 30 mins 
or free and the other says 45 mins or free, I don't interogate them as 
to whether the difference is because one uses a motorcycle and the other 
a truck, or because one does multiple deliveries at once and the other 
just one or ... Their QOS matters to me. Their implementation technique 
doesn't. If the pizza is late, I really don't care whether it was Ford's 
fault because the car broke down, except for sociological reasons (i.e. 
I may have a little more sympathy (but probably not).

Once you start down that path, it behoves me to consider looking at the 
source code to your servlets so I can tell whether you've used J2EE best 
practices or not. Anyone who wants to go this far can open source their 
implementations but let's not bother inventing a declaration language to 
handle it.

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

Both of these are typically done by human beings, not by computers 
(dynamic discovery hype aside). These human beings communicate most 
easily through prose. If a computer is going to do dynamic discovery, it 
will not be through an analysis of Turing-complete choreography files 
(for obvious reasons!). It will be by examining QOS guarantees and 
comparing them to real behaviour.

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

I'm having trouble seeing how your post relates to the features of any 
existing or proposed choreography language.

Interface and implications constrain each other and are related. But 
separate.

  Paul Prescod

Received on Monday, 21 October 2002 20:27:05 UTC