OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

ws-rx message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

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.


Anish Karmarkar <Anish.Karmarkar@oracle.com>

02/20/2006 07:31 PM

Christopher B Ferris/Waltham/IBM@IBMUS
"Yalcinalp, Umit" <umit.yalcinalp@sap.com>, Doug Davis/Raleigh/IBM@IBMUS, ws-rx@lists.oasis-open.org
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

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.


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

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]