Loosely Coupled Dimensions [Updated]

Share the article!

Tim Bray has a entry on good WebServices practices. Interestingly enough, most of his recommendations are all loosely coupled. That is he recommends, “pass messages”, “use xml” and “asynchrony”.

This reminds me, I’ve added two new entries to the Loosely Coupled table.

The first addition is on transactions, that is a pessimistic locking strategy is more tightly coupled than a optimistic compensation based strategy. The former assumes every participate be in perfect lock step synchrony, the later attempts to perform reconciliation only when necessary.

The second addition in on the concept of classification, Classes assume that reality can be classified into neatly defined categories, Prototypes on the otherhand classfies the world based on what instance an object resembles. Prototypes are more loosely coupled in that the commitment to a classification scheme is done dynamically (i.e. delayed commitment).

Finally, I updated the coordination row to instead describe more familiar instances of central versus distributed coordination. The closest thing I can think of for distributed coordination is a market based approach, however obviously there are others. I’m sure that there’s been a lot of study devoted to the characteristics of designing a distributed coordination protocol. On the other hand, maybe I should have used Robert Milner’s Hierarchical Design versus Heterarchical Phenomena classification.

  Tight Coupling Loose Coupling
Interface Class and Methods REST like (i.e. fixed verbs)
Messaging Procedure Call Document Passing
Typing Static Dynamic
Synchronization Synchronous Asynchronous
References Named Queried
Ontology (Interpretation) By Prior Agreement Self Describing (On The Fly)
Schema Grammar Based Pattern Based
Communication Point to Point Multicast
Interaction Direct Brokered
Evaluation (Sequencing) Eager Lazy
Motivation Correctness, Efficiency Adaptability, Interoperability
Behavior Planned Reactive
Coordination Central Command Driven Market Driven
Contracts By Prior Agreements, Implicit Self Describing, Explicit
Transactions Pessimistic Optimistic
Classification Classes Prototypes

Apparently, Dale Asberry has found my table to be worth of his attention in his piece “why is distributed so hard?“. He points out the human factors that influence the solution. My one liner reason though is “distribution is hard because achieving consensus is equally hard”. In clear terms, build your systems with the expectation that people will never agree on anything.


Share the article!

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>