W3C home > Mailing lists > Public > www-ws-arch@w3.org > January 2003

RE: Proposed text on reliability in the web services architecture

From: David Orchard <dorchard@bea.com>
Date: Thu, 9 Jan 2003 15:39:11 -0800
To: "'Assaf Arkin'" <arkin@intalio.com>, "'Champion, Mike'" <Mike.Champion@SoftwareAG-USA.com>, "'bhaugen'" <linkage@interaccess.com>, <www-ws-arch@w3.org>
Message-ID: <00a401c2b838$50660da0$0a0ba8c0@beasys.com>

Actually Assaf, I think you've hit on some real issues.  <aside> Seems
almost eerily like the RISC vs CISC CPU arguments.  Hmm, Intel (CISC?) seems
to be doing pretty well.  </aside>I think this text would be very useful to
capture.  I disagree with your definition of loose coupling - I think what
you are talking about is coarse-grained, not loose coupling - but that's not
important to this message.

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


> -----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 18:40:17 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:41:02 UTC