[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ws-tx] Issue 030 - 2 proposed resolutions
Ian, In the document on this issue that I submitted just after the last meeting, I raised four possible solutions: http://www.oasis-open.org/apps/org/workgroup/ws-tx/download.php/17588/2006-04-07.WS-Addressing.and.WS-TX.doc Your proposal 2 is very close to my Option 2 (Minimal Use of WS-A). This is the cleanest and best approach, in my view. My Option 3 somewhat resembles your proposal 1, but avoids active (non-none) use of [reply endpoint]. I believe that active use of [reply endpoint] has always been a source of confusion, and should be avoided in any resolution. Your Proposal 1 is probably closest to my Option 4, but deftly avoids the MUST use of a [reply endpoint]. I raised Options 1 and 4 as "strawmen" to elucidate the spectrum. * * * Your Proposal 2, while very close to my Option 2, does not fully deal with all the points that must be tackled. My Option 2 bullet points were: 2.A)
Use either WS-A [source
endpoint] or
a WS-TX [ws-tx amnesia endpoint] for non-terminal messages 2.B)
Do not mandate (but
tolerate)
presence of [fault endpoint] and [message id] on any message.
Or, ban use of these two properties.
Or mandate that they must be ignored if received. 2.C)
Treat WS-TX faults as
terminal
notifications, which can always be delivered, either to cached EPR or
to
supplied amnesia address. WS-A fault delivery rules (part of
reply-processing
model) do not apply. 2.D)
Set [reply endpoint] to
“none”, to
avoid dragging in “anon” default. This is necessary because
infrastructure
fault delivery might pick up on an anon value in some circumstances. 2.E)
Incorporate a statement
in the spec
making it clear that the reply-processing model of WS-A is not being
used. If
we choose to process [fault endpoint] and [message id] if supplied by
the
sender, then Section 3.4 reply-formulation rules may apply to faults,
and that
should be explained. 2.F)
Treat WS-A predefined
(infrastructure) faults as undeliverable (or potentially
undeliverable),
because i.
[fault endpoint] will or
may be
omitted ii.
[reply endpoint] is set
to none to
avoid use of anon, which is forbidden iii.
WS-A does not send faults
when
[fault endpoint] is absent, and [reply endpoint] is set to “none” iv.
[ws-tx
amnesia endpoint] is unknowable to
infrastructure (layer violation) I believe that your proposal 2 does not yet address bullet points 2.B), 2.E) and 2.F). * * * If we are not going down the Option 2/Proposal 2 route, then, in my view, Option 3 is preferable to your proposal 1 in a couple of respects. My Option 3 bullet points are repeated here: 3.A) Use either WS-A [source endpoint] or a WS-TX [ws-tx amnesia endpoint] for non-terminal messages 3.B)
Mandate presence of
[fault endpoint]
and [message id] on all messages 3.C)
Treat WS-TX faults as
WS-A faults.
WS-A fault delivery rules (part of reply-processing model) do apply.
All faults
are always deliverable, because of B). 3.D)
Set [reply endpoint] to
“none”, to avoid dragging in “anon” default. This is strictly
unnecessary because
the receiver will never use the [reply endpoint], but it does help make
it
clear that [reply endpoint] is not part of the picture, and that the
“anon”
endpoint will never be used. 3.E)
Incorporate a statement
in the spec
making it clear that the reply-processing model of WS-A is not being
used,
other than for faults It is not made clear that all messages must have message ids. They must, to apply reply-formulation rules for faults, and this should be clearly said. (Equally, if your proposal 1 is adopted, it is impossible to follow the reply-formulation rules for "amnesia" unless [relationship] is used, which requires [message id].) If you omit message id then you can legally create an undeliverable response which seems unnecessary. * * * My point 3.B) does not take account of the possibility of a [fault endpoint] = "none". Your proposal 1 does not address the possibility of a [reply endpoint] = "none" in the amnesia case. Can we not mandate that [fault/reply/souce endpoints] are non-anon, non-none unless specifically stated otherwise (e.g. to switch off [reply endpoint])? I think we may be in danger of losing an aspect of the original, intended content of the term "physical address" (i.e. a repliable, usable address, not a null value, nor an anon). *** Independently of the option chosen, and in line with dropping the term "physical address", the WS-Addressing spec definitions of "request-reply" or "one-way" do not exactly line up with what WS-TX is up to. One-way is defined as "no indication of future interactions", and that is not true of our messages. "Request-reply" is rather loosely, or flexibly, defined, and it would be hard to argue that some of the behaviours we have fall cleanly outside the scope of that term as described in WS-A. The point here is that we use the WS-A properties in a complex and partial way, to describe a bilateral conversation. References to the terms "one way" and "request-reply" could simply be avoided in favour of concrete descriptions of how WS-A properties are actually used, and direct reference to use of EPRs (WS-A Core 3.3) and reply-formulation (WS-A Core 3.4). This is most significant in WS-Coordination, where greater explicitness than you suggest would be appropriate (specify that [reply endpoint] and [message id] must be present on request messages, and that 3.4 should apply to all responses, fault or otherwise). *** I also suggested a procedure for triage of the various sub-points, which I still think would enable the discussion to effectively proceed from primary to secondary points in a clear way: 1. Which option?
2. If Option 2
(Your proposal 2) selected: a) [source endpoint] or
[ws-tx amnesia endpoint]? b) Permit and optionally
process [fault endpoint] + [message id] if
supplied. OR Permit and forcibly
process [fault endpoint] + [message id] if supplied,
OR Pemit but ignore [fault
endpoint] and [message id] if supplied. OR Ban [fault endpoint] and
[message id]? 3. If Option 3 selected: a) [source endpoint] or
[ws-tx amnesia endpoint]? b) Do we set [reply
endpoint] to “none”, or allow it to default to
“anon”? 4. Remove wording on
“physical addresses”, replace with ban on “anon”?
Alastair Ian Robinson wrote: Max and I have been working on some options for resolving issue 030 [1]. There has been a lot of good discussion on this issue already; we have suggested 2 (different) concrete resolutions that we can discuss on the call. Proposal 1 is closer to the status quo; it retains the use of the wsa:ReplyTo MAP for non-terminal notifications but adds a requirement for terminal notifications to set wsa:ReplyTo to 'None'. Proposal 2 replaces wsa:ReplyTo with wsa:From to further emphasize that protocol message are never replies. This proposal also classifies WS-TX "faults" raised during the agreement protocols (e.g. 2PC) as terminal notification messages. Proposal 1 (Issue30_Propsal_1_WSAT.doc) (See attached file: Issue30_Proposal_1__WSAT.doc) Proposal 2 (Issue30_Propsal_2_WSAT.doc) (See attached file: Issue30_Proposal_2__WSAT.doc) For either of these proposals, we believe WS-Coordination simply needs to remove text that is already stated in WS-Addressing: (See attached file: Issue30_Proposal__WSCOOR.doc) [1] http://docs.oasis-open.org/ws-tx/issues/WSTransactionIssues.xml#i030 Regards, Ian Robinson STSM, WebSphere Messaging and Transactions Architect IBM Hursley Lab, UK ian_robinson@uk.ibm.com |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]