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

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

-Doug

"Gilbert Pilz"
<> 

03/02/2006 03:56 PM

To

Doug Davis/Raleigh/IBM@IBMUS,
<>

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

Sent: Monday, February 20, 2006 4:45 PM

To: 

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

02/20/2006 07:31 PM

To

Christopher B Ferris/Waltham/IBM@IBMUS

cc

"Yalcinalp, Umit"
<>, Doug Davis/Raleigh/IBM@IBMUS, 

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: 

> blog: http://www.ibm.com/developerworks/blogs/dw_blog.jspa?blog=440

> phone: +1 508 377 9295

> 

> "Yalcinalp, Umit" <> 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:]

>  > Sent: Monday, Feb 20, 2006 3:35 PM

>  > To: 

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

>  > 02/20/2006 06:11 PM

>  >

>  > Please respond to

>  > tom

>  >

>  > To

>  >

>  > wsrx <>

>  >

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

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