OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ws-tx message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


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




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]