[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
> 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. That would solve the interop issue (where the service does not send a reply on the HTTP response even though the replyTo is 'anon' -- 'cause it is not constrained to that message exchange). There was also another concern wrt making all uses of 'anon' in EPRs point to the response channel. Microsoft has a specific TCP usecase where the 'anon' EPR may point to a request channel as well. > Forcing other specs to define a URI that effectively has the same semantic > is silly. See my proposal above. We'll have to wait and see how issue CR23 is resolved, but there are members within the WS-Addressing WG, who believe that the semantics are different (back-channel in the same message exchange as opposed to back-channel in any message exchange related to a Sequence). In any case, my email was meant to be a heads-up and provide more details on the WS-A issue that affects us. HTH. -Anish -- Christopher B Ferris wrote: > > 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 > > > > > > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]