RE: Proposed text on reliability in the web services architecture

> Another way to look at this, and I think this is similar to what you are
> saying, is that we know that doing fine-grained database or object access
> doesn't scale from a client or server perspective because of
> performance/latency issues.  So we put "business objects" in
> front of them.
> "Good" Web services do the same thing.  Hey, that's why we call them
> "services"!

That captures my point.

I'll avoid using the term coupling. But the more I look at it, the more it
appears that the REST solutions proposed require more visibility into how
the service actually operates and more messages to force it to operate the
right way. Which is not a bad thing, it just brings a certain level of
dependency that is not always beneficial, and sometimes require
deconstruction of what is already well abstracted.

How about 'too tightly knit'?

arkin

>
> Cheers,
> Dave
>
> > -----Original Message-----
> > From: www-ws-arch-request@w3.org [mailto:www-ws-arch-request@w3.org]On
> > Behalf Of Assaf Arkin
> > Sent: Thursday, January 09, 2003 3:28 PM
> > To: Champion, Mike; bhaugen; www-ws-arch@w3.org
> > Subject: 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 21:08:56 UTC