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