http://docs.oasis-open.org/ws-tx/issues/
WS-TX TC Issues List
Date: 2006/06/20
Revision: 15
spec
schema
soap
wsdl
policy
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
ws-at
spec
design
Mark Little
Mark Little
Remove BusinessAgreementWithCoordinatorCompletion.
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
ws-at
spec
design
Mark Little
Mark Little
Remove MixedOutcome.
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.
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.
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.
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.
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.
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".
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."
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.
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."
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: 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."
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.
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.]
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.'
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.
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.
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.
i045
Inconsistency on WS-BA use of "Fault"s
See email.
ws-ba
spec
design
Alastair Green
Alastair Green
See section "proposed resolution" in
email.