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

[Doug Davis <dug@us.ibm.com>]

That's just my way of thinking of it
 :-)    same socket == http response flow  to me  
-Doug

"Gilbert Pilz" <Gilbert.Pilz@bea.com>

03/02/2006 03:56 PM

To	Doug Davis/Raleigh/IBM@IBMUS, <ws-rx@lists.oasis-open.org>
cc
Subject	RE: [ws-rx] NEW ISSUE: WSRX:AcksTo should not use wsa:AnonymousURI

Where is the justification
for defining "the back-channel" as "the socket"? I
would think that a more natural definition, at least in the SOAP/HTTP case,
would be "the HTTP response of this HTTP request".
 
- gp

---

From: Doug Davis [mailto:dug@us.ibm.com]
Sent: Monday, February 20, 2006 4:45 PM
To: ws-rx@lists.oasis-open.org
Subject: Re: [ws-rx] NEW ISSUE: WSRX:AcksTo should not use wsa:AnonymousURI


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

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

_______________________________________________________________________
Notice:  This email message, together with any attachments, may contain
information  of  BEA Systems,  Inc.,  its subsidiaries
 and  affiliated
entities,  that may be confidential,  proprietary,  copyrighted
 and/or
legally privileged, and is intended solely for the use of the individual
or entity named in this message. If you are not the intended recipient,
and have received this message in error, please immediately return this
by email and then delete it.