RE: [ws-rx] i061 proposal / directions

["Gilbert Pilz" <Gilbert.Pilz@bea.com>]

I have a technical problem with your proposal in that it presupposes the existence of an HTTP backchannel in the face of one-way operations over SOAP/HTTP. As we've discussed exhaustively, it is very likely that there will be no such backchannel in these cases. On the other hand, the RMS and RMD cannot simply forbid all use of the anonymous AcksTo based solely on knowledge of the underlying SOAP implementation because the application may engage in synchronous, two-way interactions which would provide a backchannel.

 

The only way out of this mess that I can see is to discourage the use of anonymous AcksTo unless something (the application or configuration or what have you) tells the RMS and RMD to allow it. I'll try to get a concrete proposal out this afternoon . . .

 

- g

---

From: Doug Davis [mailto:dug@us.ibm.com]
Sent: Monday, January 23, 2006 8:31 PM
To: ws-rx@lists.oasis-open.org
Subject: RE: [ws-rx] i061 proposal / directions

And more comments inline like <dug>this</dug>.
-Doug

"Gilbert Pilz" <Gilbert.Pilz@bea.com>

01/23/2006 08:33 PM

To	Doug Davis/Raleigh/IBM@IBMUS, <ws-rx@lists.oasis-open.org>
cc
Subject	RE: [ws-rx] i061 proposal / directions

Comments inline . . .

---

From: Doug Davis [mailto:dug@us.ibm.com]
Sent: Monday, January 23, 2006 4:01 PM
To: ws-rx@lists.oasis-open.org
Subject: RE: [ws-rx] i061 proposal / directions


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

[stuff removed]
   
> 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'm confused about which "developer" you mean. I am specifically thinking about the developer of the RMS and the RMD. How does she or he know when the use of anon AcksTo is problematic and what to do about it? There are obviously cases where it depends upon the "intentions" of the application. How should the RMS go about figuring out what/how the application intends to do its messaging?

I would be comfortable in saying that the RMS should never use the anon AcksTo unless it can ascertain that the application will be operating synchronously. How it does this (static configuration, the AS tells it somehow?) should remain unspecified. We should also explicitly state that the RMD should return the CreateSequenceRefused in response to a CreateSequence that contains an anon AcksTo unless it could ascertain that the application will be operating synchronously (method again unspecified (one can almost hear the pitter-patter of policy mice in the walls)).

<dug> I'm not really sure what to say here.  I guess I always assumed that the RMS would always have to have enough knowledge to pick a valid AcksTo EPR.  Whether it chooses (or is told) to use the anonymous URI or a non-anonymous URI it can't just make that decision without some thought being given to it.  To me this is no different than the decision of what wsa:ReplyTo EPR to use - it must choose the appropriate value for the environment in which it is being used.  So to me the most the RM spec should talk about is what might be "new" to someone using RM.  For example, the notion of piggy-backing of Acks.  Or the fact that two soap envelopes might be generated for one incoming soap envelope.  Those types of things aren't necessarily obvious to a newbie.  And related to that giving some guidance about what to do in those situations would be good - but I don't really think we need to say much more. </dug>

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.
 
Hmmm . . . I think its a pretty far reach between the obviousness of "none" and the juxtaposition of MEPs, SOAP versions, and HTTP binding implementations that make up this issue. I agree that we can't specify every possible EPR and situation that might cause problems, but it seems likely that many implementations will encounter this situation (perhaps I should say "it seems enormously likely that all but an insignificant handful of implementations will encounter this yawning chasm in our specification"?)

<dug>
If you can figure out a way to include "yawning chasm" in the spec w/o making it look gratuitous I'd +1 it !!  
I agree that this situation is very likely and that's why in my proposal I included more text and "for example" verbage than I would have normally liked.  I wanted to make it clear to the reader that there's something new going on here and they need to take notice.  Perhaps, I didn't do a good enough job of wording it but that was my intent.
</dug>

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.

I didn't see how/where the new proposal did this.

<dug> I have three "for example"s in the text each of which, IMO, go into the kind of detail I think you're asking for.  But perhaps we need to rewind a bit and l should ask if you're objecting to the technical resolution of this issue or if you're objecting to the wording I've proposed?  If we agree on what should happen when the anon AcksTo is used and we're just quibbling over the wording then I'm always open to textual changes - after all, I'm just a monkey and can't be expected to get it right on my own.  :-O
</dug>

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