Re: [ws-rx] Minimalist GetMessage proposal

[Christopher B Ferris <chrisfer@us.ibm.com>]

Paul,

Please see my comments inline below.

Cheers,

Christopher Ferris
STSM, Software Group Standards Strategy
email: chrisfer@us.ibm.com
blog: http://www.ibm.com/developerworks/blogs/dw_blog.jspa?blog=440
phone: +1 508 377 9295

Paul Fremantle <paul@wso2.com> wrote on 05/04/2006
11:13:28 AM:

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

How is this fault transferred to the client if there
is no Sequence?
Are you suggesting that when a request is received,
that merits a reliable
response that the SOAP node will check BEFORE the
request is processed
that a Sequence exists for the response? That certainly
seems like 
a change in the way that RM works to me. It also presumes
that the 
channel that processes the request is aware of a)
the MEP in play
(e.g. that the message is a request in a request/response
MEP) and that
the response is to be transmitted reliably. If this
were an asynchronous
request/response, then the processing required to
process the synchronous
request would certainly not be invoked. 

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

Huh?

> 3) If the response is not available then the server could return a
> terminate or close sequence to the client on the open backchannel.
> 
> 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.

In Doug's proposal, the getMessage merely serves to
open the back-channel.
Whatever message is pending to the endpoint is transmitted.

> 
> Paul
> 
> Matthew Lovett wrote:
> >
> > 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 
> 
> -- 
> 
> 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
>