[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: FW: [ws-rx] PR Issue 22: concrete proposal
Jacques I agree completely. Paul Durand, Jacques R. wrote: > Well, implicit in Section 2 (and also explicit when the spec states that > " ...It also enables an RM Destination to Deliver the messages it > Receives to the Application Destination in the order in which they were > sent by an Application Source,..."), > Is that this RM protocol will *enable* a form of contract with the app > layer, whatever it is. Having decided to remove detailed specification > of these contracts from this spec does not free the spec from its > enabling role. > > Certainly, everyone I know who has been using or planning to use > reliable messaging expects to leverage its mechanisms (at-least-once > protocol, etc.) to be able to notify in some way the app layer (either > Source or Destination or both) of a delivery failure - e.g. be it just > in a log. > > For the RMD to "not be able to do anything to fix it" is not the point. > Awareness is. The beauty of sequence numbers is that the RMD knows right > away what it missed - except for the gap at the end of a sequence, > unless you add the Last message marker, which is a very modest feature > I'd say. > > E.g. of potential application: at the end of a business day, receiver > party communicates out of band the list of sequenceID/sequenceNum it has > not received/delivered, to the sending party so that the latter knows > exactly what to resend next day. > > -Jacques > > > -----Original Message----- > From: Paul Fremantle [mailto:paul@wso2.com] > Sent: Thursday, November 02, 2006 3:43 AM > To: Doug Davis > Cc: Gilbert Pilz; ws-rx@lists.oasis-open.org > Subject: Re: FW: [ws-rx] PR Issue 22: concrete proposal > > 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]