RE: Proposed text on reliability in the web services architecture

> But I could well be wrong ... and as Paul Prescod has noted, there's not a
> lot of conceptual difference between REST and DBMS programming
> where records
> get created, read, updated, and deleted, and where applications can't just
> blithely assume that everything will be magically taken care of by the
> infrastructure.  I don't want to exaggerate the difficulty, just
> note in the
> WSA that a) it's non-trivial; b) not widely understood; and c) not by any
> means the path of least resistance given todays tools.

Let's assume for the second that all SQL upates are idempotent. (Not
necessarily, but it simplifies the discussion) And SQL selects don't have
any side effects (not that I know of). So mapping SQL statements to HTTP
GET/PUT would make my database RESTful (correct?).

Persumably, if I expose my database as a Web service I could build a RESTful
service. And it will scale as well as the database does, which is not a bad
proposition (afterall most applications simply add overhead to the
database).

Now where did that loose coupling disappear all of a sudden?

In practice most applications achieve some level of loose coupling by
putting a middle layer between the client and the database. Instead of
performing database operations, the client performs application operations
which then become sequences of database operations. One you sequence a
select and an update, or two updates, with some logic, you're no longer 100%
idempotent. How much, I never bothered to measure. 20%? 40%? 60%

You don't have to do it. You can build a system out of a set of small
idempotent operations. I'm not going to prove this, but I'm going to believe
it's possible, certainly backs up my experience. But that means you're
shifting too much of the logic to the client side, and it requires too much
message passing to scale well. If Amazone was offering only idempotent
operations, I can tell you I wouldn't be using their services.

Another possibility is to develop the application without idempotent
operations, building really complex operations that don't map well to either
the GET or PUT semantics proposed, so the only option is to use POST. It
sounds like it doesn't scale. But the truth, it actually relieves a lot of
the pressure on messaging and constant validation, so in practice it
actually performs better. And it provides loose coupling.

Maybe you don't agree that using proprietary MOMs is loose coupling. But
that's precisely what many of these architectures try to solve by using
asynchronous message passing that causes GET/PUT to happen in the back-end
but does not map into a GET/PUT interaction. They are loosely coupled in the
sense that changes to the server implementation (E.g. using a different
database schema, introducing new constraints) do not affect the client.

They are not loosely coupled because they use binary protocols. But that's
easily resolvable by mapping their internal data structures into XML and
using SOAP over HTTP/SMTP/whatever.

I'm not sure I'm saying anything, I actually think I'm rambling and just
pointing to the obvious fact that this entire discussion is starting to go
around in circles.

arkin

Received on Thursday, 9 January 2003 18:29:00 UTC