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