A Pattern Language for Loose Coupling

Common consensus is that to build systems that scale, in both performance and complexity, that the attribute of being Loosely Coupled is essential and even mandatory. Loose Coupling is ubiquitous in successful systems, unfortunately it is equally elusive in that we have difficulty finding a good definition for it. One can look at almost every definition of SOA and you will find Loose Coupling as part of that definition.

That's one reason why the term SOA is so vacuous, it's defined on something we don't have a good definition of. I would even go out on a limb to say that Loose Coupling is what defines and enables SOA. That is, if you want to successful in identifying structures that support the agile enterprise then you best be familiar with Loose Coupling rather than subscribing to a set of SOA principles.

In the absence of a succinct definition for Loose Coupling, I've decided to define it by enumeration. That is using design patterns. A design pattern is "a named nugget of insight that conveys the essence of a proven solution to a recurring problem within a certain context amidst competing concerns". Here's the collection of named nuggets of insights that I've stubled upon in my travels:

1. Publish and Subscribe - When a server does not care to know who the clients are.
2. Pull Messaging - When the capabilities of clients are not known in advance. Clients own control flow.
3. Reactive Behavior - When one can’t predict the order of messages that are received by a server. Servers react to events.
4. Explicit Conversational State - When a server isn't required to remember a previous invocation.
5. Cloned State Machine - When concurrent states are required without the use of a central controller.
6. Crash Only - When simple recovery is easier than complex prevention
7. Non-Blocking Promise - Respond with a provisional response.
8. Store and Forward - When we care only that a message is sent.
9. Recruiter - When you need to find a server that can best fulfill a task.
10. Rendezvous Point - When you need a starting point for finding services.
11. Idempotent Endpoints - How do you ensure that the work done by one server does not conflict with others?
12. Sturdy References - How do you make resources that survive the lifetime of processes?
13. Coarse Grained Invocation - When you need to minimize conversation. That is, communicate everything in a single round trip.
14. Delayed Commitement - When options are kept as long as practical and a commitment is made at the last possible moment.
15. Explicit Contracts - When information on how to use a service is required to prior to communication.
16. Self Describing Messages - When the structure of a message is discovered on demand.
17. Semantic Markup - How does one define formats that is both human readable and machine readable?
18. Peer Discovery - When maintaining a global directory of information may be prohibitively expensive or time consuming.
19. Trampoline - How do you maintain the context of a conversation without reserving a centralized resource to maintain conversational state.
20. Integration at the Glass - Services should be composable at the edge.
21. Reputation Based Governance - Distributed governance by identifying a currency that is valuable for all participants.
22. Prototype Based - When its unclear as to how to classify the objects in the system.
23. Queried References - Decouple location in space by providing attribute based searches rather than direct naming.
24. Uniform Interfaces - Allow parties to start a conversation without needing to first negotiate how to converse.
25. Extension Points - When new functionality needs to be added to an existing system without breaking future additions.
26. Behavioral Acquisition - Allow servers to augment existing services by acquiring functionality from other services.
27. Behavioral Injection - When an object graph is annotated to allow for it to augmented with additional behavior and structure at a future time.
28. Provisional Knowledge - How does one ensure that one can correct mistakes in the future?
29. Decentralized Indexing - One can't assume the indices or references to entities can be update atomically
30. Federated Administration - Global rules sometimes are suboptimal for a local context.
31. Lazy Evaluation - Decouple the problem definition from problem solver.
32. Optimistic Transactions - Delayed resource commitment and lazy reconciliation of inconsistencies leads to more flexible coordination of resources access.
33. Versioning - Allow clients to continue to be served by deprecated services.
34. Paper Trail - A new participant in a conversation needs to discover the current context of a conversation to be able to participate.
35. Object Remodularization - When the representation of an object is selected based on the needs of a consuming agent.
36. Dynamic Typing - When the messages that an object can respond to is determine only at the time of invocation of that object.
37. Pattern Matching - When an agent's execution requires only a subset of the requested communicated data.
38. Market Driven Distribution - Use a form of currency to control resource allocation.
39. Over Booking - When it is difficult to accurately forecast the demand for a limited resource.
40. Leased Resources - How do you ensure that unused distributed resources are garbage collected?
41. Roaming Agreements - How do you provide seamless interconnectivity across multiple systems?
42. Proposals - Documents to encapsulate negotiations.
43. Render Executable Markup - How do you ensure protection simultaneously with flexibility?
44. Verb as Proper Nouns - Employ names as a conduit for a proposed action.

It definitely is a long and exhaustive list, but I'm still on the look out for more of them. I'm also in the process of consolidating the list and identifying some overarching structure. In future posts I'll document these patterns in more detail. However, please do let me know other patterns that you may have encountered.