The cardinality of declaring anything not
supported as MUST NOT could be rather daunting, couldn’t it?
From: Alastair Green [mailto:alastair.green@choreology.com]
Sent: Tuesday, May 23, 2006 6:02
AM
To: Max Feingold
Cc: ws-tx@lists.oasis-open.org
Subject: Re: [ws-tx] Policies
Max,
Let me recast the strawman in concrete WS-Policy terms.
Imagine we defined a policy vocabulary for an AT policy alternative, with three
policy assertion types, with the following working names:
wsat:MUSTReceiveCoordinationContext
wsat:MAYReceiveCoordinationContext
wsat:MUSTNOTReceiveCoordinationContext
and said (in WS-AT) that they were mutually exclusive within a policy.
That is my strawman. Absence of any attached policy expression equals
"undefined".
Your proposal is the same, but cuts out assertion
wsat:MUSTNOTReceiveCoordinationContext. I think this makes life harder -- see
the proposal below to understand why.
Having an explicit catalogue of this kind, with meaningful names, would walk us
right round the compact form problem, which leads us to an empty policy
alternative, which leads us to the nasty phrase in WS-Policy: "no behavior
is specified" -- which is where, I think, this issue started.
As a continuation of the strawman (i.e. to elicit and refine the discussion --
I don't have hardened views on this), we could consider the following wording:
Possible solution to issue:
[Insert this text as the guts of the assertion section]
The transactional behavior of a
service operation is defined as that part of its work which is performed only
when a transaction completes (commits or rolls back). The use of an assertion
type in the WS-AT policy vocabulary (defined below), within a policy
alternative of a policy expression attached to an operation, means that the
operation has transactional behavior. The details of an operation's
transactional behavior are defined by the application service designer.
The policy vocabulary of WS-AT consists of the following three policy assertion
types, only one of which may appear in a policy expression.
/wsat:MUSTReceiveCoordinationContext
Requester MUST include a wsc:CoordinationContext in the header of the request.
The service MUST enact the operation's transactional behavior in accordance
with the outcome of the transaction represented by the included context.
/wsat:MAYReceiveCoordinationContext Requester MAY include a wsc:CoordinationContext
in the header of the request. The service MUST enact the operation's
transactional behavior in accordance with the outcome of the transaction
represented by the context, if included. If the context is not included, then
the service MUST enact its transactional behavior in accordance with the
outcome of an atomic transaction unknown to the client.
/wsat:MUSTNOTReceiveCoordinationContext
Requester MUST NOT include a wsc:CoordinationContext in the header of the
request. The service MUST enact the operation's transactional behavior in
accordance with the outcome of an atomic transaction unknown to the client.
The absence of a policy alternative containing one of these assertion types
means that the characteristics or capabilities of the operation with respect to
atomic transactions is undefined by the policy expression. This does not
preclude documentation of such characteristics or capabilities by other means,
which are outside the scope of this specification.
[Note that this would remove the need for ATAlwaysCapability.]
Alastair
Max Feingold wrote:
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.
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