Re: [ws-rx] Minimalist GetMessage proposal

[Matthew Lovett <MLOVETT@uk.ibm.com>]

Hi Paul,

Thanks for the replies, I have another
set of comments inline. (Blimey, the list is busy today! Could it be that
we are making progress?)

Paul Fremantle <paul@wso2.com> wrote on 04/05/2006
12:09:23:
> Matt
> 
> Thanks for the detailed feedback. Excellent points.
> > 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. 
> Yes I agree.
> > 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)?
> If the case is req-reply and the reply is ready, then it could be
> returned on the backchannel (like the first echorequest in my example).
> If the response is delayed or there is more than one response then
it 
> seems to me these should just be thrown away. After all the reliability
> guarantee is now over (as the sequence is closed). If RM was not present
> these would be thrown away, so that seems logical.

I'm not very happy with that approach. The client
may not know that the offered sequence has been terminated. If the server
 decides to unilaterally terminate the offered sequence, and has not
yet had the opportunity to inform the client, then the client will believe
the reliability guarantee is still in place. If that happens, and a new
message arrives, I'd expect a fault to flow back on the transport backchannel,
and I would not expect the message to be processed.
Following that reasoning, even when the server has
attempted to inform the client about the termination of the sequence, it
should not assume that the client received that information. The only time
that it is safe to continue processing request messages is when the server
has received a Terminate/CloseSequenceResponse from the client.

If that were a blanket rule (no processing of inbound
messages unless we are certain that the client knows that the offered sequence
is no longer accepting new messages) then we are quite close to linking
the sequences anyway. If it is not a blanket rule, and only applies to
inbound messages that generate reliable replies, then we require the server
side to know the MEP.

I can imagine building an integration hub, with a
single RM-capable entrypoint. The messages could then be analysed, transformed,
targeted, whatever... and replies can be fed back to the client. Such a
hub would probably be serving a variety of client types, including ones
that fall into this scenario. (A firewalled laptop connected to a salesman's
mobile phone springs to mind.) I believe the entrypoint to the hub should
not have to know the MEP for each operation, it should just be a traffic
cop.

I think that Doug's proposal is a cleaner, more complete
solution to the issue at hand. You have done a good job of narrowing your
solution down, but even here the tricky stuff is lurking.

Thanks,

Matt