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



"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.

> 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.

> 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.

> 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.

> 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.

thanks,
-Doug



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]