Coupling is one of the most fundamental measures of “quality” for an information system. The concepts of coupling and cohesion appear in software design best practices for at least a couple of decades. And these concepts are also vital to the development of distributed systems. As core as the concept of coupling is, it is difficult to find a real definition in the distributed systems context. Coupling is like obscenity – we can’t define it, but we know it when we see it.
Which is why I was pleased to see Ian Robinson’s post which presented coupling as lying on two dimensions – temporal and behavioural and even put in place some characteristics which helps you put a rough measure on the degree of coupling. Coincidently, I had drafted my own version of this some time ago, but it had never made it to publication.
Like Ian, I was trying to quantify coupling so that we can understand what constitutes a tightly or a loosely coupled system and we can have some approach to measure it and therefore have a method to decide between design trade-offs in satisfying the various requirements of our distributed systems. While Ian presents a conceptually clean two-dimensional picture, I felt the true story involves multiple interacting dimensions.
While I was researching this, I happened to find a book extract which covers what I wanted to say and more. The full extract is well worth reading, but is summarised in the following table:
Level | Tight Coupling | Loose Coupling |
Physical coupling | Direct physical link required | Physical intermediary |
Communication style | Synchronous | Asynchronous |
Type system | Strong type system (e.g., interface semantics) | Weak type system (e.g., payload semantics) |
Interaction pattern | OO-style navigation of complex object trees | Data-centric, self-contained messages |
Control of process logic | Central control of process logic | Distributed logic components |
Service discovery and binding | Statically bound services | Dynamically bound services |
Platform dependencies | Strong OS and programming language dependencies | OS- and programming language independent |
Here we have no less than seven dimensions to the coupling equation.
The final paragraph of this article highlights the costs of loose-coupling (and only some of the benefits).
However, in most cases, the increased flexibility achieved through loose coupling comes at a price, due to the increased complexity of the system. Additional efforts for development and higher skills are required to apply the more sophisticated concepts of loosely coupled systems. Furthermore, costly products such as queuing systems are required. However, loose coupling will pay off in the long term if the coupled systems must be rearranged quite frequently.
I think this understates the benefit. “Rearranged frequently” seems to only cover design-changes. But it should also cover “runtime rearrangement” such as partitioning across redundant components for the purpose of load-balancing and fault-tolerance. In such cases, “loose-coupling” provides significant value in higher uptime and scalability of distributed systems.
Update May 14, 2009: Richard Veryard has pointed me to his paper “Component Based Service Engineering” (subscription required) which discusses an even wider range of coupling beyond the technical layers into Process, Organizational and Business layers. The CBDi Wiki has a table summarizing all the coupling dimensions identified in Richard’s paper.
One section of the paper struck a chord with me:
How can we have loose coupling and hard-wiring at the same time? The answer comes as soon as we recognize that coupling is multidimensional or multilayered. My head is connected (coupled) to the rest of my body in several different ways. Even if I could introduce some technology to decouple the nervous system, that doesn’t allow me to remove my head….With Web Services, SOAP simply removes one set of the hard-wired connections. Other forms of coupling remain.
This was written in 2003 and proves quite prescient in that many SOA projects in the interim have failed to achieve their goals by simply adopting out-of-the-box “web services” which only address one or two of the many dimensions of coupling.
2 comments ↓
There are several other dimensions of coupling/dependency, as I identified in my article for the CBDI Forum in November 2003 (predating the Enterprise SOA book).
Full article (subscription required) http://www.cbdiforum.com/secure/interact/2003-11/comp_based_srv_eng.php3
Extract (no subscription) http://cbdi.wikispaces.com/coupling
Hi Richard, thanks for pointing this out to me. I’ve updated the post in response.
Leave a Comment