Is there a Preferred Axis for Loose Coupled-ness?

David Walend speculates about a spectrum of the loosely coupled-ness nature of architectures. He brings forward several questions. Are there other styles in the spectrum? Is this a valid view of them, or should I be thinking about something else entirely?

My hunch is that the answers to these question lies in understanding that "loosely-coupled-ness", that is the nature of being loosely coupled, involves several dimensions. Saying that there exists a spectrum is a bias towards a view that there is either only one axis or there's a preferred axis. Based on my earlier foray into this subject matter, I've determined that Loose Coupling is a multi-dimensional thingie and it's much clearer to view it from that perspective.

David Walend's entry lists a few architectures that gives me the perfect opportunity to exercise my theory against. He lists the following architectures, in the order of tighter coupling:

1. Dissociated Ubiquitous Services are Assembled On-the-fly by Discovery
2. Known Services are Assembled at Run Time by Configuration
3. Components are Integrated at Compile Time by Glue Code
4. Client-Server systems are integrated at Design Time by Well-Defined API

For brevity sake, please refer to the two pieces linked to above while reading this.

The on-the-fly discovery architecture described most aptly highlights the dimension of References that are queried as compared to the more tightly coupled named or even fixed references. Rather than hard-wiring connectivity via named references, attribute based queries are used to stitch together a system's configuration.

The configuration based and the component based architectures more resemble the dimension of Interface. The configuration architecuture implicitly assumes fixed interfaces that allows for easy wiring together (see single-port architecture), components on the other hand present a more complex interface and thus imply tighter coupling. Fixed interfaces allow for more ad-hoc configurations. Linking togther components is not as flexible however employing configuration at runtime is still an open possibility.

Finally, for the client-server architecture, which is a bit puzzling to me in that it's hard to see why it has tighter coupling than the configuration or component based architectures. Connectivity is based on configuration and SQL provides a kind of "fixed" interface. Something is just not right here, there's a reason why client-server in David's view is perceived to be more brittle to changes, and I plan to figure this one out!

Could what David means by configuration based be the same as the sample he cites, that is a message queue based system? Could it be that the lack of support of static checking makes changes more difficult because here's no automatic mechanism for checking for inconsistencies like a compiler?

My hunch is that the difficulty of making changes is due to the fact that interface between components are not explicitly defined in one place. SQL statements in a client-server system are typically interspersed over many places and code has an implicity coupling with the interspersed statements. However, this may all be due to the inadequacy of the implementation technology rather than the inherent architecture. There's nothing that prevents one from supporting maintability by modularizing one's code base, however there's also nothing in SQL-based development that encourages such modularization (aside from a good 0/R mapper).

In general, a relational database provides a fixed, queried, self-describing, lazy evaluated system that is inherently loosely coupled. It's surprising that it's perceived to be more tightly coupled than a component based system.

In summary, Loose Coupling in a system presents itself in different dimensions. To define a "spectrum" of loose coupled-ness requires one to consistently measure on the same axis. Looking at a one dimenstional projection of a multi-dimensional space and deriving some an order can lead sometimes lead to a whole lot of confusion.