Wanton coupling

The paradox of loose coupling is that it's never context-free. Whenever two services interact, there's always some common ground, some element of mutuality. It may be loose, but it's never wanton.

Jeff Schneider has been exploring some of the boundaries of loose coupling in his weblog recently. A couple of weeks back he wrote about The Suckline, a title that refers to the way that open interoperability in a service-oriented architecture depends on descending to a least-common-denominator of shared context: "When you need to create an ad-hoc computing platform and you don't know the capabilities of all of the participants you must choose only those capabilities that are guaranteed to be available across all nodes ... The suckline is the decision to use the lowest common denominator capabilities across participating nodes in order to [achieve] guaranteed communications." The suckline, by this definition, is the lowest level of shared context that still permits interaction.

But of course in an ideal world, no one wants to operate at the suckline — hence its name. So Jeff posits the notion that, "Web services are about protocol negotiation." The suckline becomes merely an opening gambit, an entry point that allows participants to discover their common ground and then step up to a deeper, more tightly coupled level of interaction: "If the protocol negotiation is done correctly you should be able to use a metadata-described invocation and interface description mechanism that is linked to a protocol policy for runtime resolution," which then allows the participants to step up to a "Greatest Common Factor (GCF)" level of interaction.

In his latest posting, Jeff moves on to discuss the related concept of Dynamic Coupling. He makes the very important observation that an architecture that has coupling designed into it can be coupled either at assembly time or at runtime, and that these two alternatives have different implications for the looseness of the configuration:

"When we discuss loose coupling or tight coupling, we must remember that there are different issues to consider:

1. The level of investment that was placed on enabling a component to be loosely coupled (e.g., it comes with a plug attached). [POTENTIAL COUPLING]
2. The decisions that the component assembler made when combining the piece components (e.g., they used the plugs everywhere vs. soldered them together everywhere vs. some combination) [ASSEMBLY COUPLING]
3. The option of delaying the assembly interface mechanism decisions to runtime. [DYNAMIC COUPLING]"

Jeff writes that "very little information is available on the concept of Dynamic Coupling," but nevertheless he leaps ahead and introduces a further concept, the notion of "Dynamic Decoupling," which in principle sounds very similar to an idea I've previously called Unplug and play: the ability to disconnect and reconnect on demand at assembly time, in response to the runtime requirement.

What Jeff is aiming to do here is to reconcile his desire for greatest-common-factor interactions with the ability to maintain the lowest-common-denominator requirement of interoperable loose coupling. I think his theory succeeds. The performance advantages of tight coupling require a higher level of commitment to shared context, but dynamic coupling allows that higher level to take place without sacrificing flexibility, precisely because it allows dynamic assembly and disassembly — the components can be unplugged after the coupling has taken place, restoring them at the end of the interaction back to their lowest-common-denominator loosely coupled status.

posted by Phil Wainewright 10:10 PM (GMT) | comments | link