RE: [ws-rx] i061 proposal / directions

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

"Gilbert Pilz" <Gilbert.Pilz@bea.com>
wrote on 01/23/2006 06:41:27 PM:

> [text sizes changed to make them readable]

Wish I knew why it did that  :-(

> Doug said:
> If an RMS uses it then it knows how to handle
the http backchannel 
> for acks.  If the RMD accepts it then it knows how to use it
> too. If neither side faults on its use then I don't see the issue.
> As Chris said, the RMD is always free to fault on its use and an 
> RMS is always free to use a non-anonymous URI.  Both sides actually
> have a lot of control here.  My proposal simply states what both
> sides can expect if it is used - if they don't like it they don't
> have to use it - but at least its written down what people should
> expect.
> I'm a little confused by this statement. In my
mental model of this 
> issue, the use of the anonymous URI in the AcksTo EPR is only a 
> problem in cases where the AS/RMS subsequently "uses the sequence
to
> engage in"* message exchanges for which there is no backchannel
(e.
> g. one-way operations using a SOAP/HTTP implementation which does
> not put SOAP envelopes in the HTTP response). If the AS/RMS uses the
> sequence for messages conforming to a synchronous "send a SOAP
> request over HTTP, wait for the SOAP reply in the HTTP response"
> pattern there is no problem because there is a backchannel for 
> acknowledgements to return upon. Thus it seems unnecessarily 
> restrictive for an RMS to forgo all uses of the anonymous URI for
> the AcksTo EPR simply because it "knows" that, in some cases,
there 
> is no SOAP backchannel.
>  
> * Note; when I say "uses the sequence to
engage in" I am implying  
> that every message that carries a SOAP header with the same <wsrm:
> Identifier> is part of some logical application-level abstraction
> and that all the messages with that identifier will conform to the
> same interaction pattern. I know that this does not match your model
> of independent, intermediary RMS/RMD pairs that carry all "traffic
> that is to be transmitted reliably" between two clusters of services.
>  
> 
>  
> All of this still begs the question of how someone
implementing an 
> RMS or an RMD "knows" that the use of the anonymous URI
in the 
> AcksTo EPR might be problematic? The only thing we say about the 
> AcksTo EPR in the current spec is (lines 262-264 of wsrm-1.1-spec-cd-02)
is:

> Implementations MUST NOT use an endpoint reference
in the AcksTo 
> element that would prevent the sending of Sequence Acknowledgements
> back to the RM Source. For example, using the WS-Addressing "none"
> IRI would make it impossible for the RM Destination to ever send 
> Sequence Acknowledgements.

> The proposal listed here (http://docs.oasis-open.org/ws-
> rx/issues/ReliableMessagingIssues.xml#i061) does not mention the 
> possibility that there may not be a SOAP backchannel for the 
> acknowledgements to flow back on. I'm wondering how we expect a 
> developer to know precisely when and where the use of the anonymous
> URI in the AcksTo EPR might be problematic when our spec says 
> nothing about the subject?

Didn't you answer your own question?  You said
that anonymous acksTo
might only be an issue when there isn't a soap envelope
flowing
back on the http response flow.  So, in those
cases the developer
should not use anonymous for AcksTo.  

I don't think our spec says "nothing" about
the subject - it says that
people MUST NOT use an EPR for AcksTo that makes it
impossible to
send back Acks.  There are many reasons there
could be for this so
I think its ok to leave it a bit open-ended - and
I think no-backchannel
with the anon URI would be covered by the section
of the spec you
quoted.

Basically, we can provide guidance that covers these
cases but I doubt
we can enumerate all of them.  The text I proposed
for i061 [1] actually
goes one step further and makes it clear that the
use of RM may
result in some behavior that people have not seen
before - again
providing guidance but not necessarily enumerating
all of the possibilities.

-Doug

[1] http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200601/msg00145.html
Note - this is a revised version of the text that
isn't in the issue list yet (hint hint)