ws-rx message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Re: [ws-rx] Minimalist GetMessage proposal
- From: Matthew Lovett <MLOVETT@uk.ibm.com>
- To: Paul Fremantle <paul@wso2.com>
- Date: Thu, 4 May 2006 12:00:24 +0100
Hi Paul,
I don't think that this proposal is
complete without some discussion of outbound/offered Sequence lifetimes.
I guess it is always OK to Terminate/Close the outbound sequence without
affecting the offered one - and doing this allows the inbound messages
to keep flowing until the client has all its replies. However, if the offered
sequence is Terminated/Closed before the outbound one then I'm not sure
what the service should do - if it knows there should be a reliable reply
should it fault the message on arrival at the RMD, or should it allow it
to be processed and discard the reply message(s)?
On a similar vein, it is always possible
for the client to send Close/Terminate for the outbound sequence to the
server (after all, it can address the server), but the Server cannot send
Close/Terminate messages to the client. In the case where the server _must_
Close/Terminate the offered sequence, how should it inform the client?
By faulting the next outbound message with a Sequence Closed/Terminated
fault for the offered sequence?
How is the 2-way CloseSequence/CloseSequenceResponse
interaction supposed to happen for the offered sequence? Does the CloseSequence
flow on a getMessage HTTP response flow, and the Response go out on a new
HTTP flow from the client? (The same question applies to the other 2 way
interactions.) Also, is the getMessage HTTP response flow allowed to contain
a Sequence fault?
Of course, if you link the two sequences
then there is less need to handle some of the above.... but that would
have to be explained instead.
Matt
Paul Fremantle <paul@wso2.com> wrote on 03/05/2006
20:05:26:
> Based on some of the discussions it seemed to me that it could be
> valuable to produce a completely "minimalist" GetMessage
proposal.
>
> This is a new proposal that is based on the previous WSO2 proposal.
>
> The proposal removes the MessageID selector in the GetMessage - relying
> on simply getting whatever message the server sends back next.
>
> Also it removes the section 4.2. Effectively section 4.2 is an
> optimisation: for example to support unreliable-in/reliable-out a
client
> could do a createsequence+offer and never use the outgoing sequence.
In
> this case there is an overhead, which 4.2 aimed to remove, but this
> simplifies the proposal by focussing on the bare minimum required
to
> support the most common use cases, but still allowing the other use
case
> with a slight overhead.
>
> I've also included a sample message flow which I hope helps understand
> the proposal and show the general usage.
>
> Paul
>
> --
>
> Paul Fremantle
> VP/Technology, WSO2 and OASIS WS-RX TC Co-chair
>
> http://feeds.feedburner.com/bloglines/pzf
> paul@wso2.com
>
> "Oxygenating the Web Service Platform", www.wso2.com
>
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]