RE: Proposed text on reliability in the web services architecture

 Recall that the SOAP and WSA attempt to be protocol-neutral. There is no
assumption that RM *is* atop a TCP connection; there may be different
protocols, there may be unreliable intermediary processes, there may be
caches that expire and authentications that fail and transactions that are
rolled back and on and on and on.  Clearly by making enough assumptions or
adding enough constraints we could come up with a scenario where RM is
pointless.  We can also come up with plenty in where it is useful.   

Again, it would be much more useful to identify alternative scenarios and
assess their architectural strengths and weaknesses than to propose one's
favorite scenario and argue that the others aren't strictly necessary, or to
argue that its' upsides outweigh its downsides, etc.  Deep down in this
thread there is a lot of good stuff, but it's really hard for the editors to
mine it out.



-----Original Message-----
From: Walden Mathews
To: Assaf Arkin; Peter Furniss; Champion, Mike; www-ws-arch@w3.org
Sent: 1/20/2003 6:38 PM
Subject: Re: Proposed text on reliability in the web services architecture


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:48:22 UTC