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