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

[Christopher B Ferris <chrisfer@us.ibm.com>]

Lei,

Please see my comments below.

Cheers,

Christopher Ferris
STSM, Emerging e-business Industry Architecture
email: chrisfer@us.ibm.com
blog: http://webpages.charter.net/chrisfer/blog.html
phone: +1 508 377 9295

"Lei Jin" <ljin@bea.com> wrote on 07/11/2005 03:18:42 PM:

> I have the impression after talking to a few people that there is the
> implicit assumption (though not specifically called out) in the spec
> that if the AcksTo EPR is set to use the anonymous IRI, then all
> subsequent acknowledgements for that reliable sequence will be sent back
> synchronously on the http response path of either the application
> message or an ack request message.

correct.

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

> (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?

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

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

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

> 
> Flames?
> 
> Lei
>