Re: [ws-rx] i061 - a revised proposal

[Christopher B Ferris <chrisfer@us.ibm.com>]

+1

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 01/26/2006 03:43:41 PM:

> 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
> --