Loosely Coupled Dimensions [Updated]
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|
|Ontology (Interpretation)||By Prior Agreement||Self Describing (On The Fly)|
|Schema||Grammar Based||Pattern Based|
|Communication||Point to Point||Multicast|
|Motivation||Correctness, Efficiency||Adaptability, Interoperability|
|Coordination||Central Command Driven||Market Driven|
|Contracts||By Prior Agreements, Implicit||Self Describing, Explicit|
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.
Last modified 2004-05-04 06:10 AM