ws-rx message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: RE: [ws-rx] [i089] a revised proposal
- From: Doug Davis <dug@us.ibm.com>
- To: ws-rx@lists.oasis-open.org
- Date: Tue, 21 Feb 2006 14:17:04 -0500
Just to clarify something... we
too believe that the synchronous, anon, behind-firewall scenarios are very
important. But we don't want to hack-up (or worse, break) RM to try
to support them when there are solutions available that do enable those
scenarios to work without compromising RM. Keep in mind that all
of these scenarios are ones that people will want to solve even when RM
is not enabled. Ideally, any solution should basically work the same
with and without RM. But as I said, only time will tell... :-)
thanks,
-Doug
"Marc Goodner"
<mgoodner@microsoft.com>
02/21/2006 02:05 PM
|
To
| Doug Davis/Raleigh/IBM@IBMUS,
<ws-rx@lists.oasis-open.org>
|
cc
|
|
Subject
| RE: [ws-rx] [i089] a revised
proposal |
|
“If
we end up keeping Offer around just for the anon replyTo case (which I
believe you said is the main reason for keeping it),”
I think you downplay the
applicability of this to much, but that is understandable from an asynchronous
one-way queue oriented view of the world. From a synchronous req-resp view
being able to use RM with anon clients that are behind a firewall using
HTTP as a transport it is very common. I don’t understand why we would
want to restrict the spec so it couldn’t address that use case.
Similarly Offer may not seem
like much of an optimization for long running sessions from an async point
of view, but for short lived synchronous view of things it is an important
optimization.
I think the spec can address
both queue oriented on-way and synchronous req-repl implementations. The
changes that IBM is pushing for will restrict the latter, possibly even
prevent it, and I don’t understand the objective in limiting the spec
that way.
Your questions below are
good, thanks for compiling them. I’ll get something together today.
Marc Goodner
Technical Diplomat
Microsoft Corporation
Tel: (425) 703-1903
Blog: http://spaces.msn.com/mrgoodner/
From: Doug Davis [mailto:dug@us.ibm.com]
Sent: Tuesday, February 21, 2006 10:57 AM
To: ws-rx@lists.oasis-open.org
Subject: RE: [ws-rx] [i089] a revised proposal
I believe MSFT has the todo to go off and write down how anon ReplyTo is
supposed to work. In the last interop call we had there were quite
a few questions raised about how things should work and we need those addressed.
I believe some of them were:
How does the offered seq get shutdown? ie. how does the RMD send
a terminate back to the RMS?
How can the RMD close the offered sequence if it needs to?
What should happen when a late arriving (already ack'd) message arrives
at the RMD? What should the response be?
Can there be two sockets connected to the RMD at the same time and both
sending the same message? What's the response to in each case?
If request msg #2 is acked (back at the RMS) but response msg #2 isn't
acked (back at the RMD) how can the RMD resend it? I think its possible
that the RMS can get to a point where it received response msg #2 but the
ack for it was lost. So, RMS thinks all is well, but RMD doesn't.
Unless the RMS resends a message (but why would it when it thinks
all is well), then the RMD is stuck. Can't resend and can't close
the sequence.
What specific changes to the spec(s) do we ned to make to clear up these
issues?
If we end up keeping Offer around just for the anon replyTo case (which
I believe you said is the main reason for keeping it), but we can't explain
how anon ReplyTo is supposed to work without hacking up the protocol, I'm
not sure its worth keeping it - esp. not when there are other solutions
around that do allow these scenarios to work without messing up RM.
thanks,
-Doug
"Marc Goodner"
<mgoodner@microsoft.com>
02/21/2006 01:12 PM
|
To
| Doug Davis/Raleigh/IBM@IBMUS,
<ws-rx@lists.oasis-open.org>
|
cc
|
|
Subject
| RE: [ws-rx] [i089] a revised
proposal |
|
Only time? I think the scenario is pretty clear so what are the issues
with it you see that would prevent it from working?
If you are suggesting that you want to do interop on it first then are
you likewise suggesting that this issue (and I would infer i090) should
be deferred from being closed until then?
Marc Goodner
Technical Diplomat
Microsoft Corporation
Tel: (425) 703-1903
Blog: http://spaces.msn.com/mrgoodner/
From: Doug Davis [mailto:dug@us.ibm.com]
Sent: Tuesday, February 21, 2006 10:04 AM
To: ws-rx@lists.oasis-open.org
Subject: RE: [ws-rx] [i089] a revised proposal
Yea, I figured you'd say that :-) that's why I wanted the latest
text in the issue list. W.r.t. your assertion that anon replyTo can
work w/RM - only time (and your proposal) will tell :-)
-Doug
"Marc Goodner"
<mgoodner@microsoft.com>
02/21/2006 12:55 PM
|
To
| Doug Davis/Raleigh/IBM@IBMUS,
<ws-rx@lists.oasis-open.org>
|
cc
|
|
Subject
| RE: [ws-rx] [i089] a revised
proposal |
|
I can’t support this. I think some of the scenarios we have been discussing
around the use of Offer demonstrate that you can get a reliable response
back when using an anon wsa:ReplyTo value. I think the proposal would be
OK if the last sentence, beginning “Note” was struck.
Marc Goodner
Technical Diplomat
Microsoft Corporation
Tel: (425) 703-1903
Blog: http://spaces.msn.com/mrgoodner/
From: Doug Davis [mailto:dug@us.ibm.com]
Sent: Wednesday, February 08, 2006 9:31 AM
To: ws-rx@lists.oasis-open.org
Subject: [ws-rx] [i089] a revised proposal
For issue 089, I'd like to offer this revised proposed text (same basic
idea just different wording):
After line 441 of [1] add:
Messages sent using this protocol MUST NOT use a wsa:To value that would
prohibit the RM Source from retransmitting unacknowledged messages. For
example, using WS-Addressing's anonymous IRI, without any additional transmission
mechanism, would restrict an RM Source's ability to re-establishing a new
connection to the RM Destination when a re-transmission of a message is
needed. Note, that this implicitly impacts possibles values used
in other places - for example, in wsa:ReplyTo when responses are expected
to be transmitted reliably.
thanks,
-Doug
[1] http://www.oasis-open.org/apps/org/workgroup/ws-rx/download.php/16095/wsrm-1.1-spec-wd-08.pdf
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]