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

["Gilbert Pilz" <gpilz@bea.com>]

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