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