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.
|