http://docs.oasis-open.org/ws-tx/issues/
WS-TX TC Issues List
Date: 2006/02/21
Revision: 05
spec
schema
soap
wsdl
policy
all
New
Active
Pending
Review
Deferred
Closed
Dropped
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."
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
i018
i019
i020
i021
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
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.
i008
i009
i014
Proposal 2 accepted on TC Telcon
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.
i003
i014
Proposed resolution accepted on TC Telcon
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.
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."
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.
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.
i013
Proposal 2 was made and accepted on TC Telcon
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.
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
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.
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.
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.
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.
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.
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."
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.
Coord
AT
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.
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.
Coord
WS-BA
WS-AT
spec
editorial
Ram Jeyaraman
Ram Jeyaraman
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"."