Alastair,
To me that particular text appears to stray into the realm of implementation (choice). It's something we strive to keep out of the document if at all possible. Overall the (remainder of the) suggested text is fine.
Regards
Tom
Alastair Green <alastair.green@choreology.com>
12/13/2005 08:32 AM |
|
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:
- Seems ok ... except for the suggested text "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.
Regards
Tom
"Peter Furniss" <peter.furniss@choreology.com>
12/09/2005 11:53 AM |
|
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.
