ws-rx message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Re: [ws-rx] MessagePending
- From: Doug Davis <dug@us.ibm.com>
- To: ws-rx@lists.oasis-open.org
- Date: Sun, 8 Oct 2006 16:28:03 -0400
Yup. Since wsa:From has never
really been used much its a bit of an open question.
The good thing is that it is defined
as the "source endpoint" which is what we want.
The bad thing is that other specs have
been free to define when some of these various
headers should appear and what they
mean - so we could be bumping into someone
else's usage. If we could guarantee
that our usage of it was exactly what WSA intended
then we'd be ok - I think.
thanks,
-Doug
Paul Fremantle <paul@wso2.com>
10/08/2006 02:44 PM
|
To
| Doug Davis/Raleigh/IBM@IBMUS
|
cc
| Anish Karmarkar <Anish.Karmarkar@oracle.com>,
ws-rx@lists.oasis-open.org
|
Subject
| Re: [ws-rx] MessagePending |
|
Doug
This would be kind of cool, but I'm slightly concerned what impact it
might have on various implementations. The MakeConnection call primes
the RMD to "expect" a pending message on the response. But I'm
not
convinced it isn't doable. I'd like to get my implementation team's input.
Paul
Doug Davis wrote:
>
> Anish,
> I don't think I was clear. My pondering wasn't about
the
> MakeConnection message but rather about some other message - like
some
> application message. If the client just happens to be sending
a
> one-way to the server and there's no response (its a one-way) then
I
> was wondering if the server could use the wsa:From/wsa:Address value
> (if its set to RManonURI) to look for messages to send on that empty
> back-channel. Thus saving the overhead of the client having
to send
> another MakeConnection.
> thanks
> -Doug
>
>
>
> *Anish Karmarkar <Anish.Karmarkar@oracle.com>*
>
> 10/06/2006 01:51 PM
>
>
> To
> Doug
Davis/Raleigh/IBM@IBMUS
> cc
> ws-rx@lists.oasis-open.org
> 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]