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

[Anish Karmarkar <Anish.Karmarkar@oracle.com>]

Doug Davis wrote:
> 
> Hopefully I'll use the right terminology.... to me I've never associated 
> anonymous with
> a particular MEP but rather with "this socket" - at least as far as http 
> is concerned.
> The use case you mention is a great one - and I totally agree that 
> anonymous should

The credit goes to Glen (cc-ing). I'm merely doing a "fair and balanced" 
reporting of what happened on the WS-A call ;-)


> not mean "any old back-channel" - there has to be some kind of 
> correlator to make sure
> that you know the user of the "anon" URI (ie. the client) will be the 
> same guy that gets the
> message destined for the "anon" URI.  The only way you can do this today 
> in WSA is to
> use "this socket".  Any other approach that allows for some other socket 
> to be used MUST
> use some kind of correlator which WSA doesn't not currently have.
> 

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?

> Now, WSRM is ok to use it for the AcksTo EPR because we introduce a 
> correlator - the
> SequenceID/header.  We only send Acks on the back-channel (this socket) 
> when the
> incoming/request message referenced that same Sequence - that's our 
> correlator.
> 
> I don't see any issue.
> 
> -Doug
> 
> 
> 
> *Anish Karmarkar <Anish.Karmarkar@oracle.com>*
> 
> 02/20/2006 07:31 PM
> 
> 	
> To
> 	Christopher B Ferris/Waltham/IBM@IBMUS
> cc
> 	"Yalcinalp, Umit" <umit.yalcinalp@sap.com>, Doug 
> Davis/Raleigh/IBM@IBMUS, ws-rx@lists.oasis-open.org
> Subject
> 	Re: [ws-rx] NEW ISSUE: WSRX:AcksTo should not use wsa:AnonymousURI
> 
> 
> 	
> 
> 
> 
> 
> 
> More background on what happened in the WS-Addressing call.
> 
> 1) WS-Addressing resolved CR4 [1], which was filed on behalf of WS-RX.
> That issue in a nutshell was: 'anon' URL is scoped too narrowly to
> reply-to/fault-to ERP and that WS-RX needed a broader definition to
> allow 'anon' AcksTo and not have to define new things.
> It was resolved to make all EPRs with 'anon' address values mean the
> 'back-channel'.
> 
> 2) Subsequently CR15 [2] was filed and resolved. CR 15 removed the
> changes inserted as a result of CR4. CR 15 resolution resulted in
> defining what 'anon' meant in the context of SOAP 1.1 and SOAP 1.2 in
> separate sections.
> 
> 3) When this (2 above) was discovered I filed a new issue [3].
> Essentially saying -- WTF.
> 
> 4) On today's call we discussed what all this meant and the WS-RX
> specific usecase. On the call a few people stated that their
> understanding of 'anon' meant the back-channel for ***that particular
> message exchange*** not any message exchange. Please note that this is
> not stated in the WS-Addr specs today. What is in the specs today, to
> answer Doug's question, (both WS-Addr and WSRX) does not contradict each
> other or prevent WSRX from using the 'anon' value for the address
> component of AcksTo EPR (except for opinions in the WS-Addr WG that say
> that 'anon' does not mean any back-channel in any message exchange
> within a sequence).
> 
> Specifically, the concern is:
> If 'anon' means any backchannel then this is problematic for interop.
> Consider the scenario where, it is a regular (non WSRX) req-res and the
> client sets the reply-to to 'anon' EPR. If 'anon' does not mean the
> back-channel for *that* message exchange then it is OK for the service
> to not send the response in the HTTP response (and say that it is
> conformant) but send the response in some subsequent request -- that
> would not be good.
> 
> The suggestion that was kicked around was:
> scope 'anon' EPRs to mean the back-channel for the same message
> exchange. If specs like WSRX need a way to express AcksTo EPR denoting
> the any/all backchannels for any/all messages within that Sequence then
> WSRX should define a new URI for the address value (say
> http://www.oasis-open.org/.../anon-acksTo) in the EPR and use it.
> Personally, I don't think this restricts WSRX in anyway (we'll have to
> define a new URL though) and allows us to do exactly what we are doing
> today. Of course this does impact existing impls.
> 
> -Anish
> --
> 
> [1] http://www.w3.org/2002/ws/addr/cr-issues/#cr4
> [2] http://www.w3.org/2002/ws/addr/cr-issues/#cr15
> [3] http://www.w3.org/2002/ws/addr/cr-issues/#cr23
> 
> Christopher B Ferris wrote:
>  >
>  > I would not have thought that it was limited in this manner. Nor do I
>  > think that it should be. Maybe I need to lurk on the WS-A calls:-)
>  >
>  > I'd like to understand the architectural rationale given for such a
>  > constraint.
>  >
>  > 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
>  >
>  > "Yalcinalp, Umit" <umit.yalcinalp@sap.com> wrote on 02/20/2006 
> 06:58:21 PM:
>  >
>  >  > IMHO, it does not, but that is my opinion :-)
>  >  >  
>  >  > Having said that, there was quite a long discussion on this today at
>  >  > the WS-A concall.
>  >  > Some members of the wg (myself NOT included) believe that  the
>  >  > definition of anonymous only applies to the single MEP and hence it
>  >  > would not apply to acksTo.
>  >  >  
>  >  > --umit
>  >  >  
>  >  >
>  >  > From: Doug Davis [mailto:dug@us.ibm.com]
>  >  > Sent: Monday, Feb 20, 2006 3:35 PM
>  >  > To: ws-rx@lists.oasis-open.org
>  >  > Subject: Re: [ws-rx] NEW ISSUE: WSRX:AcksTo should not use
>  > wsa:AnonymousURI
>  >
>  >  >
>  >  > Tom - can you provide a pointer to where in WSA it limits its use as
>  >  > you describe (single MEP exchange)?
>  >  > thanks
>  >  > -Doug
>  >  >
>  >  >
>  >
>  >  >
>  >  > Tom Rutt <tom@coastin.com>
>  >  > 02/20/2006 06:11 PM
>  >  >
>  >  > Please respond to
>  >  > tom
>  >  >
>  >  > To
>  >  >
>  >  > wsrx <ws-rx@lists.oasis-open.org>
>  >  >
>  >  > cc
>  >  >
>  >  > Subject
>  >  >
>  >  > [ws-rx] NEW ISSUE: WSRX:AcksTo should not use wsa:AnonymousURI
>  >  >
>  >  >
>  >  >
>  >  >
>  >  > NEW ISSUE: wsrm:acksTo should not use wsa:AnonymousURK
>  >  >
>  >  > Problem statement:
>  >  >
>  >  > The wsa:anonymousURI is defiined in WS addressing for use in a single
>  >  > MEP exchange.
>  >  >
>  >  > What we really need in wsrm:acksTo is a uri which has the intended
>  >  > semantics:
>  >  >
>  >  > "return the wsrm:acknolwedgment soap header in the underlying response
>  >  > to any soap request which contains a wsrm defined soap header with
>  >  > this sequenceID."
>  >  >
>  >  > This is really quite specialized semantics, and should be defined 
> with a
>  >  > wsrm: specific URI.
>  >  >
>  >  > Proposal:
>  >  >
>  >  > Define a wsrm specific URI which has the desired semantics for use in
>  >  > the wsrm:acksTo URI.
>  >  >
>  >  > --
>  >  > ----------------------------------------------------
>  >  > Tom Rutt                 email: tom@coastin.com; trutt@us.fujitsu.com
>  >  > Tel: +1 732 801 5744          Fax: +1 732 774 5133
>  >  >
>  >  >
>