[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
Gil, I did mean to say reference parameter not reference properties. 'refp' is a short form that has been in use in WS-A for a while. Old habits. >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. I don't either. As you know I did make the 'isAnon' proposal to the WS-A WG, but the WG did not like it :-( WRT using non-existent reference properties: 'reference parameters' are the new 'reference properties' if you look around and see how they are being used -- ws-notification, ws-resource framework, ws-eventing, ws-transfer etc. -Anish -- Gilbert Pilz wrote: > 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]