Re: Proposed text on reliability in the web services architecture

> I think we've already established that RM tries to solve a very specific
> problem. I don't want to keep discussing RM in every possible scenario,
> because I don't have any evidence you will need to use it in every
possible
> scenario. I haven't used RM in every single application, only in those
> applications that need it. I don't want it to sound like I'm preaching
what
> I don't practice.

That certainly makes sense. I'd be interested in hearing about some
web services applications that used RM and how that worked.

>
> And since we both agree RM doesn't make all your problems go away, I don't
> want to keep discussing it in the context of a "the one and only
solution".
> I know some people would like to think they have "the one and only
> solution". Experience has taught me that for every problem there is a
> solution, and even if you can find the one and only solution for a
specific
> problem, it's still not "the one and only solution".

Agreed.  Certainly not "the only one".  As to whether it can be "the
one" (meaning something sufficiently general to be widely applicable),
or even "the few" ... this is where I still have reservations.  Just so you
know where I'm coming from.
>
> So I want to refocus the discussion with the following permise:
>
> - Consider the use of RM for applications that need RM and ignore
> applications that do not need RM
> - Consider the use of RM to solve the reliable messaging problem and don't
> discuss the use of RM to solve any other kind of problem

I'm interested in analysis of WS applications that "need RM".


> > > Now, if I send/receive multiple messages then TCP solves the packet
> > problem
> > > by making sure each message is either full or ignored, but it doesn't
> > solve
> > > the multi-sequence message problem. So you need something on top of
TCP
> > > whenever multiple messages are involved.
> >
> > What is the multi-sequence message problem?
>
> I send a service two messages m and m', where m' can only be processed if
m
> has been processed. I am using an asynchronous means for delivery, which
> means message loss is possible. (If I'm not using asynchronous delivery
I'm
> not using RM and so I don't really care what an RM would or would not do)
>
> From the perspective of the service it is futile to process m' before it
> processes m. The message m' will simply be rejected. But, it is also
futile
> to reject m' if m could arrive after m'. (Which is possible if we counter
> message loss with retransmission). So, if the messaging layer receives m'
> followed by m, then delivers m followed by m', the service can process
both
> messages.
>
> Incidentally, TCP does just that. That why when you are downloaing you may
> see 1KB, 2KB, pause, 5KB. Because packets 3-4 arrived before packet 5, but
> once packet 5 has arrived the browser gets all three packets at once. It
> reduces network congestion. But TCP works at the packet level and here we
> are talking about messages.

I'm truly sorry to keep quibbling over these examples, but it seems
confused.  Above you're saying TCP doesn't correct sequencing, and
here you saying it does.  If I send two messages on the same
tcp connection, they will come out the other end in the same order as
sent, or not at all.  Notwithstanding the fact that _message_ boundaries
and _segment_ boundaries can be different.  Right?

The reason I quibble about this is that if you need RM atop a TCP
connection, and RM and TCP are congruent* as processes dealing
with ordered segments on a network, then by a sort of crude induction,
you can justify an arbitrary number of "needed" layers of this sort of
thing.  Do you see my concern?  And an architecture's job is to sort
out this kind of tangle.

* meaning that structurally and operationally they are doing
   the same job, perhaps under different names


> > Is the ordering constraint optional?
>
> The ordering constraint should be imposed by the application based on the
> application needs. Otherwise you get an RM that is really good for some
> things, but a bit too heavy for others. That's actually a point I raised
> regading WS-Reliability, I think it offers strict ordering and that's too
> heavy for some applications.

I agree with you.

> But to get that service the client can't get into the details of the
> protocol. All it could know is how to open a connection, how to close the
> connection, how to determine if the connection is open, and receive errors
> when the connection dies in the middle of sending a message (unless the
> stack recovers so there's no application error).

Interestingly, you're coming close to a point I was trying to make
earlier.  That our intention is to reduce the complexity the client has
to deal with.  The reality is that much of that just gets pushed off
into another bubble, like "how to determine if the connection is open",
deciding whether it's in a state that will support "connect", or one
that will support "send" or "recv".  Et Cetera.  The intention to hide
complexity and the reality of it being different things.  I don't doubt
the intention, ever.

>
>
> >
> > Or even twenty or thirty.  I've developed lots of frameworks, probably
> > so many because of the fact that one size did not fit all. 8-(
>
> Ever heard of one-size baseball hats?
>
> Think of RM as a baseball hat. It protects you from the sun, so you
probably
> want to wear it on a sunny afternoon baseball game, but you don't really
> need it at night or when you're sitting at home watching TV. And if you
wear
> just a baseball hat you won't be allowed into any baseball stadium, in
fact
> you will be arrested for indicent exposure.
>
> It's probably not a good allegory, but I'm trying to look at different
ways
> to express the fact that an RM is a solution not "the solution", so
judging
> it as "the solution" is not a good approach to evaluating its benefits.

You know, you just made me realize that "one size" products, if
that's really what they were, could only work if the client was willing
to change to fit them. ;-)

I'm assuming you have a collection of problem cases you're using
for this evaluation?

> There are three ways to prove that a solution is worthless:
>
> 1. Look at the problem and discover that the solution does not solve it
> 2. Look at a different problem and discover that the solution does not
solve
> it
> 3. Look at a bigger problem and discover that the solution does not solve
> all of it

Point taken.  What about the flip side of the coin?  What are some
of the ways of asserting, incorrectly, that X is "a solution"?  In terms
of an architecture, what should be the criteria for disallowing these?

Thanks,
Walden

Received on Monday, 20 January 2003 18:38:33 UTC