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

[Tom Rutt <tom@coastin.com>]

Christopher B Ferris wrote:
I think the key question we have to answer is what if the "sending" 
endpoint does other things than wsrm sends.    Would a sending
infrastructure be able to find the proper "wsrm"  RMS to dispatch the 
ACK to if the http response was for a non wsrm request?

Would we want the "back channel" ACK to be restricted to http responses 
where the request had a sequence header or ackRequested
header with the specific sequence ID that was negotiated in the create 
sequence with the acksTo=wsa:anonymous.

Tom

>
> Anish,
>
> Please see my inlined comments below.
>
> 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
>
> Anish Karmarkar <Anish.Karmarkar@oracle.com> wrote on 02/20/2006 
> 07:31:16 PM:
>
> > 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.
>
> exactly. 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.
>
> I guess I just don't see the issue. The URI itself means "backchannel".
> IMO, it should ONLY have any meaning w/r/t the semantics of an MEP
> in the specific context of a given MAP, such as wsa:ReplyTo or
> wsa:FaultsTo. WS-A WG is completely within their rights to define the
> clear semantics for those MAPs. However, I see no reason why the
> URI itself needs to be constrained to having any specific relationship
> to a particular message exchange. If WS-RX wants to define an EPR
> such as we have done with wsrx:AcksTo, then we should be free to accord
> it the semantics we desire.
>
> IMO, the proper way to resolve this is to have the anon URI mean
> "backchannel", period and to have the constraints that relate to the
> specific mapping to a SOAP MEP (which I think is possibly a mistake, but
> we'll leave that sleeping dog lie) apply to the wsa:ReplyTo and
> wsa:FaultsTo MAPs.
>
> >
> > 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.
>
> Forcing other specs to define a URI that effectively has the same 
> semantic
> is silly. See my proposal above.
>
> >
> > -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
> > >  >
> > >  >



-- 
----------------------------------------------------
Tom Rutt	email: tom@coastin.com; trutt@us.fujitsu.com
Tel: +1 732 801 5744          Fax: +1 732 774 5133