http://docs.oasis-open.org/ws-tx/issues/ Date: 2007/04/23 Revision: 42 spec schema soap wsdl policy rddl all Review Active Deferred Dropped Pending Done Resolved Closed 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. 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 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 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 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 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 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 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 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 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 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 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 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 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 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. 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 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 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 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 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 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 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. 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. 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. 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. 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. 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. 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 I