ws-rx message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: RE: [ws-rx] i061 proposal / directions
- From: Doug Davis <dug@us.ibm.com>
- To: ws-rx@lists.oasis-open.org
- Date: Mon, 23 Jan 2006 23:30:39 -0500
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)
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]