RE: Proposed text on reliability in the web services architecture

I don't know if any of you have looked deeply into the concensus problem in
distributed systems, although we did touch on the topic of the generals
problem at some point in time (seems like ages ago).

There's a whole class of distributed algorithms that attempt to address
reliability by defining the system as a composition of automata that is
based on exactly two operations: read and write. State transitions are
client derived. The client uses a read operation to determine the current
state, and a write operation to change it to a new state, with guarantee
that the same write given the same initial state would always result in the
same terminal state (in other words, all actions are idempotent).

These algorithms are very well researched, there's a big body of work
dealing with them, and you will find some of them used in distributed
systems (including <insert-self-promotion-to-my-product-here/>) as a way to
solve the reliability problem (aka concensus in the face of failure). The
more we progress with this discussion the more it seems to overlap with this
class of algorithms.

I didn't get that from the definition of REST since REST is more about GET
leading to a GET leading to a GET. Which as I pointed out does not map well
into how actual business applications are designed and imposes some
impractical constraints as a requirement for a the-one-and-only
architecutre. (It does, however, provide the optimal solution for that
portion of the application that is designed to work that way to begin with,
and in my opinion in no way contradicts with the use of SOAP or HTTP POST).

But we've long since digressed from the original scope of REST and tried to
extent it to address a different problem space. When we get to the point of
talking about PUT 50% of the time, we actually talk about the same
problem/solution as the one addressed by these distributed algorithms.

A lot of the comments made with regards to the HTTP GET/PUT approach so far
seem to mirror these algorithms, though for the most part I would say that
the discussion has ignored some of the safety mechanism that is required for
reliability, such as round identifiers and failure detection.

Just pointing out that this discussion could be elevated if we could look at
what was already researched/done rather than trying to re-invent the wheel.
Personally, I have actually implemented this stuff and I think it's superior
to traditional coordination protocols in its ability to address failure.
There's a whole class of use cases where you would want to use these
algorithms, and definitely a good learning opportunity for the WS community.

arkin

> -----Original Message-----
> From: www-ws-arch-request@w3.org [mailto:www-ws-arch-request@w3.org]On
> Behalf Of Mark Baker
> Sent: Thursday, January 09, 2003 8:51 AM
> To: Champion, Mike
> Cc: www-ws-arch@w3.org
> Subject: Re: Proposed text on reliability in the web services
> architecture
>
>
>
> On Thu, Jan 09, 2003 at 09:07:31AM -0700, Champion, Mike wrote:
> > OK.  How about proposing some text that makes the case for the RESTful
> > approach to reliable applications (as opposed to reliable
> messaging), and
> > noting whatever downsides you care to admit.  I'm sure the rest
> of us will
> > think of a few more :-)
>
> Ok, something short and sweet like;
>
> "Web services that wish to inherit the properties of the REST
> architectural style, can achieve a degree of reliability without the use
> of some or all of the features of a reliable messaging facility.  For
> example, if the service was to make its data accessible via PUT (an
> idempotent method), then clients can simply reinvoke the method should
> it not be clear if the previous message was successful or not.  For
> non-idempotent methods such as POST, some of the expected features of
> a reliable messaging facility could be reused; specifically, a message
> identifier mechanism."
>
> > > BTW, a quick comment about WS-Reliability.  It contains a
> > > "To:" header,
> > > which appears to bump head first into issue 2;
> > >
> > > http://www.w3.org/2002/ws/arch/2/issues/wsa-issues.html#x2
> >
> > I don't follow.  It appears to RESOLVE issue 2 by specifying a SOAP
> > extension mechanism for identifying the target of a message. "Bump head
> > first into" sounds like it is a Bad Thing.
>
> I can't find the discussion about it, but I remember the question of
> whether that was a good idea or not came up.  The title of the issue
> seems to reflect that.
>
> I personally consider it a bad thing, yes (am I that predictable? 8-)
> I believe that when using HTTP, the only authoritative place for the
> "target URI" should be the HTTP request line.
>
> Sorry, I didn't mean to distract from work on the reliability text with
> this sidebar.
>
> MB
> --
> Mark Baker.   Ottawa, Ontario, CANADA.        http://www.markbaker.ca
> Web architecture consulting, technical reports, evaluation & analysis
>

Received on Thursday, 9 January 2003 18:08:26 UTC