RE: [ws-caf] policy ai

["Green, Alastair J." <Alastair.Green@choreology.com>]

>I'm less clear about the relevance of the EJB-style declarations. Are
>you suggesting that a service (presumably outside the container
>potentially) can state to the client what its declared approach will
be?
>Is this really any business of the client?
>
>  
>
No, its not any business of the client and not what I meant: the writeup

must be misleading.

AJG: I wasn't sure where you were driving.

I  meant to suggest that application servers using EJB or COM+ semantics

will find this does not conflict with the kinds of assertions I listed. 
I probably shouldn't even have mentioned EJB. Its not clear to me we 
need to say more than Supports/Doesn't Support, but since we didn't have

particularly strong requirements, I started to explore other assertions 
that may be of interest.

AJG: dangerous ground, I think ...

Having said all of that, there is a problem with client-server 
transaction semantics in EJB that was never really resolved: the only 
way one can reason about the relationships in EJB based systems is to 
sit in a position of omniscience.

AJG: This is, I think, a slight overstatement :-). You can reason, but
only within limits -- and without requiring omniscience. 

The limits are inherent in any contract-defined relationship. You can
never know how deep the transactionality goes in a composite tree --
it's what's wrong with the notion of "Must propagate". 

What is the contract of a transactional invocation? On the surface it
is, in this context: "we'll collaborate to do ACID". But what does that
mean? If a resource reveals partial work (relaxed isolation) is it
acting ACIDically? Not strictly. 

Aha, but then it can surely communicate its isolation policy? But what
does that tell us? Who can see those partial results? What will they do
with that knowledge? The ripple effects are unknowable and
uncontrollable. 

And in any case, what business is it of the consumer to understand what
is meant by "transactional" or "contingent" for a given service? The
only meaning that can be enforced over the contract boundary is the
external effect. If I say confirm meaning turn quote into order, then
when I enquire about order status I should see that an order exists, not
a quote. That I can reasonably expect. I cannot know how the fact of the
order is recorded, nor can I know who else knows behind the interface
about the quotes and the orders -- these facts are not my business.

Let's take this further. The fact of the existence of a quote that may
become an order is valuable business information. It is a contingent
claim on inventory, and is (like a note on contingent liabilities in a
company's accounts) not something to be brushed under the carpet.
Classical ACID hides the information. I may choose, as the service
implementer, to reveal the information to privileged third parties. That
is not a client concern at all, and it may be completely undetectable to
external observers such as the client system.  

All of this is in a certain way a restatement of ACID, the essence of
which is Consistency. Consistency is an application-derived property. A,
I and D are tools that may be used to achieve consistency. But they are
not the only tools, and they are only tools -- transactions are an
abstraction to make the programming job of the application simpler. 

I think that the only statement that can reasonably be made about the
distributed transaction protocol contract is: that the transaction
sub-system will ensure that the willingness of the participant to be
instructed as to outcome is reliably delivered, and that the intention
of the terminating application (which may not be the client) is reliably
communicated to relevant participants who are so willing (prepared).

The meaning of prepared, and the significance of the outcome message(s),
can only be given by the agents who issue and receive these signals. The
overall meaning of the interaction can either be described by universal
observation (a single design authority with omniscience) or by
describing a series of contracts. The latter is the minimum case, and is
suitable for a service-oriented world. The former is rare, in fact. We
may think that "using XA resources everywhere" is a universal
description -- it is in fact a contract written in, for example, the
rules of EJB containment, deployment etc. And, in truth, we have no
inherent idea what the XAResource chooses to do by way of implementing
"commit" or "rollback" etc. 

The ability to reason from a god-like standpoint is not necessary, and
often is not even feasible. It would be better to be clearer about what
the contract statements are, and to recognize (above all) that they are
not usefully solely made by a general-purpose transaction protocol --
they are sub-properties of application or business contracts, and
intertwined with, and concerned with externally observable application
effects.

This is the fundamental reason why the notion of an ACID-only protocol
is quasi-meaningless. It's interesting that the "technical aristocrats"
of IBM and Microsoft made this exact point when describing the
Mills-Gates demo of "secure, reliable transactions" in September 2003,
with regard to the endpoint implications of the use of WS-AT. 

A swift re-consideration of the XA and OTS specs will reveal that any
statement about universal ACIDity is (in the context of interfaces like
the xa_switch or XAResource or OTS Resource) not actually enforced or
mandated, but is rather a self-limiting mindset influenced by historical
uses cases -- an example rather than a fundament. I can use the specs to
build a useful system that is non-ACIDic, and you (as my spec
counterparty) can never tell that I broke the "rule" of ACIDity.

Alastair