Re: FW: [ws-rx] PR Issue 22: concrete proposal

[Doug Davis <dug@us.ibm.com>]

"Gilbert Pilz" <gpilz@bea.com> wrote
on 10/31/2006 02:09:17 PM:
> {Sir, I am starting a new company called Reliable Package Delivery.
> For a premium fee, we will deliver packages to you completely 
> undamaged, but we refuse to tell you whether or not you received all
> the packages we were given which were addressed to you. Can I sign
> you up as a customer?}

Just a couple more comments on this example and on
this thread...

Let's say a certain AS sends 5 messages.  After
some point in time
the corresponding AD gets 5 messages and then asks
the RMD whether or
not it got all of the messages.  The following
answers are all valid:
1 - yes, as the RMD, I got all 100 out of 100.
2 - no, as the RMD, I only got 99 out of 100 - msg
100 is missing
3 - yes, as the RMD, I got 1 out 1 messages
4 - yes, as the RMD, I got 5 out of 5 messages

1 can be true if the sequence is being used for more
than one application.
2 can be true because there's no relationship between
the AS's unit of
work and the RM sequence so the RMD has no idea if
msg 100 is important or
not to this particular AD - so this info is pointless.
3 can be true if the RMS decides to send each message
in a new Sequence.
Unless we're doing InOrder delivery the RMS is free
to make this choice.
And even then there are ways of doing InOrder when
spanning multiple Sequences.
Related to this is the assumption that the AD can
ask for the status of a
particular sequence for its messages - and if there
are multiple sequences
then which one is it asking about?
4 can be true, and I bet this is the answer some people
are expecting, however
what if the messages were split across several sequences
- not all 5 of these
messages could be the ones related to this AD's unit
of work.  So, the RMD
saying it got all 5 messages could be totally useless
information w.r.t this
AD's messages.

Its these types of ambiguities that I'm concerned
about when we start to add
a new bit of information into the protocol and people
immediately want to 
use it to convey other information that isn't clearly
spelled out.  If we
were talking about having this extra info just as
an FYI for the RMD
(meaning its useless in all cases but when IncompletSeqBehavior=DiscardEntireSeq)
then that _might_ be ok, but we've already heard that
some people think it may
be useful to pass this information on to the application
- and that's when I
get concerned because its then becomes an interop
issue.

I would also point out that making the sending of
a Close/Terminate a MUST is actually
something that is almost totally unenforceable.  Not
that that alone means we 
shouldn't add it, but if we're talking about adding
a MUST I think we need to clearly
understand why.  I follow the logic that says
Close/Terminate MUST be sent when
IncompleteSeqBeh=DiscardEntireSeq because the protocol
can't complete its job
w/o the final bit of information (LastMsgNum) - this
is the one case where sending
a close/terminate is basically enforceable because
the RMS knows that the RMD will
not deliver any messages until it get this info.  But
when its set to all other
values the protocol can still do everything, and if
we can't rely on the RMS
ever sending a Close/Terminate then how can an RMD
impl ever use data that
may actually never be sent?  

In terms of this info being just an FYI to the RMD,
I question its value there too.
Given all of the possible responses I listed above
what can the RMD possible do with
this information?  The most obvious answer of
"well if there's a gap then
it can log it or call the RMS's admin and find out
what's up".  True, but I don't see
the point.  Take the case of msg 100 not being
received - what if the RMS decided
that its giving up trying to send it on that sequence
so its starting a new one
to see if the new sequence works better - and it does.
 So this gap in the original
sequence is actually ok and safe.  Should the
RMD have been concerned about it?
We just don't know.  Its really the RMS that
knows whether or not these gaps are a
problem and possibly which application needs to be
made aware of something going
wrong.  The best the RMD can do with this info
is treat it as an FYI, but nothing
more.

If people really want to use it for more then additional
things need to happen.
In particular I think the RMS and RMD need to have
some additional hand-shaking
so that there is a common understanding of how the
Sequences are going to be used.
For example, making a 1-1 relationship between the
app's unit of work and the
Sequence. Without these additional things, IMO, all
bets are off and you get the
ambiguities in the possible RMD responses I listed
above which to me means we're
adding something that screams immediately of interop
issues.

thanks
-Doug