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

Myth of Loose coupling

From: David Orchard <dorchard@bea.com>
Date: Fri, 26 Sep 2003 18:01:02 -0700
To: <www-ws-arch@w3.org>
Message-ID: <012501c3851f$be6cfd40$470ba8c0@beasys.com>

I'm posting a link as I was asked to before on the start of a discussion on
loose coupling.


I will say that I have come to have a somewhat revised view on loose
coupling.  I would say that loose coupling is a combination of properties:
- extensibility, so that additional information can be added without
breaking receivers
- evolvable changes in the interface, so compatible changes can be made.
- rapidity of changes in the interface
- on the web, the generic interface constraint, means that applications
(browsers/search engines) are not dependent upon each site's protocol.
- asynchrony, so that senders and receivers are decoupled in time
- stateless messaging, so that senders need fewer messages and hence less
chance of communication errors
- use of URIs for identifying resources.  This means that identifiers are
very constrained and easily transferred.
- No vendor specific or platform specific constraints on any of the
technologies used.

I think one can then say that loose coupling is a property that is a
combination of other properties as I've listed above.  And it seems that
changing each property/constraint increases the coupling.  For example, a
web service with no extensibility, that evolves rapidly in incompatible
ways, an application specific interface, synchronous, stateful messages is
tightly coupled with it's clients.

This would show that the Web is "mostly" loosely coupled because of the
extensibility/evolvability in http/html, slow changes in html vocabularies,
stateless messaging, vendor/platform agnostic.  Yet it is tightly coupled in
being synchronous.

Another way of looking at this is that Web service technologies do not per
se mean a service is loosely coupled, it is only through the application of
constraints to be loosely coupled.

Seem reasonable?

I think this notion of a "combination" property is similar to the visibility
property, which I argue is a combination of simplicity and percieved
performance properties.

Received on Saturday, 27 September 2003 13:48:35 UTC

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