RE: Loose coupling is like pornography

hi, Assaf,

See my comments within.


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

<hh> Great! Editors, can we put this into the WSA document? </hh>


> 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.

<hh>Didn't understand the logic here.  SOAP always has more artificial
dependency here. </hh>

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.

<hh>It is not always true that one always needs to know the structure of the
message. In fact, for
different consumers/handlers, each of them only needs to know the part they
need to know.  So, the
problem is do we require consumers/handlers to know all the structure up
front or at their choice. 
With SOAP, one needs to know SOAP up-front. With REST, it does not prevent
you from knowing the structure and it offers you the choice of not knowing
the structure. It appears REST wins this round.</hh>

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.
<hh>I agree that you only need to know GET and POST so the REST Artificial
Dependency (AD) is even lower. I don't agree that all you need is a URI.
XML is far superior to URI encoding.  Since XML 
technology is universally available, the XML AD cost is lower than URI
encoding. </hh>

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.
<hh>If you don't put any semantics on the method name at all, the overall
cost of AD will be actually
higher since everyone has to come up with their own semantics.  On the other
extreme, if you put all
semantics on the method name, you introduce too much AD (this is effectively
RPC). So, the middle 
ground is to put some generic semantics on the method name.  GET and POST
seems to be universally understood so the AD cost is low. </hh>

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.

<hh>I agree that you can build loosely coupled system from SOAP using the
document centric approach.
However, the question is whether it is more loosely coupled when compared
with an equivalent system built with REST. IHO, it is less. </hh>

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.

<hh>The queue should be invisible to consumers.  This is an AD introduced by
implementation, not by REST
itself. </hh>

Deadlock?

<hh>Not really. SOAP advocates can win if they can put some real values into
the SOAP header and therefore reducing the overall cost of SOAP AD. For
example, if doing reliable messaging is too difficult without SOAP, then one
would have to use SOAP. REST advocates can win if they can do similar things
simply using HTTP. If I can get reliable messaging for free in HTTP, why
should I bother with SOAP?  Currently, it is difficult to see what real
value SOAP really provides apart from doing RPC over HTTP (but we agree that
RPC is not loosely coupled). </hh>



Hao