In general, the concern that is being articulated is where a node knows
that an HTTP message carrying a SOAP body is a one-way MEP, and the
introduction of ackTo anonymous effectively converts that MEP into a
two-way MEP.
Other Comments inline
> -----Original Message-----
> From: Christopher B Ferris [mailto:]
> Sent: Monday, July 11, 2005 1:24 PM
> To:
> Subject: Re: [ws-rx] NEW ISSUE: anonymous AcksTo
>
<snip/>
>
> >
> > I think that is not a good idea. First of all, we are saying that
even
> > if my application message is one way (or asynchronous), I might
still
> > receive something back on the http response(the WS-RX ack). Nothing
> > really precludes this usage, but we are introducing unnecessary
> > dependency between WS-RX (acknowledgement messages) and
WS-Addressing
>
> I don't understand your suggestion of a dependency.
>
It's pretty clear that a WS-A ReplyTo of non-anonymous means that the
reply should go to the ReplyTo value, not the backchannel. One of the
advantages of WS-A ReplyTo is to enable one-way/fire-and-forget
scenarios.
> > (normal MEP). For example, if I have an intermediary on the server
side
> > that takes an incoming message, looks at the reply-to address (or
> > message MEP), and decides to close http connection if it's a oneway
or
>
> How can you have an intermediary (it would have to be an HTTP proxy if
the
> anonymous URI is used for AcksTo) that is compliant with the HTTP
> specification
> if it closes the connection with the client before the HTTP response
is
> received?
How about it closes the connection after it gets the 2xx? That's what
you'd expect from a one-way MEP. Especially if it's the 202 that is
blessed by WS-I BP for one-ways.
>
> > asynchronous message, everything works fine. Now, with WS-RX, it
has to
> > know that "hmm, maybe I shouldn't close that connection if WS-RX is
> > involved and synchronous ack is used".
>
> One would assume that an endpoint that specified the anonymous URI for
the
>
> AcksTo EPR would know what it was doing and would in fact be expecting
> that
> the acks would be transferred on the HTTP response messages.
>
Lei's example is for an intermediary that knows about the MEP but won't
work correctly unless it adds knowledge of WS-RX.
> >
> > Secondly, the paragraph below quoted from WS-Addressing spec says
the
> > anonymous IRI shouldn't be used as the destination in any other
> > circumstances other than the destination for reply messages. I
don't
> > see acknowledgements as reply messages.
>
> What makes you think that an ack is not in some way considered a
reply?
>
Various protocols have different definitions of "Reply". The very fact
that WS-A uses "ReplyTo" for "responses" and "FaultTo" for "faults"
shows that WS-A treats responses as Replies and faults as faults.
I've always been troubled by the looseness of what can be considered a
Reply vs a "Response" and the relationship to MEPs. The reason the
relationship to MEPs is important is that it may be important for a
request-response binding to know whether a response is allowed,
required, or not allowed.
> >
> > WS-Addressing defines the following well-known IRI for use by
endpoints
> > that cannot have a stable, resolvable IRI:
> > "http://www.w3.org/2005/03/addressing/role/anonymous" Requests
whose
> > [reply endpoint], [source endpoint] and/or [fault endpoint] use this
> > address MUST provide some out-of-band mechanism for delivering
replies
> > or faults (e.g. returning the reply on the same transport
connection).
> > This mechanism may be a simple request/reply transport protocol
(e.g.,
> > HTTP GET or POST). This IRI MAY be used as the [destination] for
reply
> > messages and SHOULD NOT be used as the [destination] in other
> > circumstances.
> >
> > Proposal 1:
> >
> > Specifically call out that the AcksTo EPR should not use the
anonymous
> > IRI.
>
> I disagree. In fact, I think that there are compelling use cases where
> the only viable approach to receive acks is on the HTTP response
message.
>
> >
> > -- One reason to use an anonymous IRI is so that the acknowledgement
may
> > reach sending endpoints that may be sitting behind a NAT or
firewall.
> > But we have to deal with the same problem with asynchronous response
> > messages anyway.
>
> Actually, __we__ don't have to deal with that at all. It is out of
scope
> of this
> TC to deal with such matters. This would be the purview of some other
WG
> such as the WS-Addressing WG or the XMLP WG.
>
> >
> > Proposal 2:
> >
> > Specifically call out that an anonymous IRI in the AcksTo EPR would
> > indicate acknowledgement message will only be sent back in response
to
> > ack request messages where the ack request message should be a
> > standalone synchronous invoke.
>
> Why? How is this different than flowing acks on the HTTP response
message
> for any other message? Frankly, I don't believe that there is an issue
> here.
This solves the problem, that the MEP isn't transformed from a one-way
into a two-way.
Personally, I think the anonymous IRI is actually inappropriate for this
case. The WS-Addressing working group is probably (or has?) added
another special name for "not allowed". Imagine that a ReplyTo has
"not-allowed" value which really clearly says it's a one-way mep, and
then there's an anonymous ackTo.
I'd suggest a friendly mod to Proposal 2 to say call out a "not allowed"
IRI in the AcksTo. It might also need a bit more to say that
"anonymous" IRI is not allowed when MEP is one-way.
Cheers,
Dave
