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

RE: Loose coupling is like pornography

From: Assaf Arkin <arkin@intalio.com>
Date: Thu, 9 Jan 2003 17:49:39 -0800
To: "Hao He" <Hao.He@thomson.com.au>, "'Mark Baker'" <distobj@acm.org>, "'Champion, Mike'" <Mike.Champion@SoftwareAG-USA.com>
Cc: <www-ws-arch@w3.org>
Message-ID: <IGEJLEPAJBPHKACOOKHNOEEGDAAA.arkin@intalio.com>

> Here is my attempt at defining loose coupling. Coupling is the dependency
> between interacting systems.  Dependency can be classified as real
> dependency and artificial dependency.  Real dependency is the features or
> services one consumes from other systems. Artificial dependency
> is the thing
> one has to follow in order to consume the features or services provided by
> other systems. Typical artificial dependency in IT are: language
> dependency,
> platform dependency, API dependency ...
>
> There are two rules here:
> 1. One can never reduce real dependency but itself is evolving.
> 2. One can never get rid of artificial dependency but one can reduce
> artificial dependency or the cost of artificial dependency.
>
> Hence, loose coupling describes the state when artificial
> dependency or the
> cost of artificial dependency has been reduced to the minimum.

I like this definition a lot!


> So, to really compare between REST and SOAP, we just need to look
> at compare
> the artificial dependency and the cost introduced by them.

Let me speculate. REST advocates would point out that in REST the only
artificial dependency is HTTP itself, while in SOAP you have both HTTP and
SOAP. SOAP avocates will argue that using TCP without HTTP has even less
artificial dependency, but since SOAP is becoming ubiquitous, this is a
non-factor.

REST advocates would then point out you don't need to know anything about
the structure of the message so the artificial dependency is lower. WSA
advocates would point out that in practice you do need to know the structure
of the message (or at least machines do, we humans don't), and since the
problem they are addressing (machine understanding) requires that, they
would consider REST and SOAP to be equivalent.

REST advocates would then point out you only need to know four methods: GET,
PUT, DELETE and POST. SOAP advocates would point out you only need to know
two methods: GET and POST. REST advocates would point out that all you need
is a URI, SOAP advocates would point out that it's a message encoding issue,
XML vs URI makes no difference, and besides it's URL not URI. URLs are not
loosely coupled.

REST advocates would point out that you can expect an operation to have
specific semantics based on the method name, SOAP advocates would point out
not having to manage the individual state transitions of the service
actually reduces coupling.

REST advocates would then point out that you can only build REST
applications using REST, while SOAP advocates would point out that if you
loosely couple the model from the underlying protocol you can actually build
REST applications using SOAP.

REST advocates would then explain how you put a queue in the middle to
decouple the services, SOAP advocates would point out that you need to know
there's a queue, so the SOAP approach is more loosely coupled.

Deadlock?

arkin

>
> Thoughts?
>
> Hao
>
Received on Thursday, 9 January 2003 20:50:32 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 3 July 2007 12:25:12 GMT