[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ws-rx] PR issue 1 - WS-Addressing comment on ws-rm related touse of extended anonymous uri
> I'm not sure that I would agree. I think that this may in fact be > an errata on the WS-A SOAP Binding spec. I think that what was meant > was that the SOAP Binding (defined by the SOAP1.1 RoR) does not change > since I believe that it was the intent of the WS-A Group to have > that binding defined specifically so that WS-Addressing could be > used. I would also point out that this (SOAP1.1 RoR)is, in principle, > what almost all SOAP stacks do in practice anyway. I think we *are* in agreement here. I do believe it is an errata. I was trying to make a point that WS-A IMO did not go a good job of the whole 'anon' issue. The specs tried to say as few things as possible and therefore leave a few things open. There are two potential errata issues for the wsa soap binding here: 1) use of 202 when ReplyTo is wsa anon. Currently it says the SOAP 1.1/HTTP binding does not change. It should say the binding, which includes SOAP1.1/HTTP as defined by SOAP 1.1 + ROR, does not change. 2) It doesn't say anything about what happens if the ReplyTo is non-anon? Does the binding change? Is it required that 202 be sent back? Can a SOAP envelope be still sent back with a 200 response? These are open and important questions that remain unanswered. -Anish -- Christopher B Ferris wrote: > > I'd like to add my own $0.02 to a point that Anish made: > > > > and for SOAP 1.1/HTTP it says: > > > > > > "When "http://www.w3.org/2005/08/addressing/anonymous" is > > > specified for the response endpoint then there is no change > > > to the SOAP 1.1/ HTTP binding." > > > > > > What does all this mean wrt to sending a message to a an EPR > > > that has WS-A 'anon' as a value of wsa:Address? I don't know. > > > All it says is that the SOAP 1.1/HTTP binding does not > > > change. I.e. ROR is *not* allowed. > > > I.e. the 'response' has to be sent back on HTTP back channel. > > I'm not sure that I would agree. I think that this may in fact be > an errata on the WS-A SOAP Binding spec. I think that what was meant > was that the SOAP Binding (defined by the SOAP1.1 RoR) does not change > since I believe that it was the intent of the WS-A Group to have > that binding defined specifically so that WS-Addressing could be > used. I would also point out that this (SOAP1.1 RoR)is, in principle, > what almost all SOAP stacks do in practice anyway. > > Cheers, > > Christopher Ferris > STSM, Software Group Standards Strategy > email: chrisfer@us.ibm.com > blog: http://www.ibm.com/developerworks/blogs/page/chrisferris > phone: +1 508 377 9295 > > "Gilbert Pilz" <Gilbert.Pilz@bea.com> wrote on 09/28/2006 07:48:45 PM: > > > Overall I think this sums up the situation pretty well. I do have one > > disagreement that I've marked in line . . . > > > > - gp > > > > > -----Original Message----- > > > From: Anish Karmarkar [mailto:Anish.Karmarkar@oracle.com] > > > Sent: Thursday, September 28, 2006 12:59 PM > > > To: Paul Fremantle > > > Cc: Doug Davis; Gilbert Pilz; ws-rx@lists.oasis-open.org > > > Subject: Re: [ws-rx] PR issue 1 - WS-Addressing comment on > > > ws-rm related to use of extended anonymous uri > > > > > > Paul, > > > > > > I was merely trying to say that this issue (whether ws-a anon > > > uri is appropriate for MakeConnection) was raised during this > > > discussion without saying whether I agree with it or not. > > > > > > Here is my view on things: > > > > > > WS-A WG did a poor job on WS-Anon (granted they had some > > > constraints wrt timing/charter). There are still some dragons > > > in WS-A anon and the semantics are underdefined. > > > > > > Forgetting that the name 'anon' is a misnomer, this is what > > > the Core spec says: > > > > > > "Some endpoints cannot be located with a meaningful IRI; this > > > URI is used to allow such endpoints to send and receive > > > messages. The precise meaning of this URI is defined by the > > > binding of Addressing to a specific protocol and/or the > > > context in which the EPR is used." > > > > > > This doesn't mean a whole lot and one has to look at the binding. > > > > > > The SOAP Binding of WS-Addr says: > > > > > > "A value of "http://www.w3.org/2005/08/addressing/anonymous" > > > for the [destination] property implies no additional > > > semantics beyond those resulting from the rules defined below > > > and as described in Web Services Addressing 1.0 - > > > Core[WS-Addressing Core]. In particular, note that Web > > > Services Addressing 1.0 - Core[WS-Addressing Core], section > > > 3.4 requires such a value in messages sent to a response > > > endpoint whose [address] is > > > "http://www.w3.org/2005/08/addressing/anonymous"." > > > > > > [Note: 'Response endpoint' in that section refers to ReplyTo/FaultTo] > > > > > > and for SOAP 1.1/HTTP it says: > > > > > > "When "http://www.w3.org/2005/08/addressing/anonymous" is > > > specified for the response endpoint then there is no change > > > to the SOAP 1.1/ HTTP binding." > > > > > > What does all this mean wrt to sending a message to a an EPR > > > that has WS-A 'anon' as a value of wsa:Address? I don't know. > > > All it says is that the SOAP 1.1/HTTP binding does not > > > change. I.e. ROR is *not* allowed. > > > I.e. the 'response' has to be sent back on HTTP back channel. > > > > > > There are two problems with this: > > > 1) This specifically disallows sending a 202 using SOAP 1.1 > > > ROR HTTP Binding addendum note. This is a problem for WS-RM, > > > if you want to send message and poll for a response later. > > > 2) It does not say anything beyond the SOAP/HTTP binding > > > "MEPs". What is the semantics when used in AcksTo? What does > > > it mean when used in an EPR that is not replyTo/Faulto? It is > > > not defined. > > > > > > If you ignore what the spec-ese says and look at the > > > intention (as I see > > > it): > > > > > > The WS-A WG mostly looked at this from the view of > > > ReplyTo/FaultTo and in the context of res-res > > > MEP/transmission primitives. The intention was to allow > > > clients to say: send me stuff on the back-channel of this > > > http-connection OR open a new connection. The problem is > > > *this* http-connection, which is not what is meant by WSRM anon URI. > > > > > > How do we get out of this? > > > I think we have two solutions: > > > > > > 1) keep the WSRM anon URI as is and ask WS-Addr to relax > > > their requirements on wsaw:Anonymous wsdl marker or the > > > policy-friendly marker/assertion that they are thinking about. > > > > > > 2) remove WSRM anon URI and reuse WS-Addr anon uri. And use refps. > > > Define a specific ref property including comparison rules. > > > That is what refps were meant for. The reason for not using > > > these were cause of trepidations around WS-Addr issue 1, web > > > arch issue and all that good stuff. > > > > The WS-Addressing Core spec *does* *not* define any such thing as a > > "reference property". It defines "reference parameters" and is specific > > about the fact that reference parameters are opaque to everyone except > > the party that created the EPR. As I understand it, the fact that > > reference properties aren't in the WS-Addressing Core spec is not a > > mistake by omission; the WG deliberately decided that they didn't want > > reference properties (for various resons only some of which had to do > > with Web architecture). I don't understand why it's unthinkable to > > "break" the Core spec by adding a "useBackChannel" attribute to > > wsa:Address yet it's somehow ok to "ignore" the Core spec by using > > non-existent EPR properties. > > > > Also please don't use the term "refp". It could stand for either > > reference parameters or reference properties, an ambiguity which is not > > very helpful in the current context. > > > > > Personally I'm fine with either of the two options, but I > > > know Doug had some problems with (2) not related to WS-Addr > > > issue 1. I don't quite understand or agree with that, so > > > won't try to explain it. > > > > > > If we use option (2), the issue we'll have to tackle is the > > > fact that the SOAP/HTTP binding does change when you use the > > > refp in the replyTo/FaultTo to allow 202. OR say that when > > > used in replyTo/FaultTo the reply/fault must be sent in the > > > back-channel of *that* connection except when there is a > > > failure (in which case there is no change to the SOAP/HTTP > > > binding as WS-A stipulates). > > > > > > HTH. > > > > > > -Anish > > > -- > > > > > > Paul Fremantle wrote: > > > > Anish > > > > > > > > I'm not clear exactly which interaction you are talking about. Any > > > > chance you can give a scenario and explain exactly which > > > anon URI in > > > > which interaction *may* be at fault. > > > > > > > > Paul > > > > > > > > Anish Karmarkar wrote: > > > >> Paul, > > > >> > > > >> The replyTo/FaultTo was just an example. What I was trying > > > to convey > > > >> was that, during the MakeConnection discussion there was > > > point made > > > >> that we *may* not be able to use the WS-A 'anon' URI because that > > > >> particular URI identifies the back-channel (in the case of > > > soap/http) > > > >> for a particular connection, whereas an ws-rm 'anon' URI > > > identifies > > > >> any back-channel of a connection created by the > > > MakeConnection message > > > >> containing the right/same UUID. > > > >> > > > >> -Anish > > > >> -- > > > >> > > > >> Paul Fremantle wrote: > > > >>> Anish > > > >>> > > > >>> I don't agree with this point. RM is composing with the > > > existing flow > > > >>> to *add* reliability. There are many reasons that the > > > server cannot > > > >>> reply on the backchannel - network failures, timeouts, > > > etc. In those > > > >>> cases the original contract for delivery is over, since > > > WS-A and SOAP > > > >>> have no inherent retry or retransmission model. WS-A does not and > > > >>> should not say what goes on beyond that original > > > request/response. If > > > >>> or how the reply gets returned beyond that point is not WS-A's > > > >>> concern. That is when RM should kick in. At no point was it the > > > >>> intention or the result of WS-A to prevent the composability with > > > >>> reliability with the existing URI schemes. > > > >>> > > > >>> I suggest anyone who has any doubt about this carefully > > > rereads the > > > >>> distinction between "response" and "reply" in the WS-A spec. > > > >>> > > > >>> Paul > > > >>> > > > >>> Anish Karmarkar wrote: > > > >>>> Doug Davis wrote: > > > >>>>> > > > >>>>> IIRC there were some other reasons as well. > > > >>>> > > > >>>> Another reason that was discussed was: > > > >>>> is it even valid to use the WS-A 'anon' URI for this? > > > >>>> WS-A 'anon' URI in a ReplyTo/FaultTo says, send the > > > reply/fault in > > > >>>> the HTTP-response (back-channel) of *this* connection (in the > > > >>>> SOAP/HTTP binding case), whereas the WS-RM 'anon' URI in a > > > >>>> ReplyT/FaultTo means send the reply/fault in the > > > HTTP-response of > > > >>>> this connection (in the SOAP/HTTP binding case) or *any* > > > >>>> HTTP-response of a connection created using the > > > wsrm:MakeConnection > > > >>>> message with the correct/same UUID. > > > >>>> > > > >>>> -Anish > > > >>>> -- > > > >>>> > > > >>>> <snip/> > > > >>>> > > > >> > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]