http://docs.oasis-open.org/ws-tx/issues/ Date: 2006/01/31 Revision: 03 spec schema soap wsdl policy all New Active Pending Review Deferred Closed Dropped 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." 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 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 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]" 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. i003 i014 Proposed resolution accepted on TC Telcon 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 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 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 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 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. 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 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 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. 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. 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. 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. 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."