This is
identified as WS-TX issue 065.
Please ensure
follow-ups have a subject line starting "Issue 065 - WS-AT:
ATAlwaysCapability redundant".
From: Alastair Green [mailto:alastair.green@choreology.com]
Sent: Sunday, June 04, 2006 4:02
AM
To: ws-tx@lists.oasis-open.org
Subject: [ws-tx] NEW ISSUE --
WS-AT: ATAlwaysCapability redundant
Issue name -- WS-AT: ATAlwaysCapability redundant
PLEASE DO NOT REPLY TO THIS EMAIL OR START A DISCUSSION THREAD UNTIL THE ISSUE IS
ASSIGNED A NUMBER.
The issues coordinators will notify the list when that has occurred.
Protocol: WS-AT
Artifact: spec
Draft:
WS-AT WD 0.6 uploaded 2 June 2006
Link to the document referenced:
http://www.oasis-open.org/apps/org/workgroup/ws-tx/download.php/18527/wstx-wsat-1.1-spec-wd-06.doc
Section and PDF line number
Section 5.2, ll.268 - 275
Issue type: Design
Related issues:
Issue 045 -- use of wsp:Optional
Issue Description:
ATAlwaysCapability policy assertion will break AT-policy unaware client
Issue Details:
Discussion leading to resolution of 045 underscored the importance of
wsp:Optional = true as an "AT policy must understand = false" flag,
i.e. its use enables clients which are WS-Policy-aware, but WS-AT-ignorant to
access an operation which it is safe for them to use.
The same principle should apply to ATAlwaysCapability.
If ATAlwaysCapability were used with a wsp:Optional = true attribute, then it's
meaning would be:
1) Service has following characteristics and capabilities: it will always
execute in a transactional manner; if it receives a transaction context then it
will subordinate its transactional behaviour to the transaction represented by
that context.
2) Client can access this service if AT unaware
3) Client can access this service if AT aware, but need not send a context
4) Client can send an AT transaction context to this service.
In my view this set of meanings is operationally identical to ATAssertion with
the wsp:Optional attribute.
It is clearly unsatisfactory to have a policy that will break an AT-naive
client. But, if we allow ATAlwaysCapability to acquire the optional attribute
(or indeed, if we use it in the long form, adjacent to an empty policy
alternative) then it just becomes another way of saying MAY flow context.
Proposed Resolution:
Remove all references to the ATAlwaysCapability policy assertion type from the
WS-AT spec.
Note that this is a simplifying change which
does not affect interop scenarios.