http://docs.oasis-open.org/ws-tx/issues/
WS-TX TC Issues List
Date: 2007/01/15
Revision: 31
spec
schema
soap
wsdl
policy
rddl
all
Review
Active
Deferred
Dropped
Pending
Done
Resolved
Closed
Description of Status is Incorrect
The description of Status is incorrect. The spec currently describes the receipt of the Status
message as causing the target service to return a QName. My interpretation of the spec is that,
in fact, nothing is returned when a Status message is received - it is a response to a
getStatus message, i.e. Status is to getStatus what Closed is to Closing.
ws-ba
spec
editorial
Andy Wilkinson
Andy Wilkinson
The text on lines 213-215 to be replaced to accurately describe Status. I propose:
"Received in response to a getStatus request. The message includes a QName indicating the state of
the Coordinator or Participant to which the request was sent."
The proposed resolution was accepted during
March 14, 2006 F2F meeting.
Clarify subordinated CreateCoordinationContext behaviour
Precisely specify normative behaviour of CreateCoordinationContext
against existing (superior) context
ws-coord
spec
design
Alastair Green
Alastair Green
Sub-issue a). Editorial work required to clarify example, and
accompanying figure, and to create a section that describes the model
and normative operation of sub-coordination.
Sub-issue b). Remove any normative reference to subcoordinator
identifier inheritance in WS-Coordination.
Sub-issue c). Remove any normative statement relating to sameness of
superior and sub-coordinator coordination types or protocols.
Sub-issue d). Remove any normative statement relating to the timing of
sub-coordinator registration, other than to state that the
sub-coordinator must be registered to take part in activity
completion.
ACTION: Alastair to post 4 new issues to clarify the discussion. Dec 15, 2006 call
New issues 18, 19, 20 and 21 opened to represent issue 2 sub-issues. This issue was closed with no
action on Jan 12, 2006 call.
i018
i019
i020
i021
Appropriate categories of fault
Faults in WS-C should be divided into two categories: those which apply to the process of context creation and
registration (or which apply to the misuse of the conversational channel created by registration), and those
which are basic faults available to all coordination protocols.
ws-coord
spec
schema
design
Alastair Green
Alastair Green
Named faults should be added to permit the ActivityService and
RegistrationService to repudiate legal messages that cannot be
processed at run-time.
Faults that apply to the behaviour of some but not all conceivable
coordination protocols should be defined by the specification of each
individual coordination protocol, and should
not be specified in WS-Coordination.
Faults that apply to the interactions of application elements (as
opposed to the interactions of Coordinators and Participants, viewed
as roles in a coordination protocol), e.g. those relating to potential
unwillingness or incapacity to use a propagated context, should not be
specified in WS-Coordination.
i004
i005
i006
i008
i012
i013
Add new fault CannotCreateContext
Activation Service should be able to communicate inability to create a context.
ws-coord
spec
schema
design
Alastair Green
Alastair Green
1) Insert new Fault description (order in section an editorial matter)
as follows:
4.x Cannot Create Context
This fault is sent by the Activation Service to the sender of a
CreateCoordinationContext to indicate that a context could not be
created.
Properties:
[Code] Sender
[Subcode] wscoor:CannotCreateContext
[Reason] CoordinationContext could not be created.
[Detail] unspecified
2) Add new enumeration to schema type ErrorCodes:
<xsd:enumeration value="wscoor:CannotCreateContext"/>
Proposed resolution accepted on TC Telcon
i003
i005
Add new fault CannotRegisterParticipant
Registration Service should be able to communicate inability to register a participant.
ws-coord
spec
schema
design
Alastair Green
Alastair Green
1) Insert new Fault description (order in section an editorial matter)
as follows:
4.x Cannot Register Participant
This fault is sent by the Registration Service to the sender of a
Register to indicate that the Participant could not be registered.
Properties:
[Code] Sender
[Subcode] wscoor:CannotRegisterParticipant
[Reason] Participant could not be registered.
[Detail] unspecified
2) Add new enumeration to schema type ErrorCodes:
<xsd:enumeration value="wscoor:CannotRegisterParticipant"/>
Proposed resoltuion accepted on TC Telcon
i003
i004
Remove fault 4.4. NoActivity
NoActivity fault is not basic to all conceivable coordination protocols.
ws-coord
spec
schema
design
Alastair Green
Alastair Green
Remove ll. 443-450 of the specification.
Remove l. 104 of the schema document.
Proposed resolution accepted on TC Telcon
i003
i005
Make Register/RegisterResponse retriable
Register/RegisterResponse should be retriable exchange.
ws-coord
ws-ba
spec
design
Alastair Green
Alastair Green
Insert the following text in WS-Coordination spec, Section 3.2
"Registration Service" immediately following current l. 294
"[New paragraph]The requester MAY send a Register message for a given
Participant more than once, and the underlying transport could deliver
the Register message more than once.
On receipt of a Register message for a
given Participant, which has already been processed succesfully, the
Registration Service MUST send to the
requester a RegisterResponse containing the same
CoordinationProtocolService element (Endpoint Reference for
Participant to Coordinator protocol messages) as that
contained in all
previous RegisterResponses generated by
the Registration Service which relate to the Participant's request to
register for this activity.
[New paragraph]"
See message
Changes to WS-Coordination
Add the following to WS-C, after line 307 (at the end of section 3.2):
"A Registration service is not required to detect duplicate Register
requests and may treat each Register message as a request to register a
distinct participant.
A participant MAY send multiple Register requests to a Registration
service. For example, it may retry a Register request following a lost
RegisterResponse, or it may fail and restart after registering successfully
but before performing any recoverable work.
If a participant sends multiple Register requests for the same activity,
the participant MUST be prepared to correctly handle duplicate protocol
messages from the coordinator. One simple strategy for accomplishing this
is for the participant to generate a unique reference parameter for each
participant Endpoint Reference that it provides in a Register request. The
manner in which the participant handles duplicate protocol messages depends
on the specific coordination type and coordination protocol."
No changes are required to WS-AT
The state table already illustrates the correct behaviour for the 2 cases:
lost RegResp. Should allow forward progress. See "participant view" state table
for handling of duplicate protocol messages:[event=Prepare, state=PreparedSuccess] ->
"Resend Prepared" [event=Commit, state=None] -> "Send Committed"
reinfection after failure. Should cause failure. See "participant view"
state table for participant handling of protocol messages for an unknown/forgotten activity:
[event=Prepare, state=None] -> "Send Aborted"
Changes to WS-BA
One correction and one clarification required in WS-BA:
(i) Correction: In Appendix B, Table C3 "CoordinatorCompletion - protocol
messages received by Participant", change cell [event=Complete, state=None]
from "Ignore/Ended" to "Send Fault/Ended",
(ii) Clarification: Add the following text after line 218 (description of
the "GetStatus" message):
"A coordinator that is waiting for a participant to initiate the
BusinessAgreementWithParticipantCompletion might use this message to
confirm that the participant is in one of the expected states:
"wsba:Active" or "wsba:Completed". If the participant has failed and
forgotten the activity the Status response will be "wsba:Ended", which must
be treated by the coordinator as a failure condition.
Proposal 2 accepted on TC Telcon.
i008
i009
i014
Remove fault 4.6 AlreadyRegistered
AlreadyRegistered fault is redundant if participant registration is treated as retriable.
ws-coord
spec
schema
design
Alastair Green
Alastair Green
Remove ll. 460-468 of the specification.
Remove l. 99 of the schema document.
Proposed resolution accepted on TC Telcon
i003
i014
Is request-reply MEP useful?
Why not eliminate use of request-reply MEP, thereby simplifying all three specs?
ws-coord
ws-at
spec
design
Alastair Green
Alastair Green
Move all definitional wording relating to message types, MEPs, and
rules relating to use of WS-Addressing headers, to WS-Coordination spec,
and
excise appropriate parts of WS-AT Section 9.
Insert new section in WS-Coordination called "Message Exchanges and Use
of WS-Addressing Headers".
Insert text to the effect that:
"Messages used in WS-Coordination, and in coordination protocols whose
endpoint agents (Coordinators and Participants) exchange addresses
using the WS-Coordination Registration Service, generally fall into
three types: notifications, terminal notifications, and faults.
Notification messages contain a wsa:ReplyTo header; terminal
notifications
MUST NOT contain a wsa:ReplyTo header.
[New paragraph] Two parties may send and resend notifications, faults
and terminal notifications to each other to achieve the full
exchange of
messsages demanded by a particular specified protocol, i.e. to help
execute and terminate exchanges that will ultimately succeed despite
failures or duplicate message deliveries resulting from use of
unreliable transports or from use of retries. Such exchanges are known
as retriable exchanges. Use of retriable exchanges in conjunction with
recoverable endpoint agents allows the creation of reliable exchanges.
WS-Coordination message exchanges, and coordination protocol
specifications which use and reference WS-Coordination, are generally
expected to operate over unreliable transports, and to define adequate
retriable exchanges to assure protocol operation in the face of such
transports. They may in addition define pre-failure state persistence
and post-failure state recovery rules to assure protocol operation in
the face of endpoint agent failures.
"[New paragraph]Each individual protocol must define its particular
valid message sequences, including which messages are terminal
notifications. Terminable exchanges consist of a retriable
conversational sequence of one or more notification messages,
ended by the receipt of a final terminal notification by one party.
The receiver of a terminal notification must not send any further
messages to the
sender of a terminal notification relating to the particular
exchange.
Interminable exchanges between two parties permit one party to resend
notification messages to the other, even if they have received a
notification message which is a valid response to an earlier send.
Exchanges which allow one party learn of the state of the other can
often usefully be defined as interminable exchanges."
These definitions, or improved/more precise wording of the same intent
coming from the editors, can be referenced elsewhere in
WS-Coordination, and in WS-AT and in WS-BA.
See document.
See message.
Proposed resolution 2 accepted on TC Telcon.
i007
i010
i011
Completion protocol should be interminable
Define Completion protocol as "interminable".
ws-at
spec
design
Alastair Green
Alastair Green
Insert into Section 9 text stating:
"The Completion protocol messages Commit, Rollback, Committed and
Aborted are all notification messages.
Commit and Rollback can be sent to by the Initiator to the
Coordinator
even if one of Committed or Aborted has
already been received by the Initiator. The exchanges Commit
- Committed | Aborted, and Rollback - Committed |
Aborted are interminable, therefore."
It is possible for the transaction originator to register as a participant in order to find out the
outcome of the transaction. The issue was closed with no action, during
March 14, 2006 F2F meeting.
i007
i009
i011
Protocols should be terminable
Define BA coordination protocols as "terminable", specifying which messages are terminal
notifications.
ws-ba
spec
design
Alastair Green
Alastair Green
Insert a new section mirroring the classification of WS-AT messages,
such that the coordination protocol messages Exited, Cancelled, Closed and Compensated are terminal
notifications, and the other non-fault messages are notifications.
The resolution to issue 9 addresses this issue. This issue was closed with no action during
March 14, 2006 F2F meeting.
i007
i009
i010
Make precise, permissive statement relating to methods of context propagation
Means of context propagation by application cannot be prescribed by WS-Coordination.
ws-coord
spec
editorial
Alastair Green
Alastair Green
Replace the paragraph (ll. 135-139), which reads:
"The CoordinationContext is a Context type that is used to pass
Coordination information to parties involved in a coordination
service. CoordinationContext elements are placed within application
messages. Conveying a context on an application message is commonly
referred to as flowing the
context. A CoordinationContext provides access to a coordination
registration service, a coordination
type, and relevant extensions."
with the paragraph:
"The CoordinationContext is used by applications to pass Coordination
information to parties involved in an activity. CoordinationContext
elements are propagated to
parties which may need to register Participants for
the activity, using application-defined mechanisms -- e.g.
as a header element of a SOAP application message
sent to such parties. (Conveying a context in an application
message is commonly referred to as flowing the
context.) A CoordinationContext provides access to a coordination
registration service, a coordination type, and relevant extensions."
Replace the statement (ll. 177-178)
"When an application propagates an activity using a coordination
service, applications MUST include a Coordination context in the
outgoing message."
with the following sentence:
"An application may propagate a CoordinationContext element as a child
element
of the Body, or of the Header, of an application SOAP message. [delete
new paragraph and run
on to next sentence]"
(1) Accept first replacement paragraph (lines 135-139) as suggested in the intial proposal.
(2) Reject second replacement proposal in the intial proposal but change the existing text to remove the word
"outgoing" in line 178.
Proposal 2 was made and accepted on TC Telcon.
i013
Remove fault 4.5 ContextRefused
ContextRefused fault relates to application protocol behaviour which should not be specified by WS- Coordination.
ws-coord
spec
schema
design
Alastair Green
Alastair Green
Remove ll. 451-459 of the specification.
Remove l. 100 of the schema document.
Proposed resoltuion accepted on TC Telcon
i003
EPR equality comparison is problematic
EPR comparison to establish identity of participants is problematic.
Additional mechanism required to identify Participants.
ws-coord
spec
schema
design
Alastair Green
Peter Furniss
There are three possible resolutions that come to mind.
One is to allow a brand-new IRI element in Register, e.g.
/Register/Identifier, which mirrors the /CoordinationContext/Identifier.
The other is to define an extension IRI element, for WS-Coordination,
that can be added into the RS EPR
(/CoordinationContext/RegistrationService), to identify the Coordinator;
and into the C-P EPR (the
/Register/ParticipantProtocolService) to identify the Participant. This
would be permitted, as we see it, by
the WS-Addressing statement quoted earlier:
"However, note that it is possible for other specifications to
provide a comparison function that is
applicable within a limited scope."
The third is to ask WS-Addressing to provide a standard comparable
element in the EPR. This seems extremely
unlikely, as the move to Candidate Recommendation from Submisssion
removed the capacity to compare EPRs.
EPR comparisons cannot be used reliably. This issue was dropped with no action during
March 14, 2006 F2F meeting.
i007
i008
Replace namespace and action URIs
Replace namespace and action URIs of the form
href="http://schemas.xmlsoap.org/ws/2004/10/">http://schemas.xmlsoap.org/ws/2004/10/... with URIs that follow OASIS
namespace guidelines.
ws-coord
ws-at
ws-ba
all
design
Ian Robinson
Ian Robinson
In the following URIs, replace http://schemas.xmlsoap.org/ws/2004/10/...
with
http://docs.oasis-open.org/wstx/2005/11/...
http://schemas.xmlsoap.org/ws/2004/10/wscoor ws-c line 82
http://schemas.xmlsoap.org/ws/2004/10/wscoor/Register ws-c line 87
http://schemas.xmlsoap.org/ws/2004/10/wscoor/fault ws-c line 373
http://schemas.xmlsoap.org/ws/2004/10/wsat ws-at line 16
http://schemas.xmlsoap.org/ws/2004/10/wsat/Commit ws-at line 21
http://schemas.xmlsoap.org/ws/2004/10/wsat/Completion ws-at line 106
http://schemas.xmlsoap.org/ws/2004/10/wsat/Volatile2PC ws-at line 138
http://schemas.xmlsoap.org/ws/2004/10/wsat/Durable2PC ws-at line 145
http://schemas.xmlsoap.org/ws/2004/10/wsat/fault ws-at line 279
http://schemas.xmlsoap.org/ws/2004/10/wsba ws-ba line 78
http://schemas.xmlsoap.org/ws/2004/10/wsba/Complete ws-ba line 83
http://schemas.xmlsoap.org/ws/2004/10/wsba/AtomicOutcome ws-ba line
125, 141, 253
http://schemas.xmlsoap.org/ws/2004/10/wsba/MixedOutcome ws-ba line
126,142, 257
http://schemas.xmlsoap.org/ws/2004/10/wsba/ParticipantCompletion ws-ba
line 162
http://schemas.xmlsoap.org/ws/2004/10/wsba/CoordinatorCompletion ws-ba
line 230
http://www.msn.com
See message.
Proposal 2 accepted on TC Telcon.
ReplaceParticipant
In order to coordinate long running interactions, it is necessary to
tolerate failures and recovery situations within the scope of an
activity (long running activity). Once a participant is registered with
a coordinator, the current specification implicitly mandates that
recovery requires it to come back up on the same EPR in order that the
coordinator can subsequently drive it through whatever protocol is used
(e.g., 2PC). However, recovery on the same EPR cannot be guaranteed and
is at best an implementation choice. Failure to recover on the same EPR
will ultimately lead to more coordinated activities terminating in a
failure state (e.g., aborting) because participants cannot be reached,
even if they failed and recovered prior to the start of execution of the
coordinator's protocol.
ws-coord
spec
schema
design
Mark Little
Mark Little
That we add a ReplaceParticipant operation that allows a registering
service to instruct the coordinator service to replace one EPR with
another EPR. Because EPRs are not currently comparable, a resolution of
issue 7 or 14 is relevant to this issue.
No need to specify a mechanism for recovery, since it is implementation specific.
This issue was closed with no action during
March 14, 2006 F2F meeting.
Inconsistencies in OASIS templates
Inconsistencies in how contributed specifications were mapped to the OASIS template.
ws-coord
ws-at
ws-ba
spec
editorial
Colleen Evans
Colleen Evans
1. Use a consistent title format. Suggest:
Web Services xxx (WS-xxx)
Working Draft 1.1, [date]
2. Remove duplicate appendix listings.
3. Add the composable architecture section to BA between 1.1 and 1.2.
4. Remove distinction between normative and non-normative references in BA at this stage (we can add that distinction to later drafts if desired).
5. Move AT references up to be the final sub-section in 1 (1.5)
6. Add original spec authors and acknowledged individuals to the acknowledgement sections of AT and BA.
Proposed resolution accepted on TC Telcon
split out of 002 a) - Distinguish example from normative, for subordinated
CreateCoordinationContext behaviour
Precisely specify normative behaviour of CreateCoordinationContext
against existing (superior) context.
ws-coord
spec
design
Alastair Green
Alastair Green
Editorial work required to clarify example, and accompanying figure, and
to create a section that describes the model and normative operation of
sub-coordination.
See message.
Refer to document.
The document has change markings, beginning in section 3, line 182.
Proposal 2 accepted on TC Telcon.
i002
i019
i020
i021
Split out 002 b)-- Avoid normative reference to subcoordinator identifier inheritance
Avoid any normative reference to subcoordinator identifier inheritance.
ws-coord
spec
design
Alastair Green
Alastair Green
Remove any normative reference to subcoordinator identifier inheritance in WS-Coordination.
See message.
Refer to document.
The document has change markings, beginning in section 3, line 182.
Proposal 2 was accepted on TC Telcon.
i002
i018
i020
i021
Split out 002 c) -- Avoid normative statements on sameness of super- and sub-coordinator coordination types
Avoid normative statements on sameness of super- and sub-coordinator coordination types.
ws-coord
spec
design
Alastair Green
Alastair Green
Remove any normative statement relating to sameness of superior and sub-coordinator coordination types or protocols.
See message.
Refer to document.
The document has change markings, beginning in section 3, line 182.
Proposal 2 was accepted on TC Telcon.
i002
i018
i019
i021
Split out 002 d) -- Avoid normative statements on timing of sub-coordinator registration
Avoid normative statements on timing of sub-coordinator registration.
ws-coord
spec
design
Alastair Green
Alastair Green
Remove any normative statement relating to the timing of sub-coordinator registration, other than to state
that the sub-coordinator must be registered to take part in activity completion.
See message.
Refer to document.
The document has change markings, beginning in section 3, line 182.
Proposal 2 was accepted on TC Telcon.
i002
i018
i019
i020
WS-C: Clarify normative requirements for MU attribute
Lines 179-180 outline a condition where mustUnderstand is required, however the current text does not
reflect the normative nature of this requirement.
ws-coord
spec
editorial
Colleen Evans
Colleen Evans
Replace the text:
"When a context is exchanged as a SOAP header, the mustUnderstand attribute must be present and its value must be true."
With:
"When a context is exchanged as a SOAP header, the mustUnderstand attribute MUST be present and its value MUST be true."
Proposed resolution accepted on TC Telcon.
Definition of expires is unclear
The definition of expires is arguably incomplete and as a result unclear.
The unit is only defined w.r.t CreateCoordinationContext in the WS-C spec where
it is specified as milliseconds, no unit is defined for the inclusion of expires
in a CoordinationContext. The period to which expires refers is not specified
anywhere. The example in the WS-C spec (line 153) where it is 3000 would appear
to imply that it is a period of time sincethe creation or import of the coordination
context however the text in the AT and BA specs describes expires as specifying a
"point in time" which could be interpreted as implying expires represents a period
since the epoch.
ws-coord
ws-at
ws-ba
spec
editorial
Andy Wilkinson
Andy Wilkinson
WS-Coordination:
Add a new paragraph within section 2 to compliment the description on lines 236 and 237 that reads:
Expires is an optional element which represents the remaining expiration for the CoordinationContext
as an unsigned integer in milliseconds.
WS-AT:
Amend lines 76 - 79 by replacing "the earliest point in time at which" with "the period after which"
such that they read:
A coordination context may have an Expires attribute. This attribute specifies the period after which
a transaction may be terminated solely due to its length of operation. From that point forward, the
transaction manager may elect to unilaterally roll back the transaction, so long as it has not transmitted
a Commit or a Prepared notification.
WS-BA:
Amend lines 134 - 136 by replacing "the earliest point in time at which" with "the period after which"
such that they read:
A coordination context may have an Expires attribute. This attribute specifies the period after which
a long-running activity may be terminated solely due to its length of operation. A participant could terminate its
participation in the long running activity using the Exit protocol message.
WS-Coordination:
Add a new paragraph within section 2 to compliment the description on lines 236 and 237 that reads:
Expires is an optional element which represents the remaining expiration for the CoordinationContext
as an unsigned integer in milliseconds to be measured from the point at which the context was first
received.
WS-AT:
Amend lines 76 - 79 by replacing "the earliest point in time at which" with "the period after which"
and defining the point from which expiration is measured such that they read:
A coordination context may have an Expires attribute. This attribute specifies the period, measured from
the point in time at which the context was first received, after which a transaction
may be terminated solely due to its length of operation. From that point forward, the transaction manager
may elect to unilaterally roll back the transaction, so long as it has not transmitted a Commit or a Prepared
notification.
WS-BA:
Amend lines 134 - 136 by replacing "the earliest point in time at which" with "the period after which"
and defining the point from which expiration is measured such that they read:
A coordination context may have an Expires attribute. This attribute specifies the period, measured from
the point in time at which the context was first received, after which a long-running
activity may be terminated solely due to its length of operation. A participant could terminate its
participation in the long running activity using the Exit protocol message.
Proposal 2 was accepted during
March 14, 2006 F2F meeting.
Incorrect links in Reference section
WS-AT specification:
Section 1.6 Non-normative References, PDF line number 50, hyperlink for text
'Web Services Coordination (WS-Coordination)' currently points to an incorrect link
http://schemas.xmlsoap.org/ws/2004/10/coord. The correct link is
http://schemas.xmlsoap.org/ws/2004/10/wscoor.
WS-BA specification:
Section 1.6 Non-normative References, PDF line number 103, the text 'Web Services Coordination
(WS-Coordination)' should link to http://schemas.xmlsoap.org/ws/2004/10/wscoor.
WS-Coordination specification:
Section 1.8 References, PDF line number 114: The text 'Web Services Atomic Transaction
(WS-AtomicTransaction)' should link to http://schemas.xmlsoap.org/ws/2004/10/wsat.
The links in the References section of all the three generated PDF documents are not
navigable.
ws-coord
ws-ba
ws-at
spec
editorial
Ram Jeyaraman
Ram Jeyaraman
WS-AT specification:
Section 1.6 Non-normative References, PDF line number 50, hyperlink for text 'Web Services
Coordination (WS-Coordination)' currently points to an incorrect link
http://schemas.xmlsoap.org/ws/2004/10/coord. The correct link is
http://docs.oasis-open.org/ws-tx/wscoor/2006/03.
WS-BA specification:
Section 1.6 Non-normative References, PDF line number 103, the text 'Web Services Coordination
(WS-Coordination)' should link to http://docs.oasis-open.org/ws-tx/wscoor/2006/03.
WS-Coordination specification:
Section 1.8 References, PDF line number 114: The text 'Web Services Atomic Transaction
(WS-AtomicTransaction)' should link to http://docs.oasis-open.org/ws-tx/wsat/2006/03.
The links in the References section of all the three generated PDF documents should be
navigable.
Proposed resolution accepted on
TC Telcon.
Typo in BA WD-02
On the first page, under Status, the latest WS-BA draft states:
"This document is published by the WS-Tx TX as a "working draft".
ws-ba
spec
editorial
Mark Little
Tom Freund
Should be "This document is published by the WS-TX TC as a "working draft"."
The proposed resolution was accepted during
March 14, 2006 F2F meeting.
The resolution is already incorporated in the cd-01 draft.
Include copy of XSD and WSDL in Appendix section
The WS-Coordination, WS-AT and WS-BA specifications should include an inline (embedded) copy of the
corresponding WSDL and XSD in the Appendix section. This will ensure that a printed copy of the
specification will contain the prescribed definitions. For example, please refer to the RM
specification http://www.oasis-open.org/committees/download.php/16851/wsrm-1.1-spec-wd-10.pdf,
PDF line numbers 618 and 1174.
ws-coord
ws-at
ws-ba
spec
editorial
Ram Jeyaraman
Ram Jeyaraman
Include an inline copy of the XSD and WSDL in the specification.
The Schema and WSDL files are normative. The specification already provides pointers to the
Schema and WSDL files. For convenience, the specification, WSDL and Schema shall be packaged in a
ZIP file, and made available as a downloadable file.
Proposal 2 was accepted during
March 14, 2006 F2F meeting.
Use visible URLs in References section
WS-Coordination specification: PDF Line numbers: 104-133.
WS-BA specification: PDF Line numbers: 94-126.
WS-AT specification: PDF Line numbers: 35-76.
The reference links contained in the References section should use visible URLs, in order to
enhance readability for those with accessibility problems.
ws-coord
ws-at
ws-ba
spec
editorial
Ram Jeyaraman
Ram Jeyaraman
Use visible URLs in References section.
The proposed resolution was accepted during
March 14, 2006 F2F meeting.
Resolve which version of WS-Addressing Specification to reference
WS-Coordination specification: PDF Line numbers: table row after line 84 with ns prefix wsa,
113-114, 147.
WS-BA specification: PDF Line numbers: 107-108.
WS-AT specification: PDF Line numbers: 51-53.
To assist in discussions concerning the usage of WS-Addressing in the OASIS WS-TX specifications,
it should be resolved whether the current 2004/08 WS-Addressing
(http://www.w3.org/Submission/2004/SUBM-ws-addressing-20040810/) or the W3C WS-Addressing
specification (http://www.w3.org/TR/2005/CR-ws-addr-core-20050817/) is the target WS-Addressing
specification.
ws-coord
ws-at
ws-ba
spec
design
Joseph Fialli
Joseph Fialli
In the interest of looking forward, it would be best to update to the newest revision
of the WS-Addressing specification.
Update the WS-Coordination, WS-AT, and WS-BA specifications to reference the
current PR submission draft of the WS-Addressing
specification (http://www.w3.org/2005/08/addressing). The resolution to issue 30 should
describe the effect this change has on the replyTo semantics. The resolution was accepted
on April 06, 2006 TC call.
wsa:MessageID should be explicitly required for WS-AT non-terminal notification message
WS-AT specification: PDF Line numbers: 475-477, 481-482.
Under Section 9 "Use of WS-Addressing Headers", non-terminal notification messages MUST have
a wsa:ReplyTo but is silent on wsa:MessageID. 2004 WS-Addressing specification requires
wsa:MessageID when wsa:ReplyTo exists.
ws-at
spec
design
Joseph Fialli
Joseph Fialli
Add bullet "MUST include a wsa:ReplyTo header" to Non-terminal notification messages. (line 481-482).
Instead of updating individual issues, a larger issue is to check and update all usages of
WS-Addressing in the WS-TX specifications to be consistent with the latest WS-Addressing
specification. This issue was closed with no action during
March 14, 2006 F2F meeting.
One-way message replies
WS-AT specification: PDF Line numbers: Line 472 and 480.
Currently we use wsa:ReplyTo for one-way messages in a way which although legal in terms of the
latest CR draft of WS-Addressing, has led to confusion on a number of occasions. As an example, one
use of wsa:ReplyTo is on Prepare->Prepared, where Prepare has a wsa:ReplyTo but the Prepared
message is a separate (not response) message, because it could be sent autonomously and not
actually in response to Prepare. The issue is that as far as WS-Addressing is concerned,
wsa:ReplyTo should really only be used in the case of the request-response MEP, which is clearly
not the case here.
ws-at
spec
design
Mark Little
Mark Little
The rules for where and when wsa:ReplyTo should be included and used within WS-AT are well defined,
and particularly in respect to the interoperability scenarios. I propose that we replace
wsa:ReplyTo with something specific to WS-TX (perhaps wsc:ReplyTo, wsc:OnewayTo, or somesuch).
Addendum: Max suggested at the Raleigh f2f another potential resolution: that we use
wsa:From.
See proposal.
Proposal 2 was accepted during
May 04, 2006 TC call.
Requirement for coordinator driven
WS-BA specification: Section 3.2, lines 244-258.
BusinessAgreementWithCoordinatorCompletion is not tested for in the interoperability scenarios.
This either needs to be fixed, with some scenarios added, or we should remove the protocol.
I haven't seen any good arguments for why we should have this protocol within the BusinessActivity
specification. If there is a requirement, then it seems more appropriate for a separate model
(i.e., specification) to host this.
ws-ba
spec
design
Mark Little
Mark Little
Remove BusinessAgreementWithCoordinatorCompletion.
Closed with no action. New interop scenarios to cover CoordinatorCompletion protocol
has been added to the BA interop scenarios document. This resolution was accepted during the
August 29-31, 2006 F2F meeting.
Requirement for MixedOutcome
WS-BA specification: Section 3, lines 151-168.
The MixedOutcome is not tested for in the interoperability scenarios (AtomicOutcome is).
This either needs to be fixed, with some scenarios added, or we should remove the capability.
I haven't seen any good arguments for why we should have this protocol within the BusinessActivity
specification. If there is a requirement, then it seems more appropriate for a separate model
(i.e., specification) to host this.
ws-ba
spec
design
Mark Little
Mark Little
Remove MixedOutcome.
Closed with no action. New interop scenarios to cover MixedOutcome coordination type
has been added to the BA interop scenarios document. This resolution was accepted
during the
August 29-31, 2006 F2F meeting.
Definition of CurrentContext
WS-Coordination specification: PDF line numbers 238-240.
Make precise statement on meaning (at WS-C level) of /CreateCoordinationContext/CurrentContext.
The presence of this element has no meaning other than: a relationship of some kind is being
created between an existing context and a new context.
Details: In the course of discussions leading to resolution of issues 018 - 021, it seemed that differing
interpretations and assumptions were likely when considering the meaning of the presence of the
CurrentCoordinationContext element in the CreateCoordinationContext message. For example: under
some circumstances (sub-coordination for an atomic outcome protocol) one might consider that the
new and existing contexts were representations of the same overall activity (the atomic transaction
tree). In that case, and in others, the presence of the relationship might subsequently be
expressed in the sending of Register to the RS of the existing (current) context. However,
in principle, the statement of relationship might be expressed in ways that do not involve use
of Register.
ws-coord
spec
editorial
Alastair Green
Alastair Green
The document drafted
by Max Feingold as a result of discussions on the 018-021 AI, seems like the right kind of wording,
in the light of the above.
The proposed resolution was accepted during
May 04, 2006 TC call.
i018
i019
i020
i021
WS-AT: Define meaning/use of CurrentContext
WS-AT specification: New section required.
Make precise statement on meaning (for WS-AT) of /CreateCoordinationContext/CurrentContext.
WS-AT should state purpose and meaning of /CreateCoordinationContext/CurrentContext.
The WS-C statement is very general.
ws-at
spec
editorial
Alastair Green
Alastair Green
The document
(2006-03-21.Guaranteeing.Atomicity.of.Transaction.Tree.doc) contains a new section that
a) defines the behaviour I deduce is intended and b) avoids stating whether a lazy or eager
registration approach is taken (treating that as an implementation issue).
Closed with no change during
May 04, 2006 TC call.
i018
i019
i020
i021
ws-tx: term "coordinator" overloaded
The term "Coordinator" or "coordinator" is used with three distinct meanings:
A) as a synonym for "coordination service";
B) to describe the logical entity that coordinates all of the participants
registered for a transaction;
C) to describe the logical entity that executes a coordination protocol with
respect to a single participant.
These have different lifecycles and undergo distinct (though sometimes related)
state transitions. Distinct terms should be used for each meaning and used consistently
across the set of the specifications, to avoid ambiguity and confusion.
Details:
Meaning A:
WS-Coordination explicitly offers "coordinator" as a synonym for "coordination
service" (lines 16, 181, 627), and uses the term in that sense in other places
(e.g. figure 1, lines 31, 318).
This sense is used in WS-BA line 159 and 160 (strictly that is "implementation of
a coordination service").
An A-Coordinator is a service with an indefinite lifetime, greater than a single
coordinated activity and with no defined states.
Meaning B:
In WS-C the term Coordinator is also used to mean: the entity whose registration
EPR and identifier is tranmitted in a CoordinationContext, and which is capable of
receiving registrations of multiple participants. ("B-Coordinator"). WS-Coordination
sometimes uses the term "coordination context" to refer to this entity (line 514),
though usually "coordination context" means the transmissable datatype, as in
lines 140-175.
In WS-AT, "coordinator" is normally used in this sense (e.g. lines 95, 116, all of
section 4.3.3). (In some cases, "coordination service" would be a meaningful
alternative, in others not - which indicate it is not a synonym as in sense A).
In WS-BA, "coordinator" is clearly of this sense in lines 157 and 158.
A B-coordinator is state entity created with the CreateCoordinationContext and
ending when all activity is over and it is forgotten (exact details of its termination
depend on the coordination type)
Meaning C:
The term Coordinator is also used in WS-BA to mean: the sub-entity of a
B-Coordinator that handles the execution of a protocol with respect to a single
participant ("C-Coordinator").
The WS-AT does not use "coordinator" in quite this sense - the state tables appear
to (but see separate issue) but lines 494-496 distinguish coordinator (sense B) and the
state machines.
In WS-BA, lines 221-234 use coordinator in sense C (since they refer to the state
of a coordinator without regard to other participants) as do the state tables.
A C-Coordinator is a state entity created when a Register message is received
(if received when B-Coordinator is in appropriate state), and ending when the
relationship with the participant is terminated (details depend on coordination type
and protocol)
It might be possible to push the interpretation of coordinator = "coordination
service" in many cases, but it would seem unnatural. Understanding "coordinator" to
mean sometimes "the continuing coordination service, used by numerous transactions",
sometimes "a coordination service's view of a particular transaction" and sometimes
"a coordination service's view of the state of a registered relationship with a
particular participant service" is not helpful. A state entity should have a name,
not be the anonymous view of a state from the perspective of a general entity.
ws-coord
ws-at
ws-ba
spec
editorial
Peter Furniss
Peter Furniss
A. WS-C: remove all references to "coordinator" that mean A-Coordinator, and
replace them with "coordination service".
B. WS-C/AT/BA: use the term "Coordinator" for B-Coordinator exclusively.
C. WS-AT/BA: use the term "Bilateral Coordinator" for C-Coordinator,
e.g. "Bilateral Coordinator View" in describing the coordinator view in a state table
title.
Closed with no change during
August 10, 2006 TC call.
WS-AT: Coordinator state machine incomplete
WS-AT specification: section 10, lines 493 - 510.
The WS-AT coordinator state tables do not provide explanation of what the states or
internal events are, and do not provide specification of the interactions between the
completion, volatile and durable protocols.
Details:
The WS-AT state tables are described as showing " the view of a coordinator or
participant with respect to a single partner. A coordinator with multiple participants
can be understood as a collection of independent coordinator state machines". In fact
they appear to use the states and internal events of the multi-lateral coordinator but
inbound events for a single partner. In the absence of any explanation, especially of
the internal events, this is confusing (and there seem to be some inconsistencies).
There is also little or no specification in the state tables of the interactions between
the completion, volatile and durable protocols (which essentially determine that the
transaction is atomic).
Evidence of multilateralism: A bilateral state engine will move from None to Active on
receiving Register. "Active" thus has to be interpreted as the state of the
multilateral coordinator. Receipt of ReadOnly would cause a bilateral state engine to
go from Active to None - the tables show it as having no effect on the state.
Lack of protocol interaction: the tables provide no specification of the
volatile-first behaviour - except perhaps in the Register/Preparing cell,
which is cannot be harmonised with the rest of the table (see separate issue).
If "User Commit" is to be interpreted as Commit on the Completion protocol
(or its non-standardised equivalent), then a Prepare shouldn't be sent to a Durable
Participant until all the Volatiles have replied.
The Commit Decision event is presumably meant to occur when all participants have
replied Prepared or ReadOnly, but according to the state table it could occur any
time after Prepare has been sent.
ws-at
spec
design
Peter Furniss
Peter Furniss
Create separate tables for the multilateral and bilateral relationships, and define what
all the states and events mean.
See
email.
Proposal 2 was accepted during
June 29th, 2006 TC call.
i035
i037
WS-AT: Register/Preparing in coordinator state table problematic
WS-AT specification: section 10, lines 503/504: table row Register, column Preparing.
The cell Register/Preparing cannot be interpreted in a way that is consistent with both
the rest of the state table and with section 4.3.1 (lines 178-180).
Details:
The states of the WS-AT have to be interpreted as the state of the multi-lateral
coordinator - events occur that change the state of a bilateral relationship, but do
not not change the state in the table (see issue Coordinator state machine unclear
and incomplete).
Of the three cells that have different behaviour for volatile and durable protocols,
the two in the None state have to be understood to mean that a message from a
durable participant causes the Durable: behaviour, from a volatile participant the
Volatile: (since there is no modelled knowledge of the participant, this has to be
the case).
However, according to section 4.3.1 (and common practice in other protocols), new
registrations are permitted while volatile participants are being prepared. The only
way to interpret the Register/Preparing cell to align with that would be to declare
that the "Preparing" state is that of a bilateral relationship, and the
Volatile/Durable refers to the type of that relationship, and not that in the
Register.
This contradicts both the meaning of Volatile: Durable: in the other cells, and the
multi-lateral interpretation of the states.
ws-at
spec
design
Peter Furniss
Peter Furniss
This will be resolved if separate tables for the multilateral and bilateral
relationships are created as proposed for the issue WS-AT: Coordinator state machine
unclear and incomplete issue.
See email.
Summary:
1. Remove the 2 Register/RegisterResponse rows from the 2PC state tables.
2. Augment the text in section 4.3.1 so that we do not lose any information
as a result of removing these rows.
Agreed text: "Further participants may register with the coordinator until
the coordinator issues a Prepare to any durable participant. Once this has happened
the Registration Service for the coordinator MUST respond to any further Register
request with a Cannot Register Participant fault message".
Note to editors: Please ensure that the space delimited form of the fault
'Cannot Register Participant' is used, instead of 'CannotRegisterParticipant',
across all occurences.
Proposal 2 was accepted during
June 15, 2006 TC meeting.
i036
WS-AT: Incomplete actions on expiry
WS-AT specification: ws-at section 10, lines 503/505;
participant table: Expires times out/Active, /Preparing;
ws-at: seciton 6.1, line 371.
The cells for Expires Times out for Active and Prepared states should include the
(internal) Initiate Rollback and Forget actions.
Details:
Expires Times out should trigger the same internal events as receipt of rollback -
otherwise the state machine will never exit.
(An argument could be raised that the "initiate rollback" action is superfluous,
since the corresponding actions on the bound data [the application-dependent state
that will be changed by the transaction if it commits] for preparing and committing
are not mentioned. But the point of this issue that Expires Times out and received
rollback should trigger the same internal actions, however those are specified).
ws-at
spec
design
Peter Furniss
Peter Furniss
Make the Expires Times out cells for Active and Preparing states the same as the
Rollback cell.
Proposal was accepted during
July 13, 2006 TC call.
WS-AT: Coordinator should not distinguish protocol of orphaned participants
WS-AT specification: section 10, lines 503/505 tables rows Prepared, Relay, column None.
The requirement that a coordinator with no current knowledge of a participant can
determine which protocol it previously registered with from an incoming Prepared
or Replay messages imposes unnecessary requirements on implementations. The desired
functionality can be achieved with a common response to all such messages from
"orphans", and letting the participant interpret that response.
Since a returned fault does not show in the state tables, there is currently no behaviour
specified for the volatile participant that sent the Replay or Prepared (this will
become a separate issue if the main one is rejected, but it gets subsumed if this is
fixed).
Details:
Background:
The None state for WS-AT means that there is no record of the transaction - either
because the transaction completed (rolledback or committed) or the coordinator
crashed (and thus implicitly rolledback). Among correct implementations, Prepared
and Replay messages received in the None state can only come from participants that
were registered prior to the completion or crash, but did not receive a Commit or
Rollback message.
For a durable participant, this cannot happen if the transaction committed - the
coordinator cannot forget the transaction until it has received Committed
from the durable participant. Thus if the Prepared or Replay are received from a
durable participant in the None state, it can be inferred with certainty that the
transaction rolledback (by intent or crash).
For volatile participants however, it is legitimate for the coordinator to delete its
commit log record after receiving Committed from all durable participants, without
waiting for any response from volatile participants. If there is a crash at this
point (or just some lost messages), Prepared or Replay can be received from a
volatile participant and find the coordinator in state "None".
The issue:
The specification currently requires that the coordinator distinguish between the
two kinds of registration. This in turn requires that there is something about the
Prepared or Replay message that allows the coordinator to determine the protocol of
the forgotten registration (ipso facto, it has no specific, local information). Since
there is nothing in the Prepared or Replay messages as such, this can only be something
carried in or implied from the addressing for the coordinator. Although this can of
course be done, and for some implementations may be entirely natural (e.g. if they
have twinned-but-distinct multi-lateral coordinators for volatile and durable), for
others it will be unnatural.
There seems no reason for imposing this peculiarity (other perhaps than the
unstated aesthetic that the coordinator has the driving seat in this protocol). If the
coordinator gave the same response to Prepared/Replay from either protocol, it would be
up to the participant to determine how it should treat this response. Since the
participant certainly knows how it registered, there would be no ambiguity.
(This issue has been distinguished from the question of using Invalid State in the
volatile case - it would be even worse to use for InvalidState for the both
protocols).
There is currently no defined behaviour for the volatile participant that sends
Replay or Prepared (since fault behaviour is not defined).
ws-at
spec
design
Peter Furniss
Peter Furniss
Define new message UnknownTransactionOutcome.
Amend state table for Coordinator to send the new message when Prepared or Replay
are received in state None.
Amend state table for Participant with row for inbound "UnknownTransactionOutcome"
this is invalid (shouldn't happen) in all states except PreparedSuccess.
in PreparedSuccess
if participant is Durable action is Initiate Rollback and Forget,
transition to Aborting.
if participant is Volatile, action is Forget, transition to new state
UnknownOutcome.
UnknownOutcome state has transition to None on All Forgotten event. All other
Inbound Events are ignored, without transition.
Define new fault UnknownTransaction.
Amend state table for Coordinator to send the new fault to volatile participants,
when Prepared or Replay are received in state None.
Proposal 2 was accepted during
May 31 - June 01, 2006 (Dublin) F2F meeting.
i043
WS-AT: Coordinator should not distinguish protocol of orphaned participants
WS-AT specification: section 10, lines 503/505 tables rows Prepared, Relay, column None.
The requirement that a coordinator with no current knowledge of a participant can
determine which protocol it previously registered with from an incoming Prepared
or Replay messages imposes unnecessary requirements on implementations. The desired
functionality can be achieved with a common response to all such messages from
"orphans", and letting the participant interpret that response.
Since a returned fault does not show in the state tables, there is currently no behaviour
specified for the volatile participant that sent the Replay or Prepared (this will
become a separate issue if the main one is rejected, but it gets subsumed if this is
fixed).
Details:
Background:
The None state for WS-AT means that there is no record of the transaction - either
because the transaction completed (rolledback or committed) or the coordinator
crashed (and thus implicitly rolledback). Among correct implementations, Prepared
and Replay messages received in the None state can only come from participants that
were registered prior to the completion or crash, but did not receive a Commit or
Rollback message.
For a durable participant, this cannot happen if the transaction committed - the
coordinator cannot forget the transaction until it has received Committed
from the durable participant. Thus if the Prepared or Replay are received from a
durable participant in the None state, it can be inferred with certainty that the
transaction rolledback (by intent or crash).
For volatile participants however, it is legitimate for the coordinator to delete its
commit log record after receiving Committed from all durable participants, without
waiting for any response from volatile participants. If there is a crash at this
point (or just some lost messages), Prepared or Replay can be received from a
volatile participant and find the coordinator in state "None".
The issue:
The specification currently requires that the coordinator distinguish between the
two kinds of registration. This in turn requires that there is something about the
Prepared or Replay message that allows the coordinator to determine the protocol of
the forgotten registration (ipso facto, it has no specific, local information). Since
there is nothing in the Prepared or Replay messages as such, this can only be something
carried in or implied from the addressing for the coordinator. Although this can of
course be done, and for some implementations may be entirely natural (e.g. if they
have twinned-but-distinct multi-lateral coordinators for volatile and durable), for
others it will be unnatural.
There seems no reason for imposing this peculiarity (other perhaps than the
unstated aesthetic that the coordinator has the driving seat in this protocol). If the
coordinator gave the same response to Prepared/Replay from either protocol, it would be
up to the participant to determine how it should treat this response. Since the
participant certainly knows how it registered, there would be no ambiguity.
(This issue has been distinguished from the question of using Invalid State in the
volatile case - it would be even worse to use for InvalidState for the both
protocols).
There is currently no defined behaviour for the volatile participant that sends
Replay or Prepared (since fault behaviour is not defined).
ws-at
spec
design
Peter Furniss
Peter Furniss
Define new message UnknownTransactionOutcome.
Amend state table for Coordinator to send the new message when Prepared or Replay
are received in state None.
Amend state table for Participant with row for inbound "UnknownTransactionOutcome"
this is invalid (shouldn't happen) in all states except PreparedSuccess.
in PreparedSuccess
if participant is Durable action is Initiate Rollback and Forget,
transition to Aborting.
if participant is Volatile, action is Forget, transition to new state
UnknownOutcome.
UnknownOutcome state has transition to None on All Forgotten event. All other
Inbound Events are ignored, without transition.
Duplicate of issue i039. This issue was dropped during April 06, 2006 TC call.
i043
WS-AT: Invalid events should not cause defined transitions
WS-AT specification: ws-at section 10, lines 503/505;
coordinator table: Committed/Active, Committed/Preparing;
pariticipant table: Commit/Active, Commit/Preparing;
ws-at: seciton 6.1, line 371.
The receipt of a message when the receiver is in a state such that the event cannot
occur between correct implementations should not cause a state transition and allow
the transaction to complete "successfully". There is no need to distinguish
"InvalidState" and "InconsistentInternalState".
Details:
Background:
InvalidState is defined in WS-Coordinator as being an unrecoverable condition,
and in all the cases where it is a defined response in the WS-AT tables can only
occur if one of the implementations is broken/bugged (apart than the volatile
Prepared/None case, see separate issue). Providing a defined state transition,
as if the circumstance were expected and could be recovered from is inappropriate.
There can be no graceful completion of the protocol - it has gone fundamentally
wrong. This does not preclude an implementation from attempting to tidy up
and protecting its own resources, but there should be no required state transition
for the implementation. The protocol exchange has gone off the map.
The use of InconsistentInternalState to distinguish two cases where an invalid
event occurs is unnecessary (and the definition in line 371 does not align with the
use in the table - it is probably the coordinator that has been sending wrong messages).
The use of InvalidState is appropriate in all cases.
ws-at
spec
design
Peter Furniss
Peter Furniss
The clearest solution would be to make invalid cells in the state tables empty,
for the cells currently shown as InvalidState or InconsistentInternalState,
and also for the N/A cells and explain this with text:
"Where a cell is shown as empty
- if the row is for an Inbound Event, an WS-C Invalid State fault should be returned.
The subsequent behaviour of the implementation is undefined.
- if the row is for an Internal Event, event cannot occur in this state. A TM should
view these occurences as serious internal consistency issues."
Having invalid cells empty makes it significantly easier to read and check the
state tables. It becomes much clearer that they are essentially "sparse" and the
path through the table can be followed more easily.
AT spec wd-08,
Section 6.1, line 375-377:
Modify the definition of InternalInconsistentState fault as,
"Inconsistent Internal State
This fault is sent by a participant or coordinator to indicate that a protocol
violation has been detected after it is no longer possible to change the outcome
of the transaction. This is indicative of a global consistency failure and is an
unrecoverable condition."
Section 6.1, line 380,
Change "[Subcode] wsat:InconsistentInternalState" to
"[Subcode] wsat:Inconsistent Internal State".
Section 10, line 518,
The following cells in the Coordinator View table need to be throw
Inconsistent Internal State fault.
1. {ReadOnly; PreparedSuccess, Committing}
2. {Aborted; PreparedSuccess, Committing}
3. {Committed; PreparedSuccess, Aborting}
Note to Editors: Please ensure all occurences of 'InconsistentInternalState'
fault is replaced with the space delimited form 'Inconsistent Internal State'.
proposal 2 was accepted during
August 10, 2006 TC call.
WS-BA: Swap rows and columns in state tables to make consistent with WS-AT
WS-BA specification: Appendix C, lines 491-524.
The WS-BA state tables show states as rows, and received messages as columns. This is the
opposite to the convention adopted by WS-AT. The two specification should have a
consistent convention, to ease comparison.
ws-ba
spec
editorial
Peter Furniss
Peter Furniss
Change WS-BA state tables to use the same state/column, message/row convention as the
WS-AT spec.
The proposed resolution was accepted during
May 04, 2006 TC call.
WS-AT: Invalid state inappropriate response to orphaned volatile participants
WS-AT specification: section 10, lines 503/505 tables rows Prepared, Relay, column None.
The use of Invalid State as the response to a Prepared or Replay received from a
participant that had a (forgotten) volatile registration is inconsistent with the
definition of Invalid State in WS-Coordination and requires special processing by
implementations to handle this non-fault fault.
Issue Details
Background - see separate issue : Coordinator should not distinguish protocol
of orphaned participants.
The defined meaning of InvalidState in WS-Coordination is "This fault is
sent by either the coordinator or a participant to indicate that the endpoint that
generates the fault has received a message that is not valid for its current state.
This is an unrecoverable condition."
Occurence of InvalidState according to this definition, and in all its other
occurrences in the state tables for WS-AT or WS-BA imply that one or other of the
implementations is bugged. It is to be expected that implementations would report
such a fault conspicuously.
This is an inappropriate message in this instance. The meaning the
coordinator needs to send to the participant is something like: "Legitimate message
received, but transaction outcome is unknown: I can't help you". Since the volatile
participant, by definition, doesn't care very much, implementations will not want
to contaminate their error logs with reporting these occurrences, which can occur
between fully correct implementations. They will either have to insert special code
to identify this circumstance or annoy their users.
ws-at
spec
design
Peter Furniss
Peter Furniss
Use a new message, as proposed for issue WS-AT: Coordinator should not distinguish
protocol of orphaned participants.
Use a new fault UnknownTransaction.
Proposal 2 was accepted during
May 31 - June 01, 2006 (Dublin) F2F meeting.
The line 619 "Request messages MUST contain a [reply endpoint] property whose [address]
property is not set to 'http://www.w3.org/2005/08/addressing/anonymous' or
'http://www.w3.org/2005/08/addressing/none'." has been removed.
i039
WS-C: Clarify which endpoint is used to detect duplicate participant registrations
WS-Coordination specification: ll. 317 - 321. Section 3.2, "Registration Service".
Current text from resolution to 007 implies that
/ParticipantProtocolService endpoint can be used to detect duplicate
registrations.
Issue Details
ll. 317 - 321 read:
"If a participant sends multiple Register requests for the same
activity, the participant MUST be prepared to correctly handle duplicate
protocol messages from the coordinator. One simple strategy for
accomplishing this is for the participant to generate a unique reference
parameter for each participant Endpoint Reference that it provides in a
Register request. The manner in which the participant handles duplicate
protocol messages depends on the specific coordination type and
coordination protocol."
The sentence beginning "One simple strategy ..." is ambiguous (at best)
about which EPR is being referred to. The Register request supplies a
/ParticipantProtocolService EPR, and a wsa:ReplyTo EPR. The strategy
being discussed here can only work if the WS-A [reply endpoint] has a
value that unambiguously identifies (for the registering service) the
participant. The PPS EPR is irrelevant.
Further, message ids could be used by the registering service to achieve
the same level of knowledge of duplication.
ws-coord
spec
design
Alastair Green
Alastair Green
Option 1:
Replace the sentence beginning "One simple strategy ..." with the
following sentence:
"One simple strategy for accomplishing this is for the sender of
Register to ensure that the the WS-Addressing [reply endpoint] Endpoint
Reference that it provides in a Register request identifies the
participant unambiguously from the sender's standpoint."
Option 2:
Replace the sentence beginning "One simple strategy ..." with the
following sentence:
"This can be accomplished either by the sender of Register keeping track
of the message ids of Register messages that refer to the same
participant, or by the sender of Register ensuring that the the
WS-Addressing [reply endpoint] Endpoint Reference that it provides in a
Register request identifies the participant unambiguously from the
sender's standpoint. Each of these techniques will allow duplicate
RegisterResponses which refer to the same participant to be detected by
the requester."
Closed with no action during
May 04, 2006 TC call.
WS-AT: Meaning of "wsp:Optional
WS-AT specification: Section 5.2, lines 242-257.
The use of "wsp:Optional" on /wsat:ATAssertion for conditionally flowing atomic
transaction context in Section 5.2 in WS-AtomicTransaction (WS-AT) is fundamentally
different from the use of "wsp:Optional" meaning "can be present or not".
Issue Details
The "can be present or not" interpretation used in the WS-Policy
(http://schemas.xmlsoap.org/ws/2004/09/policy/) specification as implied by
the description of normalization, where "optional" is described as "an attribute
that is a syntactic shortcut for expressing policy alternatives with and without
the assertion", and is found in Section 4.3, Compact Policy Expression (see
specifically Section 4.3.1).
The basic WS-Policy concept is that *one* set of alternatives is selected for a
given interaction. So, using the WS-Policy [1] specified semantics, a client should
either agree to always provide a transaction context or agree never to provide it.
This implies a service contract where a transaction context is either always present
or always absent.
In contrast in WS-AT, the semantics are "if an atomic transaction context
exist at the time the operation request is invoked, then flow it with the request".
So the client has not agreed to provide a transaction context for all
invocations of the operation request. This is equivalent to client and server
agreeing to support multiple sets of alternatives in the same interaction.
This deviates from standard
WS-Policy semantics; for example, there is no way to say "in this interaction, we
agree to use either AES encryption or 3DES encryption", with the server prepared to
accept both from the same client in the same interaction, which is another variant
of accepting multiple alternatives.
What is the potential impact? A policy parser does not have a standard way to
normalize a policy. The parser has to know whether "optional" means "if a concept
is present, flow it with the request" or if it means "choose one alternative or
the other". This supports our charter that the policy assertions be usable in the
policy framework defined by WS-Policy rather than defining concepts that surround
those functions. Charter located at
http://www.oasis-open.org/committees/ws-tx/charter.php.
ws-at
spec
design
Monica J Martin
Monica J Martin
Refer to the original email
for details on the proposal.
Remove the sentence "Presence of both policy alternatives indicates that the behavior
indicated by the assertion is optional, such that an atomic transaction MAY be flowed
inside a requester's message. The absence of the assertion is interpreted to mean that
a transaction SHOULD NOT be flowed inside a requester's message.".
Further, the change suggested in this email.
Proposal 2 was accepted during
May 31 - June 01, 2006 (Dublin) F2F meeting.
WS-AT: Is logging mandatory?
WS-AT specification: Whole spec, and specifically,
Section 10, "State Tables", Coordinator View table, between ll. 503 and 504,
Participant View table, between ll. 510 and 511.
WS-AT spec only mentions logging in passing, or implicitly.
ll. 393 - 394,(Section 7, "Security Model"):
"The participant can only prove its identity to the coordinator when it
indicates that the specified transaction is not in its log and assumed
committed."
In the state tables the undefined internal events "Write Done" and
"Write Failed" might be taken to mean "persistent write done" and
"persistent write failed" -- or then again they might be taken to mean
"everything still fine" and "something went wrong".
Recovery (usually taken to mean crash recovery, and therefore implying
persistent records) is mentioned in this sense only once, as follows
(ll. 221-223, Section 4.3.3. "2PC Diagram and Notifications"):
"Replay -- Upon receipt of this notification, the coordinator may assume
the participant has suffered a recoverable failure. It should resend the
last appropriate protocol notification."
The design intent may have been either of the following:
A. Do not mandate any persistence or recovery strategy -- the protocol
should be capable of being run in a volatile, no log manner, as well as
using conventional logging techniques. (Dropping the D of ACID).
B. We all know that we mean to log, so let's not bother to mention it.
I believe A. is the correct design intent expressed by the input
document authors at the inaugural TC meeting in November, and editorial
changes should be made that clarify that intent.
ws-at
spec
design
Alastair Green
Alastair Green
a) Amend ll. 94 - 95 to delete the words "not persistent and" from the
following sentence:
"The actions taken prior to commit are only tentative (i.e., not
persistent and not visible to other activities)."
b) Insert after l. 104 a new paragraph as follows:
"While most atomic transaction systems use persistent logs to ensure
consistent execution of transaction completion in the face of
process/processor failure, WS-AtomicTransaction does not mandate any
persistence policy or strategy. Its protocols are capable of being
executed by endpoints which do log, and by those that do not. Quality of
service with respect to crash recovery is left as an implementation,
deployment and run-time issue."
c) Change name of state table actions "Write Done" and "Write Failed" to
"Decision Recorded" and "Decision Unrecorded".
The issue was closed with no action during
July 27, 2006 TC call.
i048
WS-AT: Is Completion protocol mandatory?
WS-AT specification: l. 146, Section 4.2, "Completion Protocol", and
l. 171, Section 4.3, "Two-Phase Commit Protocol".
WS-AT spec could be taken to imply that Completion protocol required to
engender User Commit internal event. Use of Completion protocol should
not be mandated.
ll. 176-177 read: "Upon receiving a Commit notification in the
completion protocol, the root coordinator begins the prepare phase of
all participants registered for the Volatile 2PC protocol."
This is an example of how the state table internal event User Commit can
be engendered. An implementation could use an API method (rather than an
interoperable message) to engender User Commit (truly make it an
"internal event").
ws-at
spec
design
Alastair Green
Alastair Green
a) Add a sentence after the existing sentence ending "... it should
attempt to commit the transaction" (l. 159) that reads:
"Receipt of this notification generates the 2PC Coordinator View state
table internal event User Commit."
b) Add a sentence after the existing sentence ending "... it should
abort the transaction" (l. 162) that reads:
"Receipt of this notification generates the 2PC Coordinator View state
table internal event User Rollback."
c) Add a sentence after the existing sentence ending "... a decision to
commit" (l.166) that reads:
"The action Return Committed in the 2PC Coordinator View state table
engenders the transmission of this notification."
d) Add a sentence after the existing sentence ending "... a decision to
abort" (l.169) that reads:
"The action Return Aborted in the 2PC Coordinator View state table
engenders the transmission of this notification."
e) Replace the sentence at the very end of Section 4.2 "Completion
Protocol", l. 170, which currently reads:
"Conforming implementations must implement Completion.", with the
following:
"Conforming implementations MUST implement the Coordinator role in the
Completion protocol (i.e. be prepared to receive Commit and Rollback,
and to send Committed and Aborted), but need not implement the matching
Initiator role. Applications/implementations may use this protocol to
signal application termination requests to a coordinator, or they may
use an implementation-defined mechanism to stimulate the 2PC Coordinator
View internal events User Commit and User Rollback."
f) Amend the first sentence of Section 4.3 (l. 171) to read:
"Upon the internal event User Commit (which may result from receiving a
Commit notification in the completion protocol) a root coordinator
begins the prepare phase of all participants registered for the Volatile
2PC protocol."
WS-AT specification wd-08,
Replace line 179 with "A coordination service that supports an Activation
service MUST support the Completion protocol.".
proposal 2 was accepted during
August 10, 2006 TC call.
i050
WS-AT: Internal events and actions undefined
WS-AT specification: Section 10, "State Tables", Coordinator View table,
between ll. 503 and 504, Participant View table, between ll. 510 and 511.
None of the user events are defined. Many of the less obvious state
table actions are undefined. This issue attempts to carve out and
resolve a specific sub-issue raised in less detail in issue 036.
While reviewing the AT tables I wrote myself a rough glossary of events
and actions, to make sure I understood the tables correctly. I think
other readers would benefit from the same kind of guidance, so I've
polished it up as a proposed addition to the spec.
The internal events and actions should be defined to avoid
misunderstanding, ambiguity and underspecification, and to achive this,
it is much easier to define them separately for Coordinator View and
Participant View.
For example, "User commit" means "the application has decided to request
the transaction be committed". "Commit decision" means: "The coordinator
has determined that the votes of remaining participants are all in, and
that commit-phase processing can commence; a log of this decision will
now be made."
To take another example: "Record vote" really means "no-op", whereas
"Record Commit" (usually) means "attempt to write a log record".
Or, again: "Record Outcome" means record coordinator wide commit
decision in CV, but "Record Commit" means "record prepared decision" in
PV.
Or, further: "User Commit" is an internal event that could be stimulated
by Completion protocol Commit message being received, and the same,
mutatis mutandis, for "User Rollback".
An allied issue is the use of the term "Return" in state table actions
meaning: send a "message", signal to the application that requested
commit or rollback. This is not defined.
All of these things are deducible, but it would be clearer and more
precise to spell them out. There may be a case for renaming some of
these events for greater clarity, but I have concentrated on writing
down the meaning as I understand it.
ws-at
spec
editorial
Alastair Green
Alastair Green
Refer to the original email
for details on the proposal.
The issue was closed with no action during
July 27, 2006 TC call.
i036
i046
i054
WS-AT: Definition of expiry inadequate/at odds with state table
WS-AT specification: Section 3, "Atomic Transaction Context", ll. 120-123,
as amended by resolution of issue 023.
Resolution of issue 023 blurs meaning of expiry for the coordinator and
participant. Point of no return misdefined (does not accord with the
state table). Fact that this attribute has no real meaning for
completion protocol is not stated.
Issue Details:
The new text agreed in resolution of 023 at the March 2006 F2F reads:
"A coordination context may have an Expires attribute. This attribute
specifies the period, measured from the point in time at which the
context was first received, after which a transaction may be terminated
solely due to its length of operation. From that point forward, the
transaction manager may elect to unilaterally roll back the transaction,
so long as it has not transmitted a Commit or Prepared notification."
But:
1) the transaction manager (better, the coordinator of the transaction)
does not receive the context, it generates it. In other words, the
transaction manager will start counting down to abortion of the
transaction at some point no later than the time it first emits a
context.
2) The entity that does receive the context is any registering service
that chooses to hook a 2PC participant into the transaction. Such a
recipient must never set a local expiry deadline for its registered
participants which is earlier than the absolute time of receipt of the
application message containing the context, plus the expiry. (Unless it
has some way of deducing network latency.) The existence of such an
actor is not made clear.
3) The definition of the "point of no return" is wrong (both for the
coordinator and the participant). The point of no return, as per the
state tables, is not the point of emission of the message, but the point
of deciding to attempt a log write.
4) The expiry interval is effectively meaningless for the Completion
protocol. Having been set (in the first place) by the initiator of the
transaction, it can reasonably be assumed that the terminator will be
directly aware of the interval concerned. In any event, what does it
mean for a completion participant to "time out"? Its only effect could
be to redeliver a rollback, which would be both duplicative and complex
to specify.
The expiry must be defined twice: in its effect on the coordinator, and
in its effect on registered participants. The definition of its meaning
should be restricted to 2PC participants.
The definition of the point of no return should be changed. Strictly
speaking it could be omitted altogether: the internal event of decision
to go prepared or to commit creates a state transition which precludes a
subsquent rollback decision being attempted). However, that seems
excessively opaque. Preferable to cross-refer the states.
ws-at
spec
design
Alastair Green
Alastair Green
Change the quoted section to read:
"A coordination context may have an Expires attribute. This attribute
specifies the period, measured from the point in time at which the
context was first published in a CreateCoordinationContextResponse
message, before whose passage a transaction will not be terminated by
the coordinator solely due to its length of operation. After that period
has elapsed, the coordinator may elect to unilaterally roll back the
transaction, so long as it has not yet made a decision to record commit
(i.e. entered the state PreparedSuccess). This attribute can be used by
any recipient of a coordination context which registers a 2PC
participant to calculate the point in time at which the participant can
safely decide to rollback because of delay in receiving a Prepare
message. A 2PC participant which has not yet decided to record prepare
(i.e. entered the state Prepared) may rollback after the Expires
interval has elapsed since the point at which the registrar of that
participant received the coordination context message."
If you want to avoid duplication of the state table, this could be
abbreviated to:
"A coordination context may have an Expires attribute. This attribute
specifies the period, measured from the point in time at which the
context was first published in a CreateCoordinationContextResponse
message, before whose passage a transaction will not be terminated by
the coordinator solely due to its length of operation. After that period
has elapsed, the coordinator may elect to unilaterally attempt to roll
back the transaction. This attribute can be used by any recipient of a
coordination context which registers a 2PC participant to calculate the
point in time at which the participant can safely decide to rollback
because of delay in receiving a Prepare message. A 2PC participant may
attempt to rollback after the Expires interval has elapsed since the
point at which the registrar of that participant received the
coordination context message."
See
email.
Proposal 2 was accepted during
July 13, 2006 TC call.
Editors to check if the "may"s in the proposed text should be upper case or lower case.
i023
WS-AT: Only root coordinators can accept Completion protocol registrations
WS-AT specification: Section 4.2, "Completion Protocol", l. 146.
Only root coordinators can accept registrations for Completion protocol.
Others must fault.
ws-at
spec
design
Alastair Green
Alastair Green
Add new para at l. 151 as follows:
"An initiator MUST NOT target a registration for the Completion Protocol
at a Subordinate Coordinator. The Registration Service for a Subordinate
Coordinator must respond to an attempt to register for this coordination
protocol with the WS-Coordination fault CannotRegisterParticipant."
WS-AT wd-08 version, insert before line 161:
"A Completion protocol coordinator must be the root coordinator of an atomic
transaction. The registration service for a subordinate coordinator MUST respond
to an attempt to register for this coordination protocol with the WS-Coordination fault
Cannot Register Participant."
proposal 2 was accepted during
August 10, 2006 TC call.
WS-AT: Clarify late registration of participants in state tables
WS-AT specification: Section 10, "State Tables", Coordinator View table,
between ll. 503 and 504.
Late registration of 2PC participants not correctly stated in CV state
table.
Issue Details:
WS-AT Coordinator View state table, row (Inbound Event) Register, column
(State) Preparing, reads as follows:
Durable: Invalid State --> Aborting
Volatile: Send RegisterResponse --> Active
The transaction moves into the Preparing state as a result of a User
Commit internal event, aka an application instruction to the coordinator
to initiate 2PC processsing.
For 2PC to work correctly it is necessary to freeze the pool of voters
before the polls close. In theory this need not happen till the very
last vote of the current pool has been received (the list can be
extended while being processed). However, WS-AT in common with other
atomic TMs and protocols (and with other types of election) chooses to
simplify by freezing the pool when the polls open, i.e. when the
application chooses to request commitment, at the beginning of the
prepare (voting) phase. The argument behind this is that the terminating
(demarcating) application must have figured out (by some application
protocol) that all the expected participating services are involved
(usually termed checking), otherwise it wouldn't have requested
commitment.
With an atomic-only commitment protocol like AT this is reasonable. We
should therefore never see an unexpected late registration of a durable
participant, because the application should not have requested commit if
all services are not yet involved. This is the current situation for
late durable registrations.
However, by this logic we should also expect that a volatile 2PC
participant should never be registered late (unknown to the terminating
application), once prepare phase processing has commenced. The vote of a
volatile participant is good enough to veto the transaction: why should
the number of volatile participants be considered any less relevant than
the number of durable participants?
There seems no reason to differentiate the reaction of the coordinator
to late registration of Volatile and Durable participants.
ws-at
spec
design
Alastair Green
Alastair Green
Amend WS-AT Coordinator View state table, row (Inbound Event) Register,
column (State) Preparing, to read as follows:
Invalid State --> Aborting
This issue has been dropped; the submitter has withdrawn the issue. Refer to the
minutes of April 20, 2006
TC conference call.
i037
WS-AT: Replay message generates protocol errors
WS-AT specification: Coordinator View State Table, after l. 503.
Replay reactions defined in current CV state table will cause
unnecessary transaction aborts.
Issue Details:
The cells in row (Inbound Messages) Replay, columns (States) Active and
Preparing read:
Active: Send Rollback --> Aborting
Preparing: Send Rollback --> Aborting
Replay message means: "play it again Sam", not "demolish the piano".
Case A. If the last thing they sent was Prepared, and it got through
(we're Preparing and we've recorded their vote), and they've recovered,
and they're waiting for a Commit or a Rollback, then we need to Ignore
the Replay (just like if they send it when we've done our own
housekeeping, and moved to Prepared Success).
Case B. If the message didn't get through, and we've processed User
Commit then we could be in the Preparing state, but have no record of
their vote. In that case we'd have to replay Prepare to indicate to
them, send us your vote again.
Case C. If the last thing we received was Register, and we haven't
processed User Commit, then we're still Active and they won't have
logged. Replay won't happen on crash recovery (no log record to recover
off), but it could be used to say to the coordinator "Are you still
there? Should I crap out?" (i.e., because of impatience). We can't stop
them using Replay in that fashion. Our only sensible response would have
to be: silence (we don't have a blank ack to a ping), i.e. to Ignore.
There is no harm in them doing this, even though it is pointless. You
could argue that this should be a N/A but that seems heavy-handed.
ws-at
spec
design
Alastair Green
Alastair Green
As the state tables do not differentiate between Preparing/no vote
recorded and Preparing/vote recorded, it seems easiest to always resend
Prepare in the Preparing state. Therefore:
Replace the current text in the cells in row (Inbound Messages) Replay,
columns (States) Active and Preparing with:
Active: Ignore --> Active
Preparing: Resend Prepare --> Preparing
Remove Replay message.
Proposal 2 was accepted during
May 31 - June 01, 2006 (Dublin) F2F meeting.
i046
i053
WS-AT: Eliminate Replay message
WS-AT specification: Section 3.4, "Two-Phase Commit Protocol", ll. 221-223
Coordinator View State Table, after l. 503.
Replay is a pointless message. Replay the last message sent, if any.
Issue Details:
Replay is a universal synonym for "resend the last message sent, if
any". Better and simpler to remove it, and rest on the rule that a
coordinator and a participant can both, if feeling lonely, resend the
last message sent, if any. (This rule is stated in the proposed
resolution to related issue: "WS-AT: Comms Times Out internal event
should be removed from state tables", and is needed in any event.)
ws-at
spec
design
Alastair Green
Alastair Green
a) Remove lines 221-223.
b) Remove the row labelled (Inbound Messages) Replay in the Coordinator
View state table.
The proposed resolution was accepted during
May 31 - June 01, 2006 (Dublin) F2F meeting.
i052
i054
WS-AT: Comms Times Out internal event should be removed from state tables
WS-AT specification: Coordinator View State Table, after l. 503
Participant View State Table, after l. 510.
Comms Times Out internal event and its concomitant action (do it again)
is universally applicable to all send/resend situations. These are not
(cannot feasibly) be called out as separate states. This vitiates the
purpose of the event in the tables.
ws-at
spec
design
Alastair Green
Alastair Green
a) Remove the rows labelled "Comms Times Out" in both CV and PV state
tables.
b) Add a note (either in Section 9 or in Section 10) saying:
"Note that any attempt to send a notification message may result in a
communications failure. It is always legitimate to attempt a retry in
such circumstances. It is also legitimate to retry a send if an expected
response has not been received in a timely fashion. The definition of
"timely" and the retry strategy used are implementation concerns.
However, complete failure to retry in all circumstances will almost
certainly lead to hung transactions."
The issue was closed with no action during
July 27, 2006 TC call.
i048
WS-AT: User Commit and User Rollback should not return Aborted in None state
WS-AT specification: Section 10, "State Tables", Coordinator View table,
between ll. 503 and 504.
If transaction in state None, and event User Commit or User Rollback
arises, then action is to Return Aborted (aka tell application that the
transaction was aborted). In fact transaction may just have been
forgotten, and may either have been aborted or committed. Return value
possibly contradicts reality, therefore.
Issue Details:
All Forgotten event arises when all participants have done action
Forget. If this happens when transaction as a whole is in Aborting or
Committting state then the state flips to None.
User Commit or User Rollback event may then arise. (Replay of Completion
protocol Commit, API replay). Response of coordinator state machine is
to process action "Return Aborted". See WS-AT Coordinator View state
table, rows (Internal Events) User Commit and User Rollback, which read
as follows:
User Commit/None: Return Aborted --> None
User Rollback/None: Return Aborted --> None
Clearly this information may be false. It is possible that we got to
None via Committing, or via Aborting. The result was either Committed or
Aborted. Naturally, if we have gone "All Forgotten" we have literally
... forgotten which it was.
ws-at
spec
design
Alastair Green
Alastair Green
a) Amend state table cells referred to in problem description to read:
User Commit/None: Return Unknown --> None
User Rollback/None: Return Unknown --> None
b) Define new fault for use by Completion protocol, called
UnknownOutcome, which can be returned if this happens.
See
document.
Proposal 2 was accepted during
May 31 - June 01, 2006 (Dublin) F2F meeting.
i056
WS-AT: User Commit and User Rollback row of CV state table contradicts
resolution of 010
WS-AT specification: Section 10, "State Tables", Coordinator View table,
between ll. 503 and 504.
Issue 010 proposed that replays of Completion protocol messages should
be permitted, to allow initiators to discover state of transaction after
initial termination request had been made. This was rejected almost
unanimously. However, state tables permit replay.
Issue Details:
WS-AT Coordinator View state table, row (Internal Events) User Commit
reads as follows:
None: Return Aborted --> None
Active: Send Prepare --> Preparing
Preparing: Ignore --> Preparing
Prepared: N/A
Prepared Success: Ignore --> Prepared Success
Committing: Return Committed --> Committing
Aborting: Return Aborted --> Aborted
Similar things happen with row User Rollback.
Reception of User Commit engendered by Completion protocol Commit
message may occur twice as a result of impatience, lost messages,
transport bounce.
State table handles this happily, replaying known outcomes (e.g if event
arises when Aborting, Commit message will be responded to with
Committed, even though message has already been sent on event Write
Done.
I like that, but the TC doesn't, by 16 to 1.
Note that this issue is very tightly related to "WS-AT: User Commit and
User Rollback should not return Aborted in None state". If all become
forgotten (every participant goes aborted or committed) then the state
flips to None. Speed at which that happens cannot be dictated
(forgetting is a non-critical path activity, that may be deferred to
some form of garbage collection or deferred for ever in a given
implementation). Replays are therefore always possible in principle.
ws-at
spec
design
Alastair Green
Alastair Green
EITHER:
Make text of completion protocol, definition of notification types etc
conform with state table and recognize that duplicate Completion
protocol Commits and Rollbacks cannot easily or sensibly be stopped (See
Register/RegisterResponse discussion).
OR:
Ban duplicate responses in the state tables by faulting duplicate
events.
See
email.
Proposal 2 was accepted during
July 13, 2006 TC call.
i055
WS-AT: conceptual nature of protocol diagrams needs to be underlined
WS-AT specification: l. 191, Section 4.3, "Two-Phase Commit Protocol", diagram.
Coordinator and Participant View State Tables, l. 503 onwards.
The state tables show (in model and in detail) a substantially different
view form the abstract protocol diagrams. Need to state that fact.
Issue Details:
The conceptual character of the protocol diagrams is not clear enough.
The predominance or override of the state tables needs to be stated
explicitly. The diagrams do not have the same states or state
transitions as the state tables. They are good simplifications which
situate readers at a first pass, but no more than that. Similarly the
text that accompanies them.
ws-at
spec
editorial
Alastair Green
Alastair Green
Replace the sentence on l. 191 with the following:
"The diagram and text in this section give a simplified, conceptual
non-normative overview of the way in which the 2PC protocol works. The
state tables in Section 10, "State Tables" are detailed and normative."
[This resolution requires refinement if Replay is retained, as the only
statement about what Replay means and when it might be sent is in this
section.]
The following text refers to CD 01 version of the AT specification.
Line 152 and 191 currently state: "The diagram below illustrates the protocol
abstractly.". Append the sentence "Refer to the section State Tables for a
detailed description of this protocol." to the text at both lines.
Editors: Please add a hyperlink to the phrase "State Tables" in the newly
added text.
Proposal 2 was accepted during
July 27, 2006 TC call.
definition of Referencing Specification
Text within WS-C refers to Referencing Specification. We have no formal definition
of that.
ws-coord
spec
editorial
Mark Little
Mark Little
One or more other specifications, such as (but not limited to) WS-AtomicTransaction may
reference the WS-Coordination specification. Referencing Specifications are generally
used to construct concrete protocols based on WS-Coordination. The usage of optional
items in WS-Coordination, or those protocol aspects where terms such as MAY or SHOULD
are used, may be further restricted by the requirements of a Referencing Specification.
For the purpose of this document, the term Referencing Specification covers both formal
specifications and more general applications that use WS-Coordination.
Use the phrase "When used by a specification that references this specification,
these faults are targeted ...", instead of "Referencing Specification".
Proposal 2 was accepted during
May 31 - June 01, 2006 (Dublin) F2F meeting.
Protocol event indications are not ws-addressing faults
With the resolution of Issue 30, the specifications (coord, at, ba) have two kinds of
indications:
Faults (definined in ws coord) which map to ws-addressing fault model.
"notifications" (from ws at, ba) which do not map to ws addressing faults,
and which are treated as first class "requests" from ws addressing
perspective.
Mapping the second kind of indication to a soap fault, but not a ws
addressing fault, will inevitably cause confustion for implementers of this spec.
ws-coord
ws-at
ws-ba
spec
design
Tom Rutt
Tom Rutt
Instead of mapping the "notifications" to soap fault syntax, define a new schema type
{ProtocolEventIndication) which conveys the proper syntax for the contents of these
protocol notifications.
Have each individual protocolEventIndication be mapped to this new syntax,
as a proper ws addressing request message.
This issue was closed with no action during
May 31 - June 01, 2006 (Dublin) F2F meeting.
WS-AT: Reference to fault-handling rules
Section 6, ll.333 - 335.
Text relating to resolution of Issue 030 does not make sense in this context.
Issue Details:
The phrase "...protocol fault handling rules defined for that protocol"
does not makes sense when the protocol concerned is this one, WS-AT.
ws-at
spec
editorial
Alastair Green
Alastair Green
Amend text to say: '...protocol fault handling rules defined in Section 9
"Use of WS-Addressing Headers" of this specification.'
Closed with no change during
August 10, 2006 TC call.
WS-AT: Spontaneous preparation/resignation/abortion of participant
Section 10, "State Tables", Coordinator View table, between ll. 503 and 504,
and Participant View table following.
PV state table appears to prohibit rollback decision in Active state,
tho' CV would accept message if sent. Same applies to ReadOnly.
Issue Details:
PV state table Row Rollback Decision, State Active, N/A -- means cannot occur.
This implies that participant can never make decision to abort until it has received
Prepare. But Expires Times Out generates spontaneous abort: it is safe against the
CV table. Not clear why P cannot abort prior to receiving Prepare.
Similarly: PV state table All Forgotten, State Active, N/A -- means cannot
occur. This implies that participant cannot go read-only until it has received
Prepare.
CV state table Row Aborted, State Active, action: Forget; state Aborting.
This cell cannot be entered if Prepare has already been sent (wd be in state
Preparing). But PV can only send if expires times out.
CV state table Read Only, State Active, action: Forget; state Active.
This cell cannot be entered: if Prepare has already been sent C would be in state
Preparing. PV cannot send Read Only in Active state.
Therefore, CV in Active state is able to accept messages that PV can never
send (Read Only) or that it can only send in a very restricted circumstance.
From the standpoint of correctness and speed of transaction resolution,
there is no argument against allowing Participants to spontaneously prepare
(q.v. Gray/Lamport, "Paxos Commit"), vote rollback, or go read-only (i.e. to make
these decisions prior to receiving Prepare).
ws-at
spec
design
Alastair Green
Alastair Green
Alter state tables to permit spontaneous preparation, abortion and resignation,
as per attached Word document.
If this is not accepted, the un-enterable cell (Read Only/Active) in CV needs
to be set to N/A.
See document.
See
email
.
Proposal 2 was accepted during
August 24, 2006 TC call.
WS-AT: Remove Prepared column from CV state table.
Section 10, "State Tables", Coordinator View table, between ll. 503 and 504.
Prepared column in CV state table is redundant.
Issue Details:
Prepared states are never entered (are all N/A) in CV state table.
ws-at
spec
editorial
Alastair Green
Alastair Green
Remove Prepared column from CV state table.
Proposal was accepted during
July 13, 2006 TC call.
WS-AT: Volatile 2PC logging behaviours unclear
Section 3.4, "Two-Phase Commit Protocol", ll. 221-223 Coordinator View State Table,
after l. 503 Participant View State Table, thereafter.
Coordinator and Participant logging behaviour for Volatile participants
is not defined.
Issue Details:
The following sentence comes from the original statement of Issue 039
(authored by Peter Furniss):
'For volatile participants however, it is legitimate for the coordinator
to delete its commit log record after receiving Committed from all
durable participants, without waiting for any response from volatile
participants. If there is a crash at this point (or just some lost
messages), Prepared or Replay can be received from a volatile
participant and find the coordinator in state "None".'
This is, I believe, an understanding derived from discussion with one of
the input authors at the Raleigh interop event in January 2005.
This is one implementation of the spec statement (l. 180): "A volatile
recipient is not guaranteed to receive a notification of the
transaction's outcome."
That statement can also be fulfilled by a volatile participant not
logging its prepared state. This will prevent it always receiving a
known outcome (i.e. there will be no crash recovery of the Participant).
The interoperable behaviour in these two cases is different.
Behaviour in the case where the PV does not log, and the coordinator
deletes its log after receiving all durable Committeds, is different
again.
The state tables do not capture the expected behaviour of either the
coordinator, or the Participant, with respect to logging.
ws-at
spec
editorial
Alastair Green
Alastair Green
Discuss and clarify the design intent, and ensure that it is captured in
the spec, preferably in the state tables.
Coordination: Use of anonymous in request/response messages
Section 7, line.619.
Spec unnecessarily restricts anonymous ReplyTo in request response
messages.
Issue Details:
Banning use of anonymous ReplyTo will cause many implementations of
WS-Addressing to use a second http connection to communicate the reply or fault.
In the case of http bindings, use of anonymous ReplyTo will allow the response to
be returned in the http response entity.
ws-coord
spec
design
Bob Freund
Bob Freund
Delete line 619.
The proposed resolution was accepted during
May 31 - June 01, 2006 (Dublin) F2F meeting.
The line 619 "Request messages MUST contain a [reply endpoint] property whose [address]
property is not set to 'http://www.w3.org/2005/08/addressing/anonymous' or
'http://www.w3.org/2005/08/addressing/none'." has been removed.
WS-AT: ATAlwaysCapability redundant
Section 5.2, ll.268 - 275.
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.
ws-at
spec
design
Alastair Green
Alastair Green
Remove all references to the ATAlwaysCapability policy assertion type from the WS-AT
spec.
Closed with no action during
August 24, 2006 TC call.
i045
Inconsistency on WS-BA use of "Fault"s
WS-AT (cd02) has the following statement on lines - 488-590
"Fault messages MUST include a wsa:RelatesTo header, specifying the MessageID
from the Notification message that generated the fault condition."
However WS-BA does not include this text.
Also, WS-BA includes the following text (lines 406-410):
"A notification message is a terminal message when it indicates the end
of a coordinator/participant relationship. Closed, Compensated, Canceled, Exited
and Faulted are terminal messages as are the protocol faults defined in this
specification and in [WSCOOR]."
"A notification message is a non-terminal message when it does not
indicate the end of a coordinator/participant relationship. Complete, Completed,
Close, Compensate, Cancel, Exit and Fault are non-terminal messages."
There are no new protocol faults define in WS BA, so the meaning of the
text "as are the protocol faults defined in this specification", is
confusing.
The protocol faults are all mapped onto the soap fault syntax in
ws-coord and ws-at, and there are no "protocol faults" defined
in ws-ba.
However, there is a wsdl one-way operation defined in WS-BA called
"Fault". This is not treated as a "protocol fault" defined
in this specification, and is not mapped onto the soap fault syntax.
This is confusing, and needs to be explained suffiently for
comprehension by a new reader.
ws-ba
spec
editorial
Tom Rutt
Tom Rutt
a) Either:
Add the missing text which is in WS-AT into WS-BA:
"Fault messages MUST include a wsa:RelatesTo header, specifying the MessageID
from the Notification message that generated the fault condition."
or
add a clarification to justify why this requirement is not included
in WS-BA.
b) Either: change the name of the "Fault" wsdl operation in WS-BA
or Add clarificaiton text on why the "Fault" operation in WS-BA is
different than a "protocol fault" notification.
Fault is a protocol message. To avoid confusion, rename Fault to Fail and Faulted to
Failed across all occurences in the specification, including the diagrams.
Further,
Change line 407 "Closed, Compensated, Canceled, Exited and Faulted are terminal
messages as are the protocol faults defined in this specification and in [WSCOOR]"
to "Closed, Compensated, Canceled, Exited, NotCompleted, and Faulted are terminal
messages as are the protocol faults defined in [WSCOOR]".
Proposal 2 was accepted during the
August 29-31, 2006 F2F meeting.
WS-BA inconsistency between schema and text
The description of the Fault message in the CD-02 release states that
the message carries a QName indicating the cause of the fault (lines
198/199).
The message in the associated schema does not match this description.
The ExceptionType defined in the schema contains an ExceptionIdentifier
element declared to be a string.
The relevant declarations in the schema are quoted in the
email
.
ws-ba
ws-ba-schema
schema
editorial
Kevin Conner
Kevin Conner
Change schema definition such that the ExceptionIdentifier element is a Qname instead
of a string.
The proposed resolution was accepted during the
August 29-31, 2006 F2F meeting.
WS-BA: Distinguish early and late fault - add Refuse message
The semantics of Fault and Exit are unclear, and partly overlapping. If the messages
are considered in terms of what they mean to the relationship between the parties
rather than the internal behaviour, there are three distinct semantics.
There should be three messages.
Issue Details
The present definition of the Fault message is in terms of an internal event
("the participant has failed"); it would be better to define it in terms of the
effect on the application contract. However, as it is currently, the Fault message
means both "I have not done any of the work you asked me" and "I have failed to
undo the work I was told to compensate", depending on when it was sent.
There is also a related ambiguity in the use of the Exit message – the text suggests
that this could be used to mean both "The application work you asked me to do has no
effect" (perhaps because it has already been done) and "I have not done any of the
work you asked me to" – which latter is also one of the meanings of Faulted.
Application messages would need to be sent to remove the ambiguity.
Combining those two, there in fact three semantics : no work, failed work,
failed compensation. The semantics should be distinguished, rather than rely on
stage of the interaction or application messages.
ws-ba
spec
design
Peter Furniss
Peter Furniss
Create a new message, Refuse, for a participants rejection of the work, and define
the semantics of all three:
Exit = The application work you asked me to do has no effect : Close, Cancel
and Compensate would all leave our business relationship in the same state.
Refuse = I have not done any of the work you asked me to. (a spontaneous
statement of unwillingness to be part of this activity.)
Faulted = I have failed to reach the requested final state
Following the pattern for other messages, Refuse would have a Refused
reply.
Add two new messages CannotComplete and NotCompleted:
CannotComplete
Upon receipt of this notification, the coordinator knows that the
participant has determined that it cannot successfully complete all processing
related to the protocol instance. Any work performed by the participant related
to the protocol instance was successfully canceled.
For the next protocol message, the coordinator should send a NotCompleted
notification. After sending the CannotComplete notification, a
participant MUST not participate in any further work under that activity.
This message may be sent by a participant only from the Active or Completing
states.
NotCompleted
After transmitting this notification, the coordinator may forget about the
participant. Upon receipt of this notification, the participant knows that the
coordinator is aware that the participant cannot complete all processing related
to the protocol instance, and that the participant will no longer participate in
the activity; the participant may forget the activity.
Proposal 2 was accepted during the
August 29-31, 2006 F2F meeting.
WS-BA: Allow Compensate in Active state
Refer to state diagrams and tables.
A coordinator (or its application) that wishes to just abort the work
of an activity, regardless of the state of the participant, will have to send
Cancel, and then follow with Compensate if the Cancel crosses with Complete. As a
protocol message, the Compensate could be sent immediately, being treated by
the participant as it would Cancel if the participant is still active.
Issue Details
The present spec resolves a cancel/completed collision in favour of the
completed, and if the coordinator and its application then determine the
participant's work should really be undone, a subsequent compensate is sent.
It is possible to imagine use-cases where this pattern is important in an
application (for example, if the compensation will involve some penalty charges,
which pre-completion cancellation would not). However, in many other cases the
intent of the coordinator and its application will be merely to stop and undo
if necessary without delay or reconsideration. This could be accommodated
without losing the flexibility of the current behaviour if Compensate were
allowed to be sent from the Active state, and the receipt by an uncompleted
Participant were treated as equivalent to Cancel.
ws-ba
spec
design
Peter Furniss
Peter Furniss
Allow Compensate from Active state, treated as equivalent to Cancel if received in
Active state.
Closed with no action, during the
August 29-31, 2006 F2F meeting.
WS-BA: Provide participant identification information for application use
The WS-C/WS-BA protocol combination must carry participant identification
information to enable two facilities, without which WS-BA is unworkable for
intended use cases:
a) Identification of registered and completed Participants, for "checking"
purposes
b) Identification of Participants for selective cancellation/confirmation
when using mixed outcome.
A [ParticipantIdentifier] element is required in the WS-C Register message
whose value is Participant-defined and which allows the application driving the
Coordinator to identify participants from an application standpoint. Typically,
this identifier will be returned in an application response, and will also be
present in the Register message. This allows the application to correlate
application responses (e.g. quote details) and Participants.
This feature is required, to take one concrete example, by applications
using a WS-BPEL or XLANG-like API, where inner scopes may be compensated
selectively, and each such scope is named: compensate scope="foo".
The means by which the identifier requirement was avoided for WS-AT
(leading to it not being made a base part of WS-C) do not apply to WS-BA, which
therefore must provide elements to carry the information. It would not be
appropriate to force all WS-BA-using applications to specify application-specific
extensions to WS-C just to make WS-BA usable.
ws-ba
spec
design
Peter Furniss
Peter Furniss
Define new element [ParticipantIdentifier] : xs:any (0..1) as an extension field in
the Register message, whose use is mandatory when registering with a WS-BA
Coordinator.
This element's contents are defined by the agent that registers the Participant,
and their meaning for the purposes of correlation with application messages that
travel between the service and the consuming application is defined by agreement
of those two parties, and is not a matter of further concern for the WS-BA
specification. (though it would be for anyone specifying a WS-BA api or similar)
(Note that this definition is silent on the question of whether the value is
application-generated or middleware-generated—this is an implementation issue.)
Closed with no action, during the
August 29-31, 2006 F2F meeting.
WS-BA: Remove "presumed nothing" requirement
WS-BA specification, Section and PDF line number: section 1 , line 35.
Reliable recording of state transitions should not be required.
Issue Details
The statement "All state transitions are reliably recorded, including
application state and coordination metadata" should not be required. Making
it a requirement imposes unnecessary overhead and is unnecessarily constraining
on implementations.
WS-BA can perform all of its design goals using presumed abort - i.e. only
reliably recording at Completion time (for a participant), at Close time (for a
coordinator). Implementation can conform with state tables and interwork
seemlessly using presumed abort without observing above requirement.
ws-ba
spec
design
Peter Furniss
Peter Furniss
Delete line 35.
Introduction section (line 35), modify as follows:
"Appropriate state transitions are reliably recorded, including application
state and coordination metadata."
Consequent to issue 92 resolution, close this issue with no action. Revert the previously accepted proposal and undo
the changes.
Proposal 3 was accepted during the
October 05, 2006 TC meeting.
WS-BA: Definition of Compensated
WS-BA specification, Section and PDF line number: section 3.1, lines 201-202.
Definiton of Compensated in 3.1 is wrong.
Issue Details
The definition of Compensated in 3.1 is "Upon receipt of this notification,
the coordinator knows that the participant has recorded a compensation request
for a protocol."
The other *-ed messages refer to the completion of the processing implied.
Since Fault will signal the unsuccessful application of Compensate, the definition,
implying Compensated could be sent, then Fault, is bugged. (It is also
over-specific on implementation behaviour). Compensated should be sent when
the compensation work has been done, not just thought about.
ws-ba
spec
editorial
Peter Furniss
Peter Furniss
Change to send Compensated when the compensation has been processed,
not recorded.
Issue 073 "Message definitions" will affect the exact text.
Issue 85 resolution addresses this. Closed with no action during the
August 29-31, 2006 F2F meeting.
i073
WS-BA: Message definitions
The message definitions in 3.1 should be defined from the perspective of the
sender, not the receiver.
Issue Details
The message definitions in 3.1 are given from the perspective of the
receiver. Although this is appropriate in terms of describing a (one-way) WSDL
interface, it really the wrong way round to describe the semantics of the messages.
The meaning of a message is better understood in terms of what it says about the
sender - who has typically just undergone a state change, rather than what can be
inferred by the receiver.
Some of the messages are also defined in the glossary - however, cancel
and close are there defined as actions, and the others as messages in terms of
the sender (as suggested for 3.1). Not all messages/actions are covered in the
glossary.
ws-ba
spec
editorial
Peter Furniss
Peter Furniss
Standardize the description of the messages, and in 3.1 express this primarily from
the perspective of the sender.
Issue 85 resolution addresses this. Closed with no action during the
August 29-31, 2006 F2F meeting.
i072
WS-BA: Permit Fault as response to Close
At present it is not possible to send Fault in response to Close. (It is
possible to send Fault in response to Compensate.) Model requirements
such as "quote-to-order" and tentative operations cannot be supported
without ability to fault closure.
Issue Details:
There are many examples of scenarios where completion of an activity
involves additional application work in a participant, just as
cancellation requires compensatory work. The model section of the spec
refers to the following iconic case:
" Allow a business application to select which child tasks are included
in the overall outcome processing. For example, a business application
might solicit an estimate from a number of suppliers and choose a quote
or bid based on lowest-cost."
A natural application of WS-BA in this scenario is:
Buy-side sends Request For Quote (RFQ) with BA context to sell-side.
Sell-side sends Completed ("prepared") to coordinator, and responds with
Quote to buy-side. Quote is "firm": it will be honoured if quote
becomes order.
Buy-side likes quote and wants to execute order, so sends Close (no need
to send application Order message).
As with compensations, the "react to Close" application operation
effectively invoked by sending Close is capable of failing (business
exceptions will be raised). The most likely reason here is that the
quote has timed-out.
A failure of this kind should be signalled in response to the Close
message.
Any scenario where participants move through application states
"Pending" to "Final" requires this feature.
ws-ba
spec
design
Alastair Green
Alastair Green
Please see the
documentuploaded in November for the changes required for Participant
completion:
The version of the state table in the uploaded document has the old
orientation of states and messages, but the point still stands.
Closed with no action during the
August 29-31, 2006 F2F meeting.
WS-BA: Sub-coordination undefined
WS-BA specification, Section 2, "Using WS-Coordination".
Meaning of creating a new context against an existing, current context
is not described or defined.
Issue Details:
WS-C places responsibilty on referencing specs to define meaning of use
of current context in CreateCoordinationContext. BA is currently silent
on this.
ws-ba
spec
editorial
Alastair Green
Alastair Green
Define meaning of interposition for atomic and mixed outcomes.
See email.
Proposal 2 was accepted during the
August 29-31, 2006 F2F meeting.
WS-BA: Long-lived indication message
Long-lived activities are susceptible to message thrashing (retries that
are soliciting answers which will not come for a long time). It is
useful for a party to be able to indicate that it will not send a
message to its counterpart for some period of time.
Issue Details:
WS-Addressing pre-defined faults cannot be assumed to be deliverable.
The WS-Addressing fault that enables indication of postponed response is
a reply, and cannot be sent spontaneously.
A new message is needed at the WS-BA level, to permit the semantic "Do
not expect anything further from me for at least n seconds" to be
communicated. This message is a legitimate response to any protocol
message that will induce a conversational response.
ws-ba
spec
design
Alastair Green
Alastair Green
Create a new WS-BA non-terminal message NextMessageDelay with a property
AnticipatedDelay, value of 0 equals indefinite, positive integer value
equals seconds to anticipated transmission of next "real" message. This
message is a hint, the anticipated delay may be foreshortened or
exceeded in practice at the sender's will. This message may be sent by
either the Participant or Coordinator, and may be sent at any time, and
is therefore always a legitimate response to any notification that
expects a reply.
Closed with no action during the
August 29-31, 2006 F2F meeting.
WS-AT: Make completion protocol request-reply, permitting anon
Section 4.2 "Completion Protocol"; Section 9, "Use of WS-Addressing
Headers".
A client that initiates a transaction using WS-Coordination
CreateCoordinationContext can do so using one-ways, or the anonymous
back-channel. The latter facility was added to permit "thin clients"
(ones that cannot listen for inbound
messages) to initiate an activity. Such a client is likely to have
responsibility for terminating the transaction, and it would therefore
be appropriate to make the completion protocol have the same
characteristics.
Issue Details:
An interoperable client program is very likely to wish to conduct the
following sequence of actions:
a) send CreateCoordinationContext to the Activation Service of a
Coordination Service.
b) send Register for the AT Completion Protocol to the Registration
Service of a Coordination Service.
c) send AT Completion Protocol Commit or Rollback to the Coordinator for
the activity within the Coordination Service.
It was accepted at the Dublin F2F that activities a) and b) should be
allowed to use the anonymous back channel for the CCCResponse and
RResponse replies, allowing the client program to be a thin client, i.e.
one that is unable to listen for unsolicited inbound messages.
It seems illogical to prevent a thin client conducting all three of the
actions in this common sequence. The inability to do c) is likely to
vitiate the purpose of the accepted change allowing such a client to
enact a) and b).
ws-at
spec
design
Alastair Green
Alastair Green
Specify that WS-AT Completion Protocol has the same addressing
characteristics as WS-Coordination, i.e. that the [reply endpoint]
property is used to indicate the target of the expected response, and
that that endpoint reference is permitted to have the WS-A anonymous URI
as its URI.
Closed with no change during
August 10, 2006 TC call.
WS-AT: state table event to model forced abort
WS-AT specification, Section 10, 2PC State tables.
There is no internal event that models the issue of Rollback to a Participant
when another Participant delivers Aborted, thus causing the transaction to
abort.
Issue Details
A coordinator on receiving Aborted from one Participant when in Active
or Preparing should initiate rollback to all participants. But the state table
just causes that one CV to initiate action Forget and transit to Aborting. The
only internal event in the CV table which would send Rollback to the other
participants at that point is Expires times out. (this used not be the case,
since User Rollback did to). The Participant table does have an action
"Initiate Rollback" which is what we need.
ws-at
spec
editorial
Peter Furniss
Peter Furniss
A) Add an internal event to CV table "Initiate Rollback", and add this as an
action in the Aborted/Active and Aborted/Preparing cells.
The internal event Initiate Rollback causes Send Rollback, Aborting in Active
and Preparing states, and is ignored in Aborting, can't happen in Committing.
(it is an interpretation rule that the actions and state transitions of a cell
complete before any initiated internal events occur - consequently the CV state
for the participant from which Aborted was received will be in Aborting when the
Initiate Rollback is actioned, and will not be sent Rollback, which aligns with
the state diagram.)
A stylistic change would then be to make Expires Times Out use Inititate Rollback,
rather than do the work for itself (since Expires Times out is "node-wide", it
could be left as it is, but it's generally neater to reuse something that is
already there, thus, additionally:
B) Change the Expires Times Out/Active and /Preparing to action Initiate Rollback,
staying in the same state.
See
email
.
Proposal 2 was accepted during
August 24, 2006 TC call.
i036
i048
WS-AT: state tables - "Forgetting" state
WS-AT specification, Section 10, 2PC CV State table.
Readonly leaves the coordinator in Active state which will cause it to send
protocol in reaction to internal events, contrary to the state diagram.
Issue Details
A coordinator receiving ReadOnly from a Participant should end the protocol
exchanges. However, the table currently has the state staying in Active
(The "Forget" action has to be understood as initiating forget, as the transitions
to None are distinct).
If User Commit or User Rollback are received while this state engine is still
in the Active state, the table says Prepare or Rollback would be sent.
ReadOnly needs to move the state to one where User Commit and User Rollback are
ignored.
A related problem is the two User actions are not permitted in Aborting - which
is correct since we would not allow duplicate User Rollback, but incorrect if
the transition to Aborting was caused by the spontaneous arrival of Aborted in
Active state.
ws-at
spec
editorial
Peter Furniss
Peter Furniss
Add a state "Forgetting", which is entered by all cells that have Forget as an action.
All incoming messages have action Ignore, except for Prepared, and User Commit,
User Rollback, Initiate Rollback, Expires Times Out are all ignored. All Forgotten
causes transition to None. receive Prepared/Forgetting has action (re)Send Rollback.
See
email
.
Proposal 2 was accepted during
August 24, 2006 TC call.
i036
i048
WS-AT: Forget on receiving Prepared in Aborting state
WS-AT specification, Section 10, 2PC CV State table.
It is inconsistent to initiate forgetting
on receiving Prepared in Aborting state.
Issue Details
It is inconsistent that the Prepared/Aborting cell initiate Forgets - a
participant that has already gone prepared should not be forgotten until a response
is received to the Rollback.
Although it is safe to forget about participants when rollback is sent
to them, it makes no sense to start forget only when Prepared is received.
ws-at
spec
editorial
Peter Furniss
Peter Furniss
Make the action in Prepared/Aborting to be just Resend Rollback, and keep the state in
Aborting.
The proposed resolution was accepted during
August 24, 2006 TC call.
i036
i048
WS-AT: state tables - Forget, Forgetting and Forgotten
WS-AT specification, Section 10, 2PC CV State table.
The existing coordinator view table has an "All Forgotten" internal event
that usually causes a transition to None.
Issue Details
Given the understanding that None means there is no longer any knowledge of
the participant, there are three rather different kinds of event that cause
transition to state None:
a) the knowledge of this particular participant has gone as a result of the
Forget action, but knowledge of other participants may remain.
b) the knowledge of all participants has gone as a result of Forget for all
of them.
c) the knowledge of this participant (and perhaps some others) has gone as
a result of a crash (when there was no persistent information for it).
The "All Forgotten" action is named for event b) (perhaps including knowledge
loss after crash), but given the purpose of the state table as referring
to an individual C:P relationship, it is actually its a) and c) that are
important. The volatile/durable distinction, and the possibility that a
readonly participant is forgotten early mean that the completion of forgetting
should relate to the single relationship, not the whole node.
By separating out the Forgetting state as proposed in issue
(new: WS-AT: Forgetting state needed), event a) will now only occur from state
Forgetting. It thus becomes unnecessary to consider what is happening to other
state machines (to do so would be to impose on implementation, anyway).
For event c), forgetting due to crash, requires different behaviour for
durable and volatile. The forgetting (= transition to None) can occur from any
state except where there is a commit log. By disallowing a transition to None from
the Committing state for a Durable partner it is possible to capture the
logging requirement without having to describe at all how it is met.
All Forgotten as event name is misleading, as it implies volatile and durable
behave the same, which is incorrect.
ws-at
spec
editorial
Peter Furniss
Peter Furniss
Replace the All Forgotten internal event by two events:
Internal event "Forget Completed", permitted only in state Forgetting,
where it causes a transition to None.
Internal event "Forgotten by accident" which models transitions to None from all
states except Committing, where it is disallowed for Durable, but transitions to
None for Volatile.
Note that "Forgotten by accident" is an event imposed on an implementation
rather than done on purpose.
See
email
.
Proposal 2 was accepted during
August 24, 2006 TC call.
i036
i048
WS-BA: Coordinator informed immediately of autonomous participant decision
A Participant in Completed state that has had to finalise the application
information should be permitted to send Closed or Compensated immediately,
rather than wait to respond to the instruction from the coordinator.
Issue Details
Services involved in loosely-coupled business activities, of the sort
targeted by WS-BA are commonly more-or-less autonomous. They are cooperating
in the Business Activity, but there are other drivers and requirements on their
behaviour. This applies whether the systems involved in the Business Activity
are from different organizations (where the autonomy is obvious) or are just
different applications in one organization (where legacy applications, for example,
often have other, primary goals, and the Business Activity is an integration).
Consequently, it must be expected that services will reserve the right to make
and apply their own decision to the work they are responsible for, despite their
promise to await the decision of the controlling application. This is analogous
to a heuristic decision in a classic ACID transaction, but is likely to be more
common.
Since such an autonomous decision will threaten, and may (like a heuristic
decision) destroy the consistency target that led to use of WS-BA, it is
important that it can be signalled as soon as possible. If the warning arrives
in time, it is possible (given that Business Activities may be long-running)
that the controller can cope with the decision – either cancelling/compensating
the whole activity, or ensuring that the rebellious participant is accommodated
somehow. (This is especially likely with participant-completion)
At present, WS-BA does not give a chance for the participant to report an
autonomous decision, until it is informed of the coordinator's decision.
Since WS-BA is based on one-way messages it would seem fairly straightforward
to allow the participant to reply before it is asked. If the answer is "right",
the protocol completes with this pre-emptive reply; if it is "wrong", the
relationship goes into the normal Fault/Faulted exchange.
ws-ba
spec
design
Peter Furniss
Peter Furniss
Allow Closed and Compensated to be sent by a Participant from Completed state,
triggering transitions to new states ("Auto-closed", "Auto-compensated").
If the "right" message arrives - i.e. Close or Compensate, respectively - resend
the Closed or Compensated and transition to Ended. (The resend may not be needed - the
earlier message may be perceived at the coordinator as the reply, but resending
avoids forcing the coordinator to remember the first message) If the "wrong" message
arrives (i.e. Compensate in Auto-closed, Close in Auto-compensate), send Fault and
transit to Faulting, awaiting Faulted as usual.
At the coordinator, receipt of Closed or Compensated in Completed state causes
no action and remains in the same state. It is not "ignored", because this is the
trigger for the coordinator/application to do something about the situation, but
there is no mandated protocol action.
Receipt at the coordinator of Closed or Compensated in the wrong state
(Compensating, Closing) is ignored - a Fault message will arrive later.
(It is not worth complicating matters further by allowing a pre-emptive Faulted,
thought it would work.)
Closed with no action during the
August 29-31, 2006 F2F meeting.
i074
Remove the optional RPC portTypes defined in wsat.wsdl
The RPC portTypes defined in wsat.wsdl are optional and not useful for
interoperability. These are the portTypes defined under:
<!-- Optional Syncronous RPC Port Types -->
Issue Details
Since the RPC portTypes are not useful for interoperability, they are
not useful at all and should be removed from the WSDL. These date back
to a time before the current state tables were defined and are not
compatable with the messages defined in the state table.
Given that the purpose of the specification is WS-AT interoperability,
the only portTypes the AT WSDL should define are the Mandatory
Asynchronous Messaging PortTypes.
ws-coord-wsdl
ws-at-wsdl
wsdl
editorial
Ian Robinson
Ian Robinson
Remove the optional RPC portTypes defined in wsat.wsdl i.e those defined
under:
<!-- Optional Syncronous RPC Port Types -->
Also remove from the wsat.xsd the types defined specifically for the RPC
portTypes. Specifically the types Vote, PrepareResponse, Outcome and
ReplayResponse.
In wsat.wsdl, remove the section "Optional Synchronous RPC Port Types" and rename
the section "Mandatory Asynchronous Messaging PortTypes" to
"Asynchronous Messaging PortTypes".
In wscoor.wsdl, remove the section "Mandatory Asynchronous PortTypes" and
rename the section "Optional Synchronous RPC Port Types" to "Request/Reply PortTypes".
proposal 2 was accepted during
August 10, 2006 TC call.
WS-AT: Completion protocol diagram should include coordinator-generated aborted transition
Consistent with resolution to issue 56, the Completion protocol diagram should
show the coordinator generated aborted transition from Active to Ended state.
ws-at
spec
editorial
Ram Jeyaraman
Ram Jeyaraman
In the Completion protocol diagram add a coordinator-generated transition from
Active to Ended state. Label the transition "Aborted".
The proposed resolution was accepted during
August 10, 2006 TC call.
i056
WS-BA: Protocol messages should be redefined to provide specific guarantees
It is fundamentally important for interoperability that the BA specification
provide a clear definition of the semantics of each protocol message, in order
to establish the precise state management guarantees that must be provided by a
conformant implementation.
For example, the current definition of Compensated does not indicate that the
participant should actually complete its compensation efforts before sending
the message. For a participant to return this message, all it has to do is
record a compensation request. It is not clear what has happened or will happen
to the work that needs to be compensated.
As another example, the current definition of the Exit message does not clearly
state what happened to the work performed by the participant prior to exiting.
Was the work successfully cancelled? Or perhaps no work was performed at all?
Similarly, other protocol messages need to be reviewed to ensure that specific
guarantees are provided.
ws-ba
spec
design
Ram Jeyaraman
Ram Jeyaraman
Modify the message definitions as follows:
The coordinator accepts:
Completed
Upon receipt of this notification, the coordinator knows that the participant
has successfully completed all processing related to the protocol instance. For the
next protocol message the coordinator should send a Close or Compensate notification
to indicate the final outcome of the protocol instance. After sending the Completed
notification, a participant MUST not participate in any further work under that
activity.
Fault
Upon receipt of this notification, the coordinator knows that the participant
has failed during the Active, Completing or Compensating states; the state of the
work performed by the participant is undetermined. For the next protocol message
the coordinator should send a Faulted notification. This notification carries a
QName defined in schema indicating the cause of the fault.
Compensated
After transmitting this notification, the participant may forget about
the activity. Upon receipt of this notification, the coordinator knows that the
participant has successfully compensated all processing related to the protocol
instance; the coordinator may forget its state about that participant.
Closed
After transmitting this notification, the participant may forget about the
activity. Upon receipt of this notification, the coordinator knows that the
participant has finalized the protocol instance successfully; the coordinator
may forget its state about that participant.
Canceled
After transmitting this notification, the participant may forget about
the activity. Upon receipt of this notification, the coordinator knows that the
participant has successfully canceled all processing related to the protocol
instance; the coordinator may forget its state about that participant.
Exit
"Upon receipt of this notification, the coordinator knows that the
participant will no longer participate in the business activity, and any work
performed by the participant related to the protocol instance was successfully
canceled. For the next protocol message the coordinator should send an Exited
notification. This message may be sent by a participant only from the Active
or Completing states."
The participant accepts:
Close
Upon receipt of this notification, the participant knows the protocol instance
is to be ended successfully. For the next protocol message the participant should send
a Closed notification to end the protocol instance.
Cancel
Upon receipt of this notification, the participant knows that the work being
done has to be canceled. For the next protocol message, the participant should send
a Canceled message. A Canceled message should be sent by the participant if the work
is successfully canceled; this also ends the protocol instance.
Compensate
Upon receipt of this notification, the participant knows that the work being
done should be compensated. For the next protocol message the participant should send
a Compensated notification to end the protocol instance. A Compensated message should
be sent by the participant if the work is successfully compensated; this also ends the
protocol instance. A Fault message should be sent by the participant if the work was
not successfully compensated.
Faulted
After transmitting this notification, the coordinator may forget about the
participant. Upon receipt of this notification, the participant knows that the
coordinator is aware of a fault and no further actions are required of the participant;
the participant may forget the activity.
Exited
After transmitting this notification, the coordinator may forget about the
participant. Upon receipt of this notification, the participant knows that the
coordinator is aware the participant will no longer participate in the activity;
the participant may forget the activity.
Further, the following statement in the Introduction section of the
specification should be modified from:
"All notifications are acknowledged in the protocol to ensure a consistent
view of state between the coordinator and participant."
to
"All non-terminal notifications are acknowledged in the protocol to ensure
a consistent view of state between the coordinator and participant. A coordinator
or participant may retry sending notifications in order to achieve this."
See email.
Proposal 2 was accepted during the
August 29-31, 2006 F2F meeting.
WS-BA: Allow Fault response to Cancel message
The specification allows a participant to send a Fault message while in
Active state.
Similarly, it is conceivable that a participant may send a Fault message
while in Canceling state.
ws-ba
spec
design
Ram Jeyaraman
Ram Jeyaraman
Allow a participant to send a Fault response to Cancel message.
The figures at line 245 and 268 should show a state transition resulting out of
a Fault notification from Canceling state.
The message definitions should be modified as follows:
Cancel
Upon receipt of this notification, the participant knows that the work being
done has to be canceled. For the next protocol message, the participant should send
a Canceled or Fault message. A Canceled message should be sent by the participant
if the work is successfully canceled; this also ends the protocol instance. A Fault
message should be sent by the participant if the work was not successfully
canceled.
Fault
Upon receipt of this notification, the coordinator knows that the participant
has failed during the Active, Canceling, Completing or Compensating states; the state
of the work performed by the participant is undetermined. For the next protocol
message the coordinator should send a Faulted notification. This notification
carries a QName defined in schema indicating the cause of the fault.
The state table (line 513) ParticipantCompletion/Participant View/Outbound
Events/:
{Fault, Canceling} cell should be: (empty, Faulting)
The state table (line 528) CoordinatorCompletion/Participant View/Outbound
Events/:
{Fault, Canceling} cell should be: (empty, Faulting).
The proposed resolution was accepted during the
August 29-31, 2006 F2F meeting.
Consistent with resolution to 66, rename Fault to Fail.
WS-BA: Meaning of 'Expires' attribute in coordination context is unclear
PDF line number: lines 152-155.
The BA specification states the following: "A coordination context may have
an Expires attribute. This attribute specifies the period, measured from the
point in time at which the context was first received, after which a long-running
activity may be terminated solely due to its length of operation. A participant
could terminate its participation in the long running activity using the Exit
protocol message."
This definition does not explain how the timeout composes with the
complete/completed messages. One would presume that, like the two-phase-commit
protocol, the timeout ceases to apply when the activity enters the
Completed state.
By not constraining this particular behavior, BA opens itself up to something
along the lines of heuristic decisions, justified on the basis of timeout
interpretations.
ws-ba
spec
design
Ram Jeyaraman
Ram Jeyaraman
Reword the definition of 'Expires' as follows:
"A coordination context may have an Expires attribute. This attribute specifies
the period, measured from the point in time at which the context was first created
or received, after which a long-running activity may be terminated solely due to
its length of operation. From that point forward, the coordinator may elect to
unilaterally compensate the transaction, so long as it has not made an outcome
decision. Similarly a participant may elect to exit the activity so long as
it has not already decided to complete."
See email.
Proposal 2 was accepted during the
August 29-31, 2006 F2F meeting.
WS-BA: 'presume nothing' assumption is contradicted
PDF line number: lines 233-242.
The specification states that: All state transitions are reliably recorded,
including application state and coordination metadata.
However, the description of GetStatus message states: "If the participant
has failed and forgotten the activity the Status response will be wsba:Ended,
which must be treated by the coordinator as a failure condition."
The fact that a participant may forget an activity due to a failure would
appear to contradict the assumption that all transitions are reliably recorded,
which violates the 'presume nothing' assumption of the protocol.
ws-ba
spec
design
Ram Jeyaraman
Ram Jeyaraman
Reword the description of GetStatus message from:
"If the participant has failed and forgotten the activity the Status response
will be wsba:Ended, which must be treated by the coordinator as a failure
condition."
To:
"If the participant has forgotten the activity, the Status response MUST be
wsba:Ended."
Further, line 234 (description of GetStatus) states:
"In response the coordinator or participant returns a Status message containing
a QName indicating which row of the state table [Appendix A: State Tables for
the Agreement Protocols] the coordinator or participant is currently in."
The word 'row' should be changed to 'column' in the above text.
The proposal resolution was accepted during the
August 29-31, 2006 F2F meeting.
Reference to SOAP 1.1 namespace
The WS-Coordination, WS-AT, and WS-BA specifications provide bindings for
SOAP 1.1 and SOAP 1.2.
However, the specifications do not include the namespace for SOAP 1.1, and
the references section does not mention SOAP 1.1.
The specifications should provide references to both SOAP 1.1 and SOAP 1.2.
ws-coord
ws-at
ws-ba
spec
editorial
Ram Jeyaraman
Ram Jeyaraman
See
email.
The proposed resolution was accepted during
August 24, 2006 TC call.
WS-AT: Volatile amnesia
Section and PDF line number: Section 10, CV and P state tables.
Following resolution to 081, we are left with two related sub-issues, as
discussed in 24/8 TC. This issue aims to scoop these up in one go.
1a. CV now transits directly to None whenever machine Forgets. This enabled
removal of All Forgotten row. P table has the same feature (transition to
None results from All Forgotten, which is implicitly generated by Forget action).
I see no reason not to align P table with this approach.
1b. P table is also inconsistent, internally, and with regard to CV table, in
that actions which should lead to None do not say "Forget"
except in the case of Commit Decision/Prepared Sucess.
2. Resolution of 081 failed to address the fact that volatile relationships
can transit to none through deliberate or accidental amnesia (volatile
participants are defined as ones which are not guaranteed to receive the
outcome, and either end could therefore decide to wipe its records of the
transaction, or could have them wiped by a crash without subseqent recovery).
This is not addressed in the state tables, which only allow transition to None
through transmission/reception of the past participle messages.
ws-at
spec
design
Alastair Green
Alastair Green
1. Relabel P table row All Forgotten as "Read Only Decision" and change the
Committing/Aborting columns in that row to "N/A".
2. Option A. All P table cells that cause a Send X, which then leads
(directly/indirectly) to None, should contain a final action Forget, and should
uniformly show a state transition "None". E.g. "Send Read Only and Forget";
"Send Aborted and Forget".
2. Option B. Remove action Forget from CV and P tables, and ensure that all
final actions which lead to None show that explicitly without indirection
through All Forgotten (as per 081 and resolution of this issue, 1. above).
This would be more consistent with resolution of this issue, 3. below.
3. Add a new row to both CV and P tables, following Max's suggestion,
called "Volatile Forgotten". All cells are "N/A" apart from Committing/Aborting.
These should read "None".
[NOTE: Volatile Forgotten (which will not be formally defined, in line with a
prior TC decision) is taken for the purposes of this resolution to mean:
"The coordinator view ! participant implementation is free to forget a
bilateral relationship where the participant is volatile, either through
positive action or post-crash amnesia, once the relationship is successfully
prepared, as there is no obligation to deliver the outcome to volatile
participants. The action or fact of forgetting in this way is represented
by the internal event Volatile Forgotten." For the avoidance of doubt,
this definition is not part of the proposed resolution.]
This issue has been resolved as per the tables (lines 518-522) in the
public review draft
of the AT specification. This resolution was accepted during
August 29-31, 2006 F2F meeting.
i081
CV table - CommitDecision in Preparing state
Section and PDF line number: Section 10, CV state table.
CV table, allows Commit Decision in Preparing. This makes it possible for
the CV to proceed to a commitment, before the participant has replied, leading
to an inconsistent result. It clearly should not be possible for CV to get to
PreparedSuccess *with respect to this participant* until it has received Prepared
*from this participant*.
ws-at
spec
design
Peter Furniss
Peter Furniss
Add a state ("Prepared") to CV table, entered only from Prepared/Preparing.
CommitDecision/Preparing becomes N/A.
Prepared cells for incoming messages are as for PreparedSuccess
(with no state change).
Prepared has N/A for all Internal Events except Expires Times Out,
Rollback Decision and Commit Decision, where it has the same entries as
Preparing has currently. (Comms Times Out is deemed "not to happen", because
a reply has been received).
This issue has been resolved as per the CV table (line 518) in the
public review draft
of the AT specification. This resolution was accepted during
August 29-31, 2006 F2F meeting.
WS-BA: specify 'presume compensate' assumption
WS-BA does not state a 'presume compensate' assumption.
ws-ba
spec
design
Thomas Freund
Thomas Freund
After line 73 insert:
In the absence of outcome information for a transaction the transaction
is presumed to have compensated.
State Table change:
The state table (line 520) ParticipantCompletion/Coordinator View/Inbound Events/:
{Completed, Ended} cell should be: (Send Compensate, Ended).
The state table (line 530) CoordinatorCompletion/Coordinator View/Inbound Events/:
{Completed, Ended} cell should be: (Send Compensate, Ended).
Close this issue. Update issue 71 as described in email.
Proposal 2 was accepted during
October 05, 2006 TC meeting.
WS-BA: Coordinator behavior upon Cancel/Completed race condition
Section and PDF line number: 249- 253.
WS-BA specification currently states the following:
"The coordinator can enter a condition in which it has sent a protocol
message and it receives a protocol message from the participant that is
consistent with the former state, not the current state. In this case, it
is the responsibility of the coordinator to revert to the prior state, accept
the notification from the participant, and continue the protocol from that point.
If the participant detects this condition, it must discard the inconsistent
protocol message from the coordinator."
In the case of Participantcompletion, the Cancel/Completed race condition
is resolved in favor of the participant. That is, the coordinator will transition
its internal state for the participant to Completed, and send forth a Compensate
or Close message. The specification is not clear which message (Compensate or Close)
is appropriate in this case; or is only Compensate the appropriate one. The spec
should provide some guidance.
Given that the coordinator had previously sent a Cancel, it seems logical
to send a Compensate (upon receiving Completed). However, one may argue that the
coordinator may have changed its mind, and hence, Close is quite a valid message
to be send (upon receiving Completed).
ws-ba
spec
design
Ram Jeyaraman
Ram Jeyaraman
This issue was closed with no action during
October 05, 2006 TC meeting.
WS-BA: State Table Errata
WS-BA State Table Errata.
ws-ba
spec
design
Thomas Freund
Thomas Freund
See email.
The proposed resolution was accepted during
October 05, 2006 TC meeting.
WS-BA: State table typo
There is a typo in the state tables of the recent BA document. Section C2, outbound
event Cancel/state Active contains Canceling-Active but should be Canceling.
ws-ba
spec
editorial
Kevin Conner
Kevin Conner
In the BA state tables, section C2, outbound event Cancel/state Active:
Change Canceling-Active to Canceling.
The proposed resolution was accepted during
October 19, 2006 TC meeting.
WS-BA: Schema omission
The wsba:Failing-Completing state has been omitted from the enumeration
in the schema document.
ws-ba-schema
schema
editorial
Kevin Conner
Kevin Conner
Add wsba:Failing-Completing to the enumeration in wsba.xsd.
The proposed resolution was accepted during
October 19, 2006 TC meeting.
WS-C: Editorial comments
See
email.
ws-coord
spec
editorial
Ram Jeyaraman
Ram Jeyaraman
See description section above.
The proposed resolution was accepted, along with comments as noted in the minutes, during
October 19, 2006 TC meeting.
WS-C/WS-AT: Comments on WSDL/XSD files
1. The WS-Addressing schema is imported in both wsat.wsdl and wscoor.wsdl, though
types from this schema are not used in either WSDL. The imports could each be
removed.
2. Further, the wsa:Action extension is in the WS-Addressing namespace instead
of the WS-Addressing WSDL Binding namespace in each document. (wsa:Action has been
changed to wsaw:Action; this changed from the submitted version where they were in the
same namespace). The namespace should be changed to
http://www.w3.org/2006/05/addressing/wsdl and it would be nice to use the
conventional "wsaw" prefix.
3. Check the copyright notices in XSD/WSDL files, and reconcile them with
the copyright notice in the corresponding specifications.
ws-coord-schema
ws-coord-wsdl
ws-at-schema
ws-at-wsdl
spec
editorial
Ram Jeyaraman
Ram Jeyaraman
See description section above.
The copyright of the WSDL documents are to be updated as described in the
email. Issue 104 has been opened to address the other aspects of this issue.
This resolution was accepted during
October 19, 2006 TC meeting.
i104
WS-C/WS-AT: Use of wsa:Action should be clarified
WS-Coordination implies in section 7 that [action] values are put in messages. But in
line 88, the text "if an action URI is used…". Line 408 says "fault MUST include
as the [action] property…". This seems to lead to inconsistency in when an action
must appear.
ws-coord
ws-at
spec
design
Ram Jeyaraman
Ram Jeyaraman
WS-Coordination, Section 1.5, line 88, remove the phrase "if an action URI is used
then". Thus, by enforcing use of wsa:Action uniformly, potential inconsistencies
may be avoided.
WS-AT, Section 1.3 line 68, the phrase "if an action URI is used then".
The proposed resolution was accepted during
October 19, 2006 TC meeting.
WS-C/WS-AT: RDDL document should use standard OASIS template
The RDDL documents are missing the OASIS template. For an example of the OASIS
template, see http://docs.oasis-open.org/ws-rx/wsrm/200608/wsrm-1.1-rddl-200608.html.
ws-coord-rddl
ws-at-rddl
rddl
editorial
Ram Jeyaraman
Ram Jeyaraman
See description section above.
The proposed resolution was accepted during
October 19, 2006 TC meeting.
WS-C: Remove Invalid Protocol fault
Section 4.2: What exactly does "Invalid Protocol" mean? When is it sent?
The explanation is unclear.
ws-coord
spec
design
Ram Jeyaraman
Ram Jeyaraman
Remove the fault.
Change fault description to:
This fault is sent by either the coordinator or a participant to indicate that the
endpoint that generates the fault received a message which is invalid for the
protocols supported by the endpoint. This is an unrecoverable condition.
Proposal 2 was accepted during
November 07-09, 2006 F2F meeting.
WS-AT: Editorial comments
See
email.
ws-at
spec
editorial
Ram Jeyaraman
Ram Jeyaraman
See description section above.
The proposed resolution, along with amendments as recorded in the minutes of November 02, 2006 and November 07-09, 2006,
meetings, was accepted during
November 07-09, 2006 F2F meeting.
WS-C: Update "reference properties" text
Section and PDF line number: Section 3.2, line 331; Section 6, line 572.
The
resolution
to issue 28 included:
3. Change all instances of "reference properties" to "reference parameters"
and "ReferenceProperties" to "ReferenceParameters".
On review of the PR spec there remain 2 instances where we still refer to
"reference properties".
ws-coord
spec
editorial
Ian Robinson
Ian Robinson
In Section 3.2, line 331; Section 6, line 572, change the instances of
"reference properties" to "reference parameters".
The proposed resolution was accepted during
November 07-09, 2006 F2F meeting.
i028
Remove wsaw:Action attribute from WSDL
Issue i099 properly noted that the WSDLs incorrectly used the "wsa" rather
than the "wsaw" namespace for the message "action" attribute.
While changing to the "wsaw" namespace is technically correct it may be
premature in that the WS-Addressing WSDL binding spec is not yet a Proposed
Recommendation and the wsaw namespace is likely to change.
Since there is no requirement to specify a wsaw:action attribute in the
WSDL, we can isolate ourselves from a dependency on the not-yet-stable wsaw
namespace by removing this attribute and the import of the schema for the
wsaw namespace.
The specifications already normatively define the action URI that MUST be
used in protocol messages. Having said that, the normative definition could
be made clearer than it currently is. The text (for example in the WS-C
spec) says:
The action URI MUST consist of the coordination namespace URI concatenated
with the '/' character and the element name. For example:
http://docs.oasis-open.org/ws-tx/wscoor/2006/06/Register
It may not be clear what "element" refers to here. Also, the action URIs
for faults do not follow this pattern as there is no message element part
of the URI. Instead each spec defines a specific action URI to be used for
all protocol faults defined for that spec. For example, WS-C says:
WS-Coordination faults MUST include as the [action] property the following
fault action URI:
http://docs.oasis-open.org/ws-tx/wscoor/2006/06/fault
ws-coord
ws-at
ws-ba
spec
editorial
Ian Robinson
Ian Robinson
1. Remove the wsaw:Action attribute and xsd:import of the wsaw namespace
from each WSDL.
2. In each spec, move the text in the "Namespace" section that begins "The
action URI MUST consist of..." to the section "Use of WS-Addressing
Headers" and and change the wording to:
Request and reply messages used in WS-Coordination MUST include as the
[action] property an action URI that consists of the wscoor namespace URI
concatenated with the "/" character and the element name of the message.
For example:
http://docs.oasis-open.org/ws-tx/wscoor/2006/06/Register
or
Notification messages used in [WS-AtomicTransaction | WS-BusinessActivity]
MUST include as the [action] property an action URI that consists of the
[wsat | wsba] namespace URI concatenated with the "/" character and the
element name of the message. For example:
http://docs.oasis-open.org/ws-tx/wsat/2006/06/Commit
This is clearer about which "element" we are referring to. The definition
of the fault action URI can be left exactly as is.
The proposed resolution was accepted during
November 07-09, 2006 F2F meeting.
i098
i099
WS-AT: Determine standard fault requirements in WS-AT
The Public Review Draft of WS-AT references 3 standard faults in the
State Tables in Section 9. Two of those faults are also referenced in
Section 9 prose and their definitions exist in Section 5.1 and 5.2.
What are the implementation requirements surrounding these standard
faults?
A similar question exists for WS-BA. Standardizing fault generation may
increase in importance for the compensating transaction model, as that
defined in WS-BA. Note, only WS-AT is addressed here.
It is logical that guidance on standard fault usage should come in WS-AT
(and WS-BA as appropriate) rather than WS-C. For WS-AT, two questions
are important for discussion:
* The requirements surrounding the use of standard faults in Section
9 in prose and the State Tables (and as supported in WS-C and
WS-AT, Section 5.1 and 5.2)
* Links to WS-C where those standard faults are defined,
particularly those currently used in WS-AT.
ws-at
spec
editorial
Monica Martin
Monica Martin
Consider in Section 9 "State Tables", WS-AT:
Change from:
503 ... Unexpected protocol messages will result in a fault
504 message, with a standard fault code such as Invalid State or
Inconsistent Internal State.
Change to:
503 ... Unexpected protocol messages SHOULD result in a fault
504 message. Such fault messages include those standard fault codes
defined in [WS-COOR] and found earlier in Section 5, Transaction Faults.
Reason for change: Invalid State fault is currently defined in WS-C but
no reference exists in WS-AT to WS-C for that fault (WS-C includes its
definition). Therefore, for simplicity, we have opted to realign the
sentence and provide the WS-C reference. It is recognized there may be
other faults than those specified here, such as those in WS-A. This
reasoning was used in the rewording suggested.
Any TC decision surrounding the rigor of guidance of the use of standard
faults will drive whether or not further statements are made in Section
9, particularly regarding those faults used in the State Tables in that
section. Our actions may also be related to any decisions surrounding
the RFC 2119 review initiated by Actions #56-58, to part of #097, and to
#102.
The proposed resolution, along with amendments as noted in the minutes, was accepted during
November 07-09, 2006 F2F meeting.
i097
i102
Requirement for the use of SOAP and the location of a CoordinationContext in a message is unclear
At present the only place within the AT and BA specs where a statement is
made about the use of SOAP w.r.t propagating a CoordinationContext and the
location of that context within a message is in section 4.2 of both
specifications during the discussion of WS-Policy assertions. In this
section in both specs it's stated that in the presence of an ATAsseration,
AtomicOutcomeAssertion, or MixedOutcomeAssertion that:
"The transaction MUST be represented as a SOAP header in
CoordinationContext format, as defined in WS-Coordination [WSCOOR]." (AT
279-280, BA 386-387 and 399-400).
Without any further statement elsewhere in the specs on the use of SOAP to
propagate a CoordinationContext or on the location of such a context in a
message it could reasonably be inferred that when a policy assertion is
present SOAP MUST be used and the CoordinationContext MUST be placed in
the SOAP header but when such an assertion is not present the use of SOAP
is optional and, irrespective of the use of SOAP, the context may be
placed anywhere in the message.
ws-at
ws-ba
spec
design
Andrew Wilkinson3
Andrew Wilkinson3
To resolve this I propose that a precise statement is made about the
required location of a CoordinationContext within a message in section 2
of each specification. Lines 145-146 in the AT spec would be modified to
read:
"The Atomic Transaction coordination context flows in application messages
involved with the transaction and MUST be represented in
CoordinationContext format as described in WS-Coordination [WSCOOR]. For
application messages that use a SOAP binding the CoordinationContext MUST
flow in the SOAP header of the message."
Lines 179-180 in the BA spec would be modified to read:
"The Business Activity coordination context flows in application messages
involved with the transaction and MUST be represented in
CoordinationContext format as described in WS-Coordination [WSCOOR]. For
application messages that use a SOAP binding the CoordinationContext MUST
flow in the SOAP header of the message."
In addition to the above changes the description of the three policy
assertions should also be amended. I believe there are two alternatives
here:
a) Modify the assertions to state the requirements more clearly:
AT lines 279-280 - final sentence of the description:
The transaction MUST be represented in CoordinationContext format, as
defined in WS-Coordination [WSCOOR]. For application messages that use a
SOAP binding the CoordinationContext MUST flow in the SOAP header of the
message.
BA lines 386-387, and 399-400 - final sentence of each description:
The transaction MUST be represented in CoordinationContext format, as
defined in WS-Coordination [WSCOOR]. For application messages that use a
SOAP binding the CoordinationContext MUST flow in the SOAP header of the
message.
b) Remove the final sentence from each of the three descriptions (AT
279-280, BA 386-387 and 399-400) as this is now specified in section 2.
The proposed resolution, along with amendments as noted in the minutes, was accepted during
November 07-09, 2006 F2F meeting.
Other Editorial Issues Surrounding AI#0057 Review for RFC 2119 (I#097)
See
email.
ws-at
spec
editorial
Monica Martin
Monica Martin
See description section above.
The proposed resolution, along with amendments as noted in the minutes, was accepted during
November 07-09, 2006 F2F meeting.
i102
Other Editorial Issues Surrounding AI#0057 Review for RFC 2119 (I#097), Submission 2
See
email
.
ws-at
spec
editorial
Monica Martin
Monica Martin
See description section above.
The proposed resolution, along with amendments as noted in the minutes, was accepted during
November 07-09, 2006 F2F meeting.
i102
i105
Normative descriptions of protocol messages
See
email.
ws-at
spec
editorial
Andrew Wilkinson
Andrew Wilkinson
See description section above.
The proposed resolution, along with amendments as noted in the minutes, was accepted during
November 07-09, 2006 F2F meeting.
WS-BA PR01 Errata (Issues 106, 107, 108 and miscellaneous deltas)
See
email.
ws-ba
spec
editorial
Thomas Freund
Thomas Freund
See description section above.
Public review comments on WS-BA
See
email
.
ws-ba
spec
editorial
Ian Robinson
Ian Robinson
See description section above.
Public review comments on WS-BA (#2)
See
email
.
ws-ba
spec
editorial
Ram Jeyaraman
Ram Jeyaraman
See description section above.