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:52:38 -0500
Duane,
yes, its the latter. Yes
I agree its a dup but the question is what should the response be? a
202? the response that was previous generated? What if the response
that was previously sent was lost - would seem to imply that a 202 would
be wrong - and the RMD needs to send the response message - or at least
do so until the response is acked. But then what's the response to
another dup request? Now is it a 202? And what should the client
do with that 202? 202 feels like an odd response since it could mean
so many things, but mainly it means just "Accepted" - would an
RM-specific "already sent you the response" message be more appropriate?
And in these cases (202 or some other response) should it assume
that some other retry thread already got the response? probably. But
what about non-ExactlyOnce DAs? Does that change things at all? Dunno.
Maybe not. I may have already answered my own question with
all of this rambling, but the point isn't that some of these questions
can't be answered but rather I'd like to see the proposed textual changes
for the spec so that readers will not need to ask these questions themselves.
The more we talk about this the
more I'm thinking that we're leaving our RM space and entering into WSA's
:-(
thanks,
-Doug
"Duane Nickull"
<dnickull@adobe.com>
02/21/2006 02:24 PM
|
To
| Doug Davis/Raleigh/IBM@IBMUS,
<ws-rx@lists.oasis-open.org>
|
cc
|
|
Subject
| RE: [ws-rx] [i089] a revised
proposal |
|
Doug:
Can you be more specific on
point #3? Do you mean a message arrives after timeout value has been
exceeded for a legally constituted sequence or a message arrives after
the RMD has send an ack for it? If it is the latter, the late arriving
message would simply be a duplicate (unless the RMD had ESP) and could
just be dropped, could it not? Perhaps I am missing the meaning.
Funny how on the surface it
all seems to simple.
D
*******************************
Adobe Systems, Inc. - http://www.adobe.com
Vice Chair - UN/CEFACT http://www.uncefact.org/
Chair - OASIS SOA Reference Model Technical Committee
Personal Blog - http://technoracle.blogspot.com/
*******************************
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]