ws-rx message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Re: [ws-rx] Minimalist GetMessage proposal
- From: Christopher B Ferris <chrisfer@us.ibm.com>
- To: Matthew Lovett <MLOVETT@uk.ibm.com>
- Date: Thu, 4 May 2006 19:25:03 -0400
+1
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
Matthew Lovett <MLOVETT@uk.ibm.com> wrote on
05/04/2006 09:36:00 AM:
>
> 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
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]