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] MessagePending


Doug Davis wrote:
> 
> Would we always be able to know it though?  When the MessagePending 
> header flows as a result of the MakeConnection there's a "query 
> expression" associated with the MakeConnection.  In cases where the 
> message on the transport request flow was not a MakeConnection then I'm 
> not sure what value the server would use to determine if there are 
> messages pending - i.e. what "query expression" would it use to do the 
> check?  Interestingly enough, I have been recently wondering if we could 
> use the wsa:From header for this purpose.  If a one-way message was on 
> the transport request flow, and since its a one-way there was no 
> response, could the server look at the wsa:From, and if it used the RM 
> anon URI, use that as an optimized MakeConnection?

Can you elaborate on this?

What/which information in the pending messages can the server use to 
figure out which message to send, if the sender identifying information 
is in the wsa:From of MakeConnection?
If only wsa:To was an EPR (sigh).

-Anish
--

>  In other words, does 
> wsa:From identify the sender?  WSA would seems to say 'yes'.  This could 
> save the overhead of another message exchange in some cases.  Good thing 
> WSA didn't kill wsa:From like they were thinking.  :-)
> 
> thanks,
> -Doug
> 
> 
> 
> *Paul Fremantle <paul@wso2.com>*
> 
> 10/05/2006 06:32 PM
> 
> 	
> To
> 	"ws-rx@lists.oasis-open.org" <ws-rx@lists.oasis-open.org>
> cc
> 	
> Subject
> 	[ws-rx] MessagePending
> 
> 
> 	
> 
> 
> 
> 
> 
> Rereading the spec around MakeConnection, I realize that we defined
> MessagePending as only applicable on a message flowing back on a
> MakeConnection backchannel. It seems to me that we could usefully add
> this message in cases where a response is flowing on a back channel.
> 
> For example. Suppose I have an interaction
> 
> 1. GET1 ----->
> <---- RESPONSE1
> 
> 2. GET2----->
> (response lost)
> 
> 3. GET3----->
> <------RESPONSE3
> 
> In 3, the Get will have an ack for response1, and the server can
> indicate that response 2 is missing.
> 
> We already have logic to decide when piggybacking of acks is
> appropriate. I believe the logic could be extended to decide when it was
> ok to send back a MessagePending header:
> 
> * In the sequenceID case, it would be appropriate whenever the message
> being sent back was part of the same Offered response sequence.
> * In the URI case, it would be appropriate whenever the replyTo URI
> matched the MessagePending URI.
> 
> Paul
> 


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