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] Minimalist GetMessage proposal



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]