[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ws-tx] Issue 009 - WS-C/WS-AT: Is request-reply MEP useful?
Alastair,
Tom, I'm not deeply attached to any particular wording, but I am curious as to why you don't like this piece of text. I wanted to capture the fact that these protocols are not expected to require an independent reliable messaging substrate. This includes, but is not restricted to, the fact that they will operate over unreliable transports. Exchanges such as Prepare/Prepared or Commit/Committed do need to have the properties of exactly-once reliable messaging, to support full ACID, including the D: a) Initiator will retry until it gets an ack, and responder will resend ack every time it gets the initiator's message. b) Initiator failure/recovery will cause retry, responder failure/recovery will reinstall capacity to ack c) duplicates will be tolerated but eliminated (in this context, will not cause state changes, will seep into the sand in the state machine) a) is retriable, b) is reliable, and c) is EO. The phrase you're not happy with says "may in addition". It doesn't say: "will always". An application could, for example, decide to behave recoverably with respect to the sending of Register: once it has received the Context, it persists that fact, and will then attempt to resend Register when it recovers from crash. The retriable nature of Register/Respond (if we agree on that) enables the reliable behaviour that tolerates endpoint agent failure, but does not mandate it. Or the WS-AT 2PC protocol might be run ACID or ACInoD, durable or volatile, retriable or reliable. So, it seemed worth mentioning that persistence and state reconstitution would likely play a part in protocols that use WS-Coordination. By mentioning this I was trying to clarify, for the alert spec reader, the relationship of these protocols to reliable messaging. Or I am missing your point completely? Thanks, Alastair Thomas Freund wrote:
and post-failure state recovery rules to assure protocol operation in the face of endpoint agent failures. Regards Tom "Peter Furniss" <peter.furniss@choreology.com>
This is hereby declared to be ws-tx Issue 009. Please follow-up to this message or ensure the subject line starts Issue 009 - (ignoring Re:, [ws-tx] etc) The Related Issues list has been updated to show the issue numbers. Issue name -- WS-C/WS-AT: Is request-reply MEP useful? Owner: Alastair Green [mailto:alastair.green@choreology.com] Target document and draft: Protocol: Coord / AT Artifact: spec Draft: Coord spec working draft uploaded 2005-12-02 AT spec working draft uploaded 2005-12-02 Link to the document referenced: http://www.oasis-open.org/committees/download.php/15738/WS-Coordination- 2005-11-22.pdf http://www.oasis-open.org/committees/download.php/15719/WS-AT%20Working% 20Draft.pdf Section and PDF line number: WS-AT spec, Section 9 "Use of WS-Addressing Headers", ll. 412-457 Issue type: Design Related issues: Issue 007 - WS-C: Make Register/RegisterResponse retriable Issue 010 - WS-AT: Completion protocol should be interminable Issue 011 - WS-BA: Protocols should be terminable Issue Description: Why not eliminate use of request-reply MEP, thereby simplifying all three specs? Issue Details: Section 9 of WS-AT defines five types of message: request, reply, notification, terminal notification, fault. It shows how these relate to the WS-Addressing request-reply and one-way message exchange patterns (MEPs) and then specifies which category applies to the non-fault messages that appear in WS-Coordination, and in the WS- AT 2PC coordination protocols. However, this categorization is not performed for the Completion coordination protocol messages (Commit/Committed, Rollback/Aborted). There is no definition of the message exchange pattern for the Completion protocol in the spec. Is Completion intended to be a request-reply pattern, or a one-way based retriable and terminable exchange? Trying to understand which it should be leads to two related questions: * Why complicate the specs by using request-reply and one-way: wouldn't one-way do? * Are all one-way based exchanges terminable? The same questions are prompted by considering whether these categorizations and patterns need to be defined, used or referred to in WS-BA. The same line of thought emerges from consideration of related issue "Issue 007 - WS-C/WS-AT: Make Register/RegisterResponse retriable". A resend (as in resend of RegisterResponse) may be simpler if there is no need to correlate using message ids and RelateTo. Scenario: P sends message Register, id=20 to RS. P crashes and recovers. P sends Register, id=95. C sends RegisterResponse, relates-to=20 before 95 is received. P coughs in bemusement. Back to the two questions. It seems that it would simplify the specs and implementations if all message exchanges used the same MEP, i.e. one-way messages. (Note in this regard that the WS-AT spec bans use of the anonymous reply address, thereby removing any possibility of "thin client" behaviour.) What should the WS-AT and WS-BA specs say about terminable exchanges, specifically with relation to the unspecified characteristics of the Completion protocol, and the WS-BA specifications? This issue proposes a definition of a terminable exchange which is broader than that given in Section 9 of WS-AT. Two separate related issues, "WS-AT: Completion protocol should be interminable", and "WS-BA: Protocols should be terminable" allow separate consideration of the design of the exchanges for the coordination protocols which are as yet unspecified. The use of one-way messages, including the definition of a terminable protocol seem to belong in WS- Coordination, making them referenceable tools for WS-AT and WS-BA and other future coordination types/protocols. Proposed Resolution: 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. |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]