Re: FW: [ws-rx] PR Issue 22: concrete proposal

[Paul Fremantle <paul@wso2.com>]

Doug

I agree. I don't think the spec should be concerning itself with any RMD 
to AD communications other than our vague notion of "delivery".

Paul

Doug Davis wrote:
>
> To me our disagreement actually comes down to this one line you wrote:
>  If either (a) or (b) is false the Sequence is incomplete and the RMD 
> MAY signal the AD that "not all the messages have been received".
> If you had said that the RMD MAY wish to log it or something like that 
> then I wouldn't be
> going on with this thread - this new feature would be just an 
> interesting bit of extra info
> for the RMD to have around.  But when you start talking about it being 
> useful to something
> above the RMD (like the AD) then we have a problem because I believe 
> that in order for
> it to be interpreted in an interoperable way we would need to get into 
> defining what LastMsgNum
> means w.r.t. the AD semantics.  For example, which AD does it notify? 
> Does it notify it
> even in cases where the app's messages spanned multiple sequences? 
>  How would the
> RMD even know this?  Perhaps I should just ignore that you said that 
> and assume your
> final proposal won't mention it.  :-)
>
> thanks
> -Doug
>
>
> "Gilbert Pilz" <gpilz@bea.com> wrote on 11/01/2006 07:34:58 PM:
>
> > Comments inline with a <gp> . . .
> >  
> > "Gilbert Pilz" <gpilz@bea.com> wrote on 10/31/2006 05:48:07 PM:
> > > Doug,
> > >  
> > > Forgive me if I am not understanding you correctly, but are you
> > > saying that it is a requirement that the AS and AD must be
> > > unaffected by their use of WS-RM? If so, this is the first time I
> >
> > Nope, just saying adding RM is adding a QoS not adding new application
> > semantics. If you could be assured that all of your messages would
> > arrive at the AD w/o RM then RM adds no value - meaning you could turn
> > it off and everything would still work.  And your AD would still need
> > to know that after a certain number of messages that one of those 
> would be
> > 'the last one' - how would it know that?  However this determination
> > is made w/o RM should still be done when RM is turned on.  While its
> > obviously possible for an implemenation and the RM layer to communicate
> > (as you suggest below) to share lots bits of information, as far as
> > the current RM spec is concerned that's all out of scope.  
> >  
> > <gp> You are simply asserting that "receivers knowledge of success"
> > is an application-level concept and not a QoS concept. That's one
> > possible definition (a bizarre and completely counterintuitive
> > definition, but a definition nonetheless). A more common and widely
> > understood meaning of "reliable messaging" would include "receivers
> > knowledge of success" as a QoS-level concept.
> >
> > > have heard such a requirement put forth. It seems like a rather
> > > strange requirement. I've always imagined that, if I were writing
> > > (or re-factoring) an application to use WS-RM, there would be a
> > > number of things I would do differently. For example, I probably
> > > wouldn't bother with any sort of retry/resend logic on the 
> client-side.
> >
> > Yes because the current RM spec is designed to handle this logic for
> > the application.  Unless we get into defining a relationship between
> > the RM's Sequence lifecycle and the application's 'unit of work'
> > I don't see how we can even head down the path of defining a new
> > bit of data (like lastMsgNum) that can be advertised for anything
> > more than to satisfy the IncompleteSeqBehavior semantics.
> >  
> > <gp> The "application uses RM to communicate a unit of work" is a
> > strawman use case that has only ever been advanced by you. I want to
> > be clear that I am not championing this use case as the reason for
> > putting LasMsg functionality back in the spec.
> >  
> > Here's a use case that I am more comfortable with: I'm running a B2B
> > hub with tens or hundreds of trading partners. I have a management
> > tool to keep track of how my trading partners are doing with regards
> > to sending me messages. Things like "when was the last time they
> > sent a message to the hub" and "how many messages did they send in
> > the last 24 hours?" I would also like to know if any of the TPs has
> > had problems in getting messages to me. I don't think I'm being
> > unreasonable if I expect my reliability QoS solution to tell me
> > if/when some messages aren't getting through.  
> >
> > > There could be any number of reasons that an RMD might wish to know
> > > that it has not received all of the messages in a Sequence. It might
> >
> > Actually I think the RMS would want to know it more than the RMD
> > since the RMD can't do anything with the information that something
> > went wrong.  Remember, I claim the AD would already know this even
> > w/o RM.
> >  
> > <gp> Obviously the RMS has to know if there are messages that didn't
> > make it through. What we're arguing about is whether the RMD should
> > be allowed to figure this out as well. I'm saying that, even in
> > cases where the AD has no knowledge of how many messages its
> > supposed to receive, it may be important for the RMD to figure out
> > that something went wrong. You keep saying that the RMD "can't do
> > anything". If you mean "the RMD can't proactively do anything to
> > receive messages once they are lost" I agree with you, but that's
> > only half of the overall problem. Logging an error, sending an
> > event, etc. are just as important as any other part of this
> > protocol. I want WS-RM to smooth over temporary infrastructure 
> problems and
> > tell me when it fails to do so.
> >
> > > wish to log it, raise an alert, attempt some diagnostic procedures,
> > > or (*gasp*) inform the AD. Some rules:
> >
> > Ah, here's the issue - would the AD need to know that the Sequence
> > is incomplete or would it need to know that not all of the messages
> > were delivered?  These are two different things.  I claim that the
> > AD shouldn't necessarily care about the RM Sequences but instead
> > wants to know if all of the messages got there.  And, if RM is just
> > a QoS then there must already be some other logic within the 
> application
> > message for the AD to know whether all of the messages have been
> > processed - just as if RM were not turned on.  You're suggesting that
> > the application can only do its job if RM is turned on and I don't
> > agree with that.
> >  
> > <gp> Could you clarify the distinction you are drawing between
> > "incomplete Sequence" and "not all of the messages were delivered
> > (did you mean received?)"? To me a "complete Sequence" (from the
> > RMDs perspective) is one in which (a) the RMD as received all
> > messages numbered 1, 2, . . . n (where n == LastMsgNumber), (b) the
> > RMD has received either a CloseSequence or a TerminateSequence. If
> > either (a) or (b) is false the Sequence is incomplete and the RMD
> > MAY signal the AD that "not all the messages have been received".
> >
> > > 1.) WS-RM cannot specify how or even *if* the RMD should inform the
> > > AD that it detected an incomplete sequence.
> > >
> > > 2.) A WS-RM implementation that chooses not to communicate the
> > > completeness/incompleteness of a sequence to the AD should still be
> > > considered as conforming to WS-RM (all other things being equal).
> > >  
> > > 3.) If I write an application that depends upon a particular
> > > implementation of WS-RM to inform me that some of the messages sent
> > > by the client didn't make it through, I must accept the fact that my
> > > application may not port well to WS-RM implementations that don't
> > > provide this functionality.
> > >  
> > > The main point is that if you don't consider LastMsgNumber to be
> > > useful, you are free to implement an RMD that *ignores* it. We
> > > happen to think it is a useful idea, and we don't think requiring
> > > the RMS to add this information to TerminateSequence (and/or
> > > CloseSequence) places an undo burden upon anybody.
> >
> > As I said, I'm ok with adding it - I think we're just disagreeing
> > over whether Close/Terminate becomes required with all values of
> > IncompleteSequenceBehavior because I only see it being needed for
> > one of them.  So, we're probably not that far apart.
> >  
> > <gp> I think the value of IncompleteSequenceBehavior is largely
> > irrelevant. True, you can't implement DiscardEntireSequence properly
> > without some form of last message indicator but, to me, that is a
> > minor point. The main point is that the RMD has to be able to detect
> > when some of the messages in a Sequence didn't make it through.
> > Other people assert that its important for the RMD to be able to
> > determine exactly which messages didn't make it through. I'm not
> > willing to go that far, but if it's important to them and doesn't
> > cost me anything more in terms of complexity or infrastructure, I'm
> > willing to go along with them.  
> >
> > thanks,
> > -Doug

-- 
Paul Fremantle
VP/Technology and Partnerships, WSO2 
OASIS WS-RX TC Co-chair

http://bloglines.com/blog/paulfremantle
paul@wso2.com
(646) 290 8050

"Oxygenating the Web Service Platform", www.wso2.com