Re: [ws-caf] policy ai

[Greg Pavlik <greg.pavlik@oracle.com>]

Green, Alastair J. wrote:

>>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. 
>
>  
>
No, you can't reason about the relationships at all without a special 
position of intelligence (omniscience was a bit of hyperbole) because 
the "policies" are merely internal configuration. I think you took me to 
mean something different: ie, what kinds of real guarantees can we 
expect in a composite system that makes certain claims: in EJB no claims 
are made.

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