Re: [ws-rx] Minimalist GetMessage proposal

[Doug Davis <dug@us.ibm.com>]

Paul Fremantle <paul@wso2.com> wrote on 05/04/2006
12:03:42 PM:
> 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".

EPRid is not in the current proposal.  
This is an impl choice - yes it can do it that way.
Or it can wait until
it tries to send the message on the wire before it
decides which seq to
use - in which case it would not know it needs to
send a CS until the
GetMessage comes in.  This is actually just like
async - the RMS can
decide when to decide what seq to use - if it does
it early then yes
it can buffer the CS, if it chooses to wait then it
doesn't.  Does your
proposal allow impls to choose?

> 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.

No different than the async world - goodness.

> 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.

Not our concern - there are lots of reasons why it
may choose to close
a sequence.

> 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 

Well, actually, I believe that the implicit CS was
removed for two reasons
1 - so some up-front security check can be done
2 - so that some very late arriving msg (resend of
msg#1) isn't treated
    as a new sequence/new msg

> 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.

Not sure I see the issue.  What happens when
a CS is lost in the async
world?  The RMS will either resend or give up.
 Why should we act any
differently here?

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