RE: Proposed text on reliability in the web services architecture

Amen to that, brother.  By which I mean your statement, "Deep down in
this thread there is a lot of good stuff, but it's really hard for the
editors to mine it out."  As you know I made some efforts to summarize
the RM threads -- a long time ago when they were a lot simpler.  I
wouldn't even THINK about trying it now.  ("Don't try this at home, kids
...")

It seems to me that the people who have been participating in these
threads could do everyone a big favor by proposing simple and concise
statements of one or more points of view that might be starting points
for verbiage for the architecture document -- or a note from the WG or
whatever might be most appropriate.

-----Original Message-----
From: Champion, Mike [mailto:Mike.Champion@SoftwareAG-USA.com] 
Sent: Monday, January 20, 2003 5:48 PM
To: 'www-ws-arch@w3.org '
Subject: 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 19:05:26 UTC