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

[Doug Davis <dug@us.ibm.com>]

In general +1 and I'd be ok with closing
the issue with no action.  The only part that worries
me a bit is that it may not be obvious
to some people what exactly is supposed to happen
when RM is used and there's an anon
AcksTo but a one-way is sent.  My experience with
having worked with people who have implemented
the spec is that it wasn't clear to them
that this "new" behavior is
expected of them.  Things like piggy-backing of acks on non-RM
messages, or creating a new message
just for acks are things that might be obvious
to us but haven't always been obvious
to some people I've run into who read the spec.
So, that's why I proposed adding this
bit of text to make it really clear to people what's
expected of them and so that we reduce
interop issues.  If we don't put text like this in
here we might find that it ends up in
some profile and while that can work I prefer it when
a spec can be interopable on its own.
thanks,
-Doug

Anish Karmarkar <Anish.Karmarkar@oracle.com>

01/26/2006 03:43 PM

To	Doug Davis/Raleigh/IBM@IBMUS
cc	ws-rx@lists.oasis-open.org
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
--