It’s a question of scope and
slippery slopes. Should a policy expression with a MUST NOT assertion
type be declared for everything not supported?
Best regards,
Colleen
From: Alastair Green [mailto:alastair.green@choreology.com]
Sent: Tuesday, May 23, 2006 8:16
AM
To: Colleen Evans
Cc: Max Feingold; ws-tx@lists.oasis-open.org
Subject: Re: [ws-tx] Policies
Colleen,
Could you explain what you mean? I'm not sure I understand your question (in
fact, I'm sure I don't understand your question :-) ).
In this strawman proposal the MUST NOT would only be used to say: "The
service op will execute within a server-side transaction: do not attempt to
subordinate this transaction to your client-demarcated transaction."
You can always keep shtum, and move to undefined behaviour.
By the way, the term "client" in the proposed text shd be replaced
with "requester" for consistency.
Thanks,
Alastair
Colleen Evans wrote:
The cardinality of declaring anything not supported as MUST
NOT could be rather daunting, couldn’t it?
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