RE: [ws-tx] Policies

["Max Feingold" <Max.Feingold@microsoft.com>]

Without having a lot of time to elaborate, I’m inclined to state that we only need your (1), (2) and (3).  A few thoughts on this discussion:

 

1. From the perspective of the semantics of the ATAssertion, I don’t think transactions are that different from the prior art of existing policy assertions with the three modes we discussed on the con-call.  If we propose new semantics in addition to these, I’d really like to understand why we need them.
   
   
1. MUST – your (2)
2. MAY – your (3)
3. Undefined wrt policy – your (1).

 

2. In the context of the policy framework, I don’t believe we need your (4):  a service that asserts (4) is essentially similar to a service that asserts (1).  Keep in mind that an interoperable, policy-aware client will only flow a transaction if one of the following three cases applies:
   
   
1. The client consumes a MUST assertion – covered by your (2).
2. The client consumes the MUST alternative of a MAY assertion – covered by your (3).
3. The client uses OOB knowledge about the service - largely falls outside of policy, but can be covered by your (1)

 

3. For similar reasons, a policy aware client has no real use for the distinction between (4) and (5).

 

4. As aspects of ambient execution, transactions are not optional:  you either need them or you don’t, and you write different code depending on whether they are present or not.  But the ATAssertion is not a statement about the service’s implementation details;  it is a statement about the readiness of the service to accept flowed transactions on the wire.  An optional ATAssertion does NOT mean that the service thinks transactions are optional for its own execution.

 

5. The distinction between MUST and MAY is useful.  Some services may contain operations that only make sense when composed inside a larger operation (the MUST case), while others may be happy either composing with the larger operation or executing as an atomic unit in isolation (the MAY case).  This is the distinction that we’re attempting to draw by allowing the optional semantic.

 

---

From: Alastair Green [mailto:alastair.green@choreology.com]
Sent: Monday, May 22, 2006 2:02 PM
To: ws-tx@lists.oasis-open.org
Subject: [ws-tx] Policies

 

I've been pondering the policy options question for AT, including Ian's question on the use of must understand in the "not supported/never" case. Here's a strawman categorization.

A service arguably needs to be able to say (such that a client or a tool can discover) that it has the following attributes/requirements

1. Undefined: makes no statement about transactions: any use of transactions must be a matter of external contractual agreement between client and service.

2. Will only operate if supplied with a context (MUST receive one).

3, Will operate with or without a context (MAY use a supplied context, will act atomically if not supplied)

4. Will tolerate a context (will understand, but will not use)

5. Will not operate if one is supplied (MUST NOT).

The controversial ones are probably 3 and 5.

MAY: I believe (have long believed) that there is no such thing as an operation that may operate transactionally or may operate non-transactionally. An operation may very easily operate in its own server-side transaction, or in the context of an imported transaction. Don't expect everyone to agree, but I think it's worth discussing. I'd be very interested to hear of a real-world use case that contradicts my view. If you accept my view, then there is no need for the always capability, which is subsumed in MAY.

MUST NOT: if policy is about declaring capability and requirements, then declaring MUST NOT tells the client something they should be able to know upfront, before invoking. Relying on a fault (do not understand) is too late. If you don't agree with that, then I ask: why are we bothering with policies, and not just relying on external contracts?

Thought experiment: if I can state MUST NOT, then I don't need policy 4), because no-one should send a context when it won't be understood.

Last thought: do we need to define a standard faults to indicate that a client is breaking the declared policy, either must understand violation (MUST NOT case) or something else for MUST?

Alastair