[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ws-tx] Issue 030 - Proposal 2 silence on WS-A faults
Alastair,
Yes, these 4 points all follow - as you have stated them - from our
Proposal 2.
Regards,
Ian Robinson
Alastair Green
<alastair.green@c
horeology.com> To
Ian Robinson/UK/IBM@IBMGB
21/04/2006 09:54 cc
ws-tx@lists.oasis-open.org
Subject
[ws-tx] Issue 030 - Proposal 2
silence on WS-A faults
Ian,
Further to yesterday's call, I want to make sure of my understanding of the
deliberate "silence on infrastructure faults" in your Proposal 2.
1. Sender of a notification message may set values for [fault endpoint],
[message id], neither, or both.
2. [fault endpoint]'s value, if present, is of no concern to WS-TX at all,
and can therefore be set to none, anon, or a "real address" at the sender's
will.
3. Receiver of a notification message may send WS-A faults to the fault
endpoint using [relationship]; may send to the anon endpoint if anon
specified as [fault endpoint] value, may choose to refuse to send a WS-A
fault at will, may be unable to send a WS-A fault through lack of property
values needed to follow the fault-formulation rules in WS-A SOAP
Binding/Core (absence of either of [fault endpoint] or [message id] has
this disabling characteristic)..
4. Under no circumstances is sender of "protocol messages" (including e.g.
InvalidState) to ever use or pay attention to the value of [fault
endpoint]: it can only use cached EPR or [source endpoint].
Is this a correct summary of the inferences that you and Max intended to be
drawn from silence in this circumstance?
Thanks,
Alastair
Alastair Green wrote:
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
I believe we should avoid the tangle with [reply endpoint]
altogether: the combination of [source endpoint] and [fault endpoint]
properly differentiates the two models for two kinds of messages.
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? My Option 2/Your Proposal 2 (which have same broad
thrust)
My Option 3
Your Proposal 1
[any other proposals raised]
[If we want to make this simple procedurally, then I would suggest
that we vote first on a motion to adopt the thrust of my Option
2/your Proposal 2. If that wins then the rest can fall away. That is
the big fault line, if you will pardon the pun.]
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”? [mandate non-none values for [source/fault endpoint]?
[Remove refs to one-way or request-reply?]
5. Revisit use of reply-processing model in WS-C?
Yours,
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]