Re: [ws-rx] Minimalist GetMessage proposal

[Paul Fremantle <paul@wso2.com>]

So what you are saying is that in Doug's proposal the following will happen:

1.The client initiates a sequence+offer.
2.Sends messages...
3.Server closes/terminates the Offered sequence.
4.Client sends a message. A response message is now due back to the client.
5.The server spotting there is no open sequence creates a CS to the 
client, and somehow associates the waiting message with the as yet 
not-open sequence.
6.So the CS is waiting for the client to GetMessage it. The server is 
now buffering the CS message under the EPRId and the remaining responses 
messages under the "sequence".


Firstly, the client may refuse the CS message. In this case the messages 
are now undeliverable. Does that mean that the server should have 
faulted on the earlier responses? Too late now.
Secondly, it isn't clear why the server closed the offered sequence in 
your scenario. If it has run out of storage then there is no guarantee 
that it can buffer the CS message, or that it can be buffering messages 
against a sequence it is planning to create.
Thirdly there is no definition in the spec of what the status of these 
messages that are being held in the hope of creating a sequence. As 
Chris pointed out quite often in the early days of the TC, the whole 
design of this spec is that RM takes place *under the context of a 
sequence*. This was the argument why the implicit CS was removed. In 
your case that isn't true because the server cannot be sure the CS will 
succeed until after it has decided whether to buffer the messages or 
fault. So I think to be strict you would probably have to implement the 
same behaviour as I have proposed.

So in summary I don't believe that IBM proposal is actually any more 
solid in this scenario. Like you say there is plenty of tricky stuff 
lurking.

Paul

Matthew Lovett wrote:
>
> Hi Paul,
>
> I've tried to answer your questions, below:
>
> Paul Fremantle <paul@wso2.com> wrote on 04/05/2006 16:13:28:
>
> > Matt
> >
> > I don't agree - perhaps not surprisingly. If the server closes the
> > offered sequence, then there are three choices what to do.
> >
> > 1) If there is a policy in place saying that the response should be
> > reliable and there is no open sequence to the client then the server
> > should fault back to the client and raise a fault locally.
> > 2) If the response is not necessarily reliable (i.e. the policy or
> > config allows either) and the response is ready, then the server should
> > return the response unreliably. At this point the clients might spot
> > this and GetMessage to the server and get back a fault.
> > 3) If the response is not available then the server could return a
> > terminate or close sequence to the client on the open backchannel.
>
> Well, 1 and 2 sound like valid choices, but I'm a bit confused by 3. 
> Assuming this is a new request (not a replay), will the message be 
> dropped as well as returning the terminate/close, or will it be sent 
> for processing? I'd assume the latter is a bad idea, as we know that 
> the offered sequence is closed, so any reply is stuck. Perhaps the 
> logic of 1 and 2 comes back in here?
>
> >
> > Perhaps you'd like to explain to me what would happen in this case 
> using
> > Doug's proposal because its not at all clear to me.
> >
>
> Doug's case allows the server to establish new sequences to the client 
> as and when it chooses (modulo a transport connection giving it a 
> opportunity to send the create sequence message). That means that 
> there really is nothing special about the offered sequence, and if the 
> offered sequence is no longer the one that the server wishes to use 
> then it can set up another.
>
> So, for the case I was discussing (where the server side has needed to 
> terminate the offered sequence and the client does not know about the 
> failure yet) I think we have no problems. The client can send new 
> requests and the server can go on and process them and the messages 
> can be transferred back to the client (who we can assume will come 
> knocking, as she isn't the one with the problem).
>
> Did I manage to explain that clearly? Hope so!
>
> Matt

-- 

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