RE: Proposed text on reliability in the web services architecture

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
"services"!

Cheers,
Dave

> -----Original Message-----
> From: [email protected] [mailto:[email protected]]On
> Behalf Of Assaf Arkin
> Sent: Thursday, January 09, 2003 3:28 PM
> To: Champion, Mike; bhaugen; [email protected]
> 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
>
>