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

[Doug Davis <dug@us.ibm.com>]

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