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

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

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