OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ws-rx message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [ws-rx] Minimalist GetMessage proposal



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