[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
Doug Davis wrote: > > 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 The credit goes to Glen (cc-ing). I'm merely doing a "fair and balanced" reporting of what happened on the WS-A call ;-) > 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. > What if one uses the wsa:RelatesTo as the correlator in the message. I.e., client sends a message to a service with 'anon' as the replyTo. The service does *not* send the reply in the HTTP response. But in some subsequent interaction (say a req-optional-response MEP), the service sends the reply in the HTTP response with the wsa:RelatesTo in the message. Is that conformant to WS-A? > 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 > > > > > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]