RE: [ws-rx] NEW ISSUE: anonymous AcksTo

["David Orchard" <dorchard@bea.com>]

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:chrisfer@us.ibm.com]
> Sent: Monday, July 11, 2005 1:24 PM
> To: ws-rx@lists.oasis-open.org
> 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