Re: [ws-rx] NEW ISSUE: WSRX:AcksTo should not use wsa:AnonymousURI

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

Right, but that is in relation to a
REPLY. An Ack is not a reply. It is an Ack. I can certainly
appreciate the desire to constrain the
semantic of anon in wsa:ReplyTo and wsa:FaultsTo
to be *the response backchannel for
this request message*, but I don't believe that they
should do this by according the semantic
to the URI, but rather to the MAPs themselves
when the URI is specified as its value.

Cheers,

Christopher Ferris
STSM, Emerging e-business Industry Architecture
email: chrisfer@us.ibm.com
blog: http://www.ibm.com/developerworks/blogs/dw_blog.jspa?blog=440
phone: +1 508 377 9295

Doug Davis/Raleigh/IBM@IBMUS wrote on 02/20/2006 08:37:23
PM:

> 
> Anish Karmarkar <Anish.Karmarkar@oracle.com> wrote on 02/20/2006
08:27:51 PM:
> > What if one uses the wsa:RelatesTo as the correlator in the message.
> > I.e., client sends a message to a service with 'anon' as the
replyTo. 
> > The service does *not* send the reply in the HTTP response. But
in some 
> > subsequent interaction (say a req-optional-response MEP), the
service 
> > sends the reply in the HTTP response with the wsa:RelatesTo in
the 
> > message. Is that conformant to WS-A?
> 
> No, because there is no guarantee that the receiver of this response
> can hand it over to the original client.  You're basically allowing
> for the server to mix-n-match where responses go and assuming that
> all endpoints on the receiving end can share/exchange replies - and
> that's not a safe assumption. 
> 
> btw - ws-polling does provide a way to solve this since WSA doesn't
> solve it natively.  If WSA wanted to take on this problem I think
> it would be a huge improvement and benefit for the WS community. 
> IMO, WSA should solve the anon/firewall issue w/o the need for 
> additional specs - but I suspect that's out of scope right now  :-(
> 
> thanks, 
> -Doug