NEW issue: WS-C/WS-AT: Is request-reply MEP useful?

[Alastair Green <alastair.green@choreology.com>]

Issue name -- WS-C/WS-AT: Is request-reply MEP useful?

PLEASE DO NOT REPLY TO THIS EMAIL OR START A DISCUSSISON THREAD UNTIL 
THE ISSUE IS ASSIGNED A NUMBER.

The issues coordinators will notify the list when that has occurred.

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 [] WS-C: Make Register/RegisterResponse retriable
Issue [] WS-AT: Completion protocol should be interminable
Issue [] 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 
"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.