"Loose Coupling" (was: Re: REST, Conversations and Reliability)

I want to address this issue of "Loose coupling" from David's post of
several days ago:

David Orchard wrote:
> 
> ... Your
> proposal means that the application now has to deal with all the aspects of
> reliability, and reliability software has to know about the application.
> Tightly coupled.

"Loose coupling" is an important buzzword around web services (with good
reason). Therefore it is important to use it precisely. In my mind,
loose coupling is about the ability of message senders and receivers to
independently evolve. It has *nothing* to do with the level of
communication between layers of implementation of either the sender or
the receiver. In fact, the organization of these layers is a very minor
issue for the www-ws-arch compared to the much more important issue of
describing how to achieve loose coupling between independently deployed
web service nodes. Or to put it another way, but the sender and the
reciever could be monolithic blobs of Perl code and the system would
still be loosely coupled if the client and server can evolve separately.

I think that "mixing" reliability and application logic *improves* loose
coupling because it does not impose a particular reliability strategy on
the client. The only way I can imagine you "abstracting" out reliability
is to require the participants to agree on a particular underlying
reliable protocol (MQSeries, HTTPR). This is yet another agreement to be
negotiated. Furthermore, if this reliability layer ever fails, my
impression is that you are totally screwed. The measure of either a
security or a reliability solution should not be how powerful it is when
it succeeds but what happens when it fails.

"Any system that depends on reliability is unreliable."

    -- Nogg's Postulate
-- 
XML, Web Services Architecture, REST Architectural Style
Consulting, training, programming

Received on Friday, 16 August 2002 20:24:21 UTC