Doug – I had in mind corner case(s)
where some messages were acked, but not delivered for some reason (their
processing failed, and no assurance that the fault was received), or where the
final Ack does not make it back (e.g. on a different connection of TS, and not
sent reliably…) .
In that case the final “out-of-band”
account would include { seqNums excluded from Ack/Final } + { seqNums non-delivered
}
But I agree that you can build a roughly
equivalent feature on top of Ack/final, given that receiving party still notifies
{ seqNums non-delivered}. (a good RMD could persist its final Acks until being
assured in some way that the RMS got it even after seq terminated).
Note: It seems to me that the “HighestMessageNbr”
(+ 1 to Chris on that) should be sent with every CloseSequence as well (not
just TS).
My example of application is not the best
one: the real benefit is full awareness of what is missing on the RMD party side,
which was almost achieved except for the final gap…
-Jacques
From: Doug Davis [mailto:dug@us.ibm.com]
Sent: Thursday, November 02, 2006
4:35 PM
To: Durand,
Jacques R.
Cc: Gilbert Pilz; Paul Fremantle;
ws-rx@lists.oasis-open.org
Subject: RE: FW: [ws-rx] PR Issue
22: concrete proposal
Not disagreeing but for this comment/scenario:
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.
I
would note that isn't this what close + Ack/Final is for? It doesn't
require an out-of-band
communication
- its part of RM. :-)
thanks,
-Doug
|
"Durand,
Jacques R." <JDurand@us.fujitsu.com>
11/02/2006 07:25 PM
|
|
To
|
"Paul Fremantle" <paul@wso2.com>,
Doug Davis/Raleigh/IBM@IBMUS
|
|
cc
|
"Gilbert Pilz"
<gpilz@bea.com>, <ws-rx@lists.oasis-open.org>
|
|
Subject
|
RE: FW: [ws-rx] PR Issue 22: concrete
proposal
|
|
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