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:
- 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.
- MUST
– your (2)
- MAY
– your (3)
- Undefined
wrt policy – your (1).
- 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:
- The
client consumes a MUST assertion – covered by your (2).
- The
client consumes the MUST alternative of a MAY assertion – covered by
your (3).
- The
client uses OOB knowledge about the service - largely falls outside of
policy, but can be covered by your (1)
- For
similar reasons, a policy aware client has no real use for the distinction
between (4) and (5).
- 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.
- 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