OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

ws-rx message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: RE: [ws-rx] i089 - a revisted proposal

No, that is exactly what I meant to say. Remove RM from your example, keep anon, and you still can't get the response. 

Of couse add polling and you can. But that is my point, your example, and thus your proposal as well as this issue generally, have nothing to do with a problem particular to RM.

-----Original Message-----
From: "Doug Davis" <dug@us.ibm.com>
To: "ws-rx@lists.oasis-open.org" <ws-rx@lists.oasis-open.org>
Sent: 4/27/06 12:34 PM
Subject: RE: [ws-rx] i089 - a revisted proposal

  could you reword your 2nd para (the "The only conclusion..." one) I'm a 
bit lost.    Did you mean to say "can" instead of "can't"  ??

"Marc Goodner" <mgoodner@microsoft.com> 
04/27/2006 03:03 PM

Doug Davis/Raleigh/IBM@IBMUS, <ws-rx@lists.oasis-open.org>

RE: [ws-rx] i089 - a revisted proposal

When I look at your sample message flow on page 3, if I remove RM from the 
equation what I see is a one way in message and a one way out message that 
need to be correlated (presumably with wsa:RelatesTo) to form a complete 
req-resp MEP. 
The only conclusion I can draw from that is that you can’t get the 
response (the one way out) with an anonymous uri for the replyTo on the 
request (the one way in) whether or not RM is involved. 
So why is this a problem for RM to solve?
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: Thursday, April 27, 2006 7:49 AM
To: ws-rx@lists.oasis-open.org
Subject: [ws-rx] i089 - a revisted proposal

Based on feedback we've received I've attached an updated proposal for 
i089.  The basic idea is still the same but I think we've cleaned things 
up quite a bit and eliminated some of the confusion that some people 
thought the old proposal introduced.  This one is pretty small and still 
addresses all of the use-cases we've heard about.  The biggest change is 
that we've made it more clear that GetMessage is designed to simply 
(re-)establish a transport-specific back-channel, nothing more. 
(sorry, no cute poem :-) 

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]