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
- From: "Gilbert Pilz" <gpilz@bea.com>
- To: "Doug Davis" <dug@us.ibm.com>
- Date: Wed, 1 Nov 2006 16:34:58 -0800
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
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]