[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?
WS-AT's section 9 served its purpose well in terms of achieving
interoperability. However, I can see why it might be preferable to
re-factor the content as appropriate between WS-C and AT/BA.
With that said, I do think there are substantial distinctions between
the message exchange patterns (MEPs) used for WS-C and WS-AT/BA
messages. This justifies the existence of the various message types
described in section 9.
WS-C's two MEPs are both relatively straightforward request/reply
operations:
- Requests are always initiated by the client.
- Each request receives exactly one reply.
- A request retry is a new logical sequences. Replies are not retried.
- Replies are correlated using the RelatesTo header.
This MEP is best modeled using the WS-A request-reply pattern.
WS-AT and WS-BA define MEPs that are more naturally peer-to-peer:
- Messages may be sent (unsolicited) by either side.
- Explicit retries may be performed inside same logical sequence.
- All messages are correlated by EPRs exchanged during registration.
This MEP is best modeled using the WS-A one-way pattern.
I think that attempting to force WS-C's MEPs to conform to WS-AT
pattern, or vice-versa, would entail pursuing a false consistency. Is
there a compelling functional reason to contort WS-C into a one-way
pattern, if it naturally tends towards request-reply semantics?
Furthermore, not every coordination protocol is necessarily going to
look like WS-AT and BA. Some protocols may be request/reply at heart,
or may define new types of MEPs. I think it makes sense to simply
define the natural pattern into which each spec's MEP naturally falls.
-----Original Message-----
From: Peter Furniss [mailto:peter.furniss@choreology.com]
Sent: Friday, December 09, 2005 9:54 AM
To: ws-tx@lists.oasis-open.org
Subject: [ws-tx] Issue 009 - WS-C/WS-AT: Is request-reply MEP useful?
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]