Mark, Max:
Some comments arising from the recent exchanges, and then a proposal to
refine Proposal 2 (see bold heading Proposal towards end of
this mail).
I agree it is not a layering violation per se to use
WS-Addressing to target messages. There is no difference in principle
between using [source endpoint] (or [reply endpoint]) and [fault
endpoint]. In each case WS-A offers assistance to the upper (app) layer
for next/related message processing.
The argument that "it makes no sense to send faults to a different
endpoint" is ... well, arguable. WS-Addressing allows faults to be
directed somewhere different than normal responses. I could see an
architecture that centralizes fault reporting for the WS-A level, while
sending normal, good replies to the "real destination". You could argue
that the same might apply for WS-TX faults. However, I think it is true
that the WS-TX interlocutor might appreciate a rapid notification that
it, or its counterpart, are operating bugged, and this makes the TX
counterpart the natural recipient of errors such as Invalid State.
I think that Max's argument that the current scheme
"... includes bits of WS-A that complicate or confuse the core protocol
being described."
is a central point.
The difference between WS-A-layer faults and WS-TX-layer abnormal
messages is that WS-A layer faults require message-id-based correlation
to be targeted correctly, while WS-TX layer error messages (like all
other WS-TX messages) do not. They can avail of EPR reference
parameters, which are produced and consumed by the app-layer only.
EPRs provide an application-level mechanism for correlation, and that
is the fundamental model for AT/BA. Their use to argue and describe the
resolution to 007 (handling duplicate registrations) shows that they
can also fulfil all the correlation needs of WS-C.
Given this premise:
1. Only if we need WS-A-layer faults for correctness, MUST we include
[fault endpoint] and [message id] on all messages. I have argued that
we do not need them, and that is a fundamental premise of Proposal 2.
2. The WS-TX protocols do not need WS-A level correlation. We should
not exploit [fault endpoint] to
communicate the (non-critical) logic errors such as Invalid State etc
for this reason. That is the core argument for sending WS-AT/BA
"faults" in the same way as "normal messages". It would not be a
layering violation to use [fault endpoint] for abnormal messages, any
more than sending a normal message to [source endpoint] would be a
layering violation. Its use is overweight and redundant (and
potentially misleading, as Max observes).
3. The Invalid X faults defined in WS-C must be capable of being sent
in the same way as all other WS-AT/BA messages.
4. Given WS-Coordination's use of [reply endpoint] and [message id]
(which is part of what I think is meant by "request-reply") we would
either have to send Invalid X faults using [relationship], or we could
ignore the received [reply endpoint] and [message id], and send them
without [relationship] (abandoning the S3.4 rules in this special
case). In either approach we end up with inconsistent treatment --
Invalid X messages are sent correlated in WS-C but uncorrelated in
WS-AT/BA, or, faults are sent uncorrelated, but responses are sent
correlated, in WS-C.
5. But, we do not need [reply endpoint], [message id] and
[relationship] for WS-Coordination exchanges. We simply need an EPR
target for responses, which can equally well be [source endpoint] as
[reply endpoint]. (Cf. Resolution of 007). Then all WS-C messages
(normal responses or Invalid X messages) would travel to the
initiator's [source endpoint]. In this sense, the WS-C CCC/CCCR and
R/RR exchanges are no more (or less) "naturally" request-reply than the
WS-AT Completion exchanges, for example. The presence of [message id]
and [relationship] creates two mechanisms for registration correlation
when only one is needed, which is a good example of the current use of
WS-A introducing complexity and confusion.
6. Invalid X messages may be sent in response to terminal messages,
therefore they need a response address, which should also be [source
endpoint].
Proposal
Therefore, we should move to a simple, uniform model, refining and
restating Proposal 2:
All WS-TX messages MUST contain a WS-Addressing [source endpoint]
property whose value is neither [the anon URI] nor [the none URI],
which MAY be used by the receiver to target a subsequent message back
to the sender. All WS-TX messages MUST contain a WS-Addressing [reply
endpoint] property whose value is [the none URI].
(Note in passing that the term "physical address" was meant, I believe,
as a synonym for "non-anon, non-none", and that the current text of
Proposals 1 and 2 has narrowed it down to meaning "non-anon".. The
square brackets around [the anon URI] etc indicate: substitute the
proper value or a formal reference.)
This model would apply to all of the protocols, including WS-C.
I would further propose that we facilitate delivery of WS-Addressing
SOAP Binding predefined faults, which can be useful in internal and
interop testing, by stating:
If the WS-Addressing [fault endpoint] and [message id] properties
are present in an inbound message then the receiver SHOULD use
WS-Addressing Section 3.4 rules to formulate and send any relevant
WS-Addressing SOAP Binding Predefined Fault as a reply.
Interop scenario executions should not be deemed to fail if an
implementation fails to generate such WS-A faults.
These two principles on use of WS-Addressing properties could be stated
once, in WS-C, and would apply to all referencing specifications. The
non-anon, non-none rule needs to be restated in respect of the
coordinator and participant protocol endpoints for Register and
RegisterResponse, also in WS-C, using the following text:
This endpoint reference must have a value which is neither [the anon
URI] or the [none URI]
to be inserted in the element description for
Register/ParticipantProtocolService and
RegisterResponse/CoordinatorProtocolService.
Alastair
Mark Little wrote:
Max Feingold wrote:
If the question is why the WS-A mechanism
isn't good enough, I believe
the answer has already been provided: the semantic embodied by
'Aborted' is similar to the semantic embodied by 'InvalidState' in that
both signals are generated and consumed by the same architectural
layer.
It makes little sense to compose them differently and send them to
potentially different endpoints. We have already defined a mechanism
for sending the first, so why not use it for the second? This is not a
declaration of WS-A inadequacy, but a statement about how our protocols
should work.
Actually that is an interesting argument for not using wsa:FaultTo.
Maybe I missed it in previous emails, or it's in the minutes of the
last telecon (where are they ;-)? However, taken to the extreme, it
could then be argued that the same discussion will eventually be had by
most/all users of WS-A and as a community we should agree that
wsa:FaultTo is only for WS-A related errors/faults (something which the
current WS-A specification does not state).
Mark.
-----Original Message-----
From: Bob Freund-Hitachi [mailto:bob.freund@hitachisoftware.com] Sent:
Sunday, April 23, 2006 3:14 PM
To: Alastair Green; Ian Robinson
Cc: ws-tx@lists.oasis-open.org
Subject: RE: [ws-tx] Issue 030 - Proposal 2 silence on WS-A faults
In that case, you might consider removing all references to
ws-addressing, since you seem not to want to deal with it. I am curious
as to what the motivation for dumping it might be.
Does ws-tx presume that it will always be operating in a soap bound to
http environment?
Will all endpoints be addressable at all times?
Will all transports supported by the spec allow implicit
success/failure
status transmission to the sender? HTTP provides a backchannel
mechanism (the equivalent to anonymous replyto) but some don't.
I get the distinct feeling that folks are imagining an environment
where
the medium is raw (or shall I say unconstrained) tcp/ip.
I often hear use of the phrase "one-way" message, and occasionally its
definition is cited as being contained within Ws-addressing (which does
no such thing). At the moment I have no idea exactly what is meant by a
"one-way" message since currently, no bindings that describe it
normatively exist.
Can these one-way messages generate a fault that might be communicated
to the sender or perhaps to someplace else?
I do not see the distinction that is being made between
"infrastructure"
faults and protocol faults. If a fault of either sort needs to go
somewhere, is that somewhere addressable at the time the fault is
generated or will the soap/http implicit backchannel have gone away
since the fault managed to happen some time after "200/202/204" and
your
one chance of returning a single http response entity (as per HTTP 1.1.
If I were to imagine a soap over scsi environment, there is NO WAY to
send a non-encoded fault message unless you retain the id of the
initiator and establish some sort of correlation mechanism to the
message that caused the fault.
I think that the happy implementer may be finding that he has a bit of
infrastructure to replicate.
I have no trouble with tossing the stuff that ws-addressing provides,
provided that it is done with malice and forethought.
At the moment, I am completely baffled over the motivation behind
proposal 2.
Thanks
-bob
-----Original Message-----
From: Alastair Green [mailto:alastair.green@choreology.com] Sent:
Friday, April 21, 2006 8:21 AM
To: Ian Robinson
Cc: ws-tx@lists.oasis-open.org
Subject: Re: [ws-tx] Issue 030 - Proposal 2 silence on WS-A faults
Leaving the cheerful implementer free to never generate [fault
endpoint]
and [message id], and always to ignore them. Good stuff.
Alastair
Ian Robinson wrote:
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/20
06-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
|