It is assumed that even a “one way”
message when there is the potential of faults (nearly always I think), is in
reality a request-response message with a potentially null response.
The purpose of faultTo is to provide an
address other than replyTo should the implementer decide that faults should go
to a different place.
Specialized (non general use cases) exist
where responses are ALWAYS expected to be on a back-channel, thus the
defaulting mechanism that is specified in WS-A and a somewhat grudging optional
on messageid since in this case correlation may be preformed implicitly.
In general, when messages may be sent and
received asynchronously with respect to the lifetime of an underlying protocol
specific backchannel, ReplyTo will be explicitly set to the desired value.
In order to support either deployment
scenario, then it is required to specify both replyTo as well as messageid in
the sent messages so that returned replies, even if they are only fault
messages, may be correlated through relatesTo.
I don’t think that I have seen any
one-way messages in the wild other than possibly of non-reliable logging-type
messages where there is no particular concern about its receipt or faults it
may produce
Cheers
-bob
From: Alastair Green [mailto:alastair.green@choreology.com]
Sent: Tuesday, March 21, 2006 7:59
AM
To: Doug Davis
Cc: Mark Little;
ws-tx@lists.oasis-open.org
Subject: Re: [ws-tx] Issue 30 -
One-way message replies
Mark, Doug:
I don't think that the section I quoted, tho' it appears in 3.4, is limited to
the "reply processing model". It references section 3.2:
/wsa:ReplyTo
This OPTIONAL element (of type
wsa:EndpointReferenceType) provides the value for the [reply endpoint]
property. If this element is NOT present then the value of the [address]
property of the [reply endpoint] EPR is "http://www.w3.org/2005/08/addressing/anonymous".
This seems to me to unambiguously enforce a default of
anonymous when using the XML infoset.
Section 3.4 simply reminds the reader that this rule exists and will apply
(also) in the reply processing model (which I agree and understand we may not
want to use -- that's why I raised this whole discussion in the first place).
As for the question of where a fault goes to -- you raise an interesting
dimension, Doug. :As I understand it there are two kinds of fault we could be
talking about here:
1) An application-defined fault which the application contract determines
should go to the fault-to EPR of a prior and related inbound message
2) A standard WS-Addressing fault, predefined in the WS-A SOAP binding spec
Properties are provided by WS-Addressing to assist in delivering fault type 1).
If you choose not to use them, then that's fine. The direction we seem to be
heading in here is to define a WS-TX "fault" as "yet another
WS-TX coordination protocol message with WS-TX-defined semantics, that happens
to be generated when an inbound message causes a state machine to take an
alternative path (generate a different message than it would when pursuing the
normal, happy path)".
However, the standard WS-Addressing faults do need to use the apparatus defined
in WS-Addressing.
Section 6 ("Faults") of the WS-A SOAP binding spec (http://dev.w3.org/cvsweb/~checkout~/2004/ws/addressing/ws-addr-soap.html)
reads, in part:
Endpoints compliant with this specification MUST
include the required message addressing properties serialized as SOAP headers
in generated fault messages. Fault messages are correlated as replies using the
[relationship] property as defined in Web Services Addressing 1.0 - Core[WS-Addressing-Core].
Note that omission of the [message id] property in an input message may impact
the ability of a fault message receiver to correlate the fault message to the
message that caused the fault message to be generated. Omission of the [fault
endpoint] or [reply endpoint] properties in input messages may impact the
delivery of a generated fault message
So, to allow correct WS-Addressing predefined fault
processing, all WS-A applications/implementations must specify message ids and
at least a fault-to EPR. Arguably, if the [reply endpoint] is allowed to
default to anonymous then the absence of a message id would not prevent the
delivery of the fault (no correlation needed).
However, it does appear that WS-A SOAP binding fault processing expects use of
the whole "reply processing model" apparatus with respect to standard faults. This
would militate against omission of fault-to and reply-to, an omission which I
think you view as "normal" for one-ways.
Therefore: we can properly avoid use of [reply endpoint], but it is far from
clear that we can escape [fault endpoint] so easily.
And, if we have to drag [fault endpoint], [message id] and [relationship] back
in for this purpose, then it would appear that the difference between one-way
and the full-scale "reply processing model" is more apparent than
real. Are we coming full circle?
If we default reply-to to anonymous (by omission), and live with the fact that
faults must now travel on the anonymous back-channel, then I guess you could
just about get away with ignoring the reply processing model. But that requires
some heroic assumptions.
The statement:
"Fault messages are correlated as replies using the
[relationship] property as defined in Web Services Addressing 1.0 - Core[WS-Addressing-Core]."
seems, on the face of it, to be normative. The qualifications in the following
sentences about "impacting" the ability to deliver faults could be
seen to weaken the force of that statement, but once again, I get that queasy
feeling that one is in danger of bending and dodging the design intent of
WS-Addressing.
Alastair
Doug Davis wrote:
I don't think you want to do that because in the
absence of a wsa:FaultTo, setting
wsa:ReplyTo
to "none" prevents you from getting back any fault messages - not
Tx,non-related,
faults, but other ones. These are just normal one-ways which
people
normally leave replyTo/faultTo blank - I see no reason to make them
anything
special but including a 'none' replyTo.
-Doug
Mark,
My point is that the WS-Addressing spec mandates that an absent reply-to causes
the receiver to infer an anonymous response:
Section 3.4 of the latest draft:
Note:
The
[reply endpoint] message addressing property will always be present when using
the XML Infoset representation since, in the absence of a wsa:ReplyTo element,
the value of the [reply endpoint] message addressing property defaults to an
EPR with an [address] property of "http://www.w3.org/2005/08/addressing/anonymous"
- see section 3.2 XML Infoset Representation of Message Addressing
Properties.
My
understanding of this note, and of section 3.2, is that this inference MUST be
drawn by a receiver, irrespective of any extension property like wsc:Response.
Hence my proposal that we explicitly set wsa:ReplyTo to "none".
Alastair
Mark Little wrote:
The discussion during the f2f concluded that we are indeed using wsa:ReplyTo in
a way that, although probably legal, is not the way it was meant to be used and
can lead to confusion (as we've seen here). So the first step in the process of
removing that confusion, is to remove wsa:ReplyTo, which was my proposal. What
we replace it with, and what the rules are around it, are the central points of
the issue.
Alastair Green wrote:
Mark,
Taking off from a comment in the last paragraph of my written contribution on
this area during the F2F
http://www.oasis-open.org/apps/org/workgroup/ws-tx/email/archives/200603/msg00088.html
I think we need to address, in resolving this issue, the question of the [reply
endpoint] value being defaulted to anonymous.
The issue is about replacing wsa:ReplyTo in the case of "one ways that may
ultimately have a response but aren't really request-response based
messages" (to paraphrase). So in that case, we would be defining the rules
around wsc:ReplyTo (just a name I've picked for this email so I can easily
refer to it as being different to wsa:ReplyTo). As such, anonymous may not even
play in that space. Why would we want an anonymous default? The current uses of
wsa:ReplyTo really all assume that it was present on the message. I'd prefer a
binary approach for wsc:ReplyTo.
An absent [reply endpoint] property in the XML infoset representation becomes a
receiver-inferred value of "anonymous" (actually, the URI that means
anon).
It seems preferable that we explicitly specify the value of "none"
(again, a URI in truth).
I would have expected us to be more specific: if there's a wsc:ReplyTo present,
then this is the destination that MAY/SHOULD/MUST be used for sending a
response. The absence means that no response is needed - no default.
This is explicit, intuitively what one would expect for a one-way in terms of
HTTP handling, and avoids any ambiguity/under-specification if a different
representation is used at some future point.
The current wording banning use of anonymous reply-to addresses would then be
replaced.
I think we also need to ban use of message ids, and ban use of fault-to, i.e.
make it clear (by omission or by explicit statement) that none of these aspects
of the reply-processing rules and apparatus are being put to use.
("Ban" in this context could mean "make it clear that these
properties, if present, will be ignored".)
We had discussed at the f2f that wsa:FaultTo is really meant just for comms
faults and "application faults" would be treated as messages. I'm not
sure if that made it into the minutes.
I think use of wsa:From tends to detract from the clarity obtained by defining
an extension property for our special use.
Mark.
Yours,
Alastair
Mark Little wrote:
Line 472 and 480.
Mark.
Ram Jeyaraman wrote:
Mark,
Could you please provide the PDF line numbers in the referred document that are
relevant to this issue. Thanks.
------------------------------------------------------------------------
*From:* Ram Jeyaraman [mailto:Ram.Jeyaraman@microsoft.com]
*Sent:* Friday, March 17, 2006 2:48 PM
*To:* ws-tx@lists.oasis-open.org
*Subject:* [ws-tx] Issue 30 - One-way message replies
This is identified as WS-TX issue 30.
Please ensure follow-ups have a subject line starting "Issue 30 -"
(after any Re:, [ws-tx] etc.)
===================================
Issue name: One-way message replies
Issue type: spec
Owner: Mark Little (mark.little@jboss.com)
Reference documents:
WS-AT specification:
http://www.oasis-open.org/apps/org/workgroup/ws-tx/download.php/17044/http://www.oasis-open.org/apps/org/workgroup/ws-tx/download.php/17129/wstx-wsat-1.1-spec-wd-04.pdf
<http://www.oasis-open.org/apps/org/workgroup/ws-tx/download.php/17044/http:/www.oasis-open.org/apps/org/workgroup/ws-tx/download.php/17129/wstx-wsat-1.1-spec-wd-04.pdf>
Description:
Currently we use wsa:ReplyTo for one-way messages in a way which although legal
in terms of the latest CR draft of WS-Addressing, has led to confusion on a
number of occasions. As an example, one use of wsa:ReplyTo is on Prepare->Prepared,
where Prepare has a wsa:ReplyTo but the Prepared message is a separate (not
response) message, because it could be sent autonomously and not actually in
response to Prepare. The issue is that as far as WS-Addressing is concerned,
wsa:ReplyTo should really only be used in the case of the request-response MEP,
which is clearly not the case here.
Proposed Resolution:
The rules for where and when wsa:ReplyTo should be included and used within
WS-AT are well defined, and particularly in respect to the interoperability
scenarios. I propose that we replace wsa:ReplyTo with something specific to
WS-TX (perhaps wsc:ReplyTo, wsc:OnewayTo, or somesuch).
Addendum:
Max suggested at the Raleigh
f2f another potential resolution: that we use wsa:From.