OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ws-rx message

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