[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ws-rx] i061 - a revised proposal
Few comments on this issue: 1) The issue list description says nothing about what the issue is -- this should be updated. Obviously the issue is about dragons that may lie in the way if anon AcksTo is used. 2) Examining the interaction between ReplyTo and AcksTo values: a) ReplyTo is anon and AcksTo is non-anon: not a problem, replies will be sent over the "back channel" and acks would be sent separately from the replies. b) ReplyTo is anon and AcksTo is anon: not a problem, acks and replys can live together happily ever after. c) ReplyTo is non-anon, AcksTo is non-anon: not a problem, replies will be sent to the EPR in ReplyTo and acks will be sent to the AcksTo EPR. Replies may or may not be bundled together depending on whether the RMD can do EPR comparison and determine if ReplyTo EPR and AcksTo EPR are the same. d) ReplyTo is non-anon and AcksTo is anon -- this is the most interesting case, especially in the context of SOAP/HTTP. But I don't think this is necessarily a problem. Since ReplyTo is non-anon, the reply is sent to the ReplyTo EPR. The AcksTo EPR is sent over the back-channel. Now whether there is a back-channel or not will depend on the SOAP binding/MEP used and may or may not depend on what the WSDL MEP is. These MEPs are different and should not be conflated. In addition, the ws-addressing [reply endpoint] property is not necessarily correlated with the response/reply in a SOAP MEP or a WSDL MEP. There are two possibilities here in (d) above -- i) There is never a back channel available (say because WS-I BP conformant one-way WSDL MEPs are being used for every message in the Sequence) -- this is obviously a problem. But we already say in our spec the following: "Implementations MUST NOT use an endpoint reference in the AcksTo element that would prevent the sending of Sequence Acknowledgements back to the RM Source." ii) There is a back channel available in some interactions (messages sent with Sequence header) and not in others. For example, it is quite possible that messages sent within a Sequence use different WSDL operations, different SOAP MEPs or even different transports (some of which cannot have a back channel, eg: UDP). Obviously for operations/MEPs that don't have a 'back channel' can't use it for the acks. But that does not mean that there is never ever a back channel available for all messages in the Sequence. Three points to note here: 1) AcksTo applies to the entire Sequence and ReplyTo applies to a single message. I don't think there is anything wrong with having a 'anon' AcksTo EPR for a Sequence and a non-anon ReplyTo EPR for a particular message, as long as a back channel is available in other messages. 2) Both AcksTo and ReplyTo are set by the RMS, so it is safe to assume that the RMS knows what it is doing (if not, the RMS implementation isn't correct). 3) WS-Addressing [reply endpoint] isn't necessarily related to the a particular SOAP MEP or a WSDL MEP. Why do we need to say anything more than what we already have? -Anish --
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]