Since the beginning of computing we've been dealing with the notion of coupling, or the degree to which one component is dependent on another component in both the domain of an application or an architecture. Lately, the movement has been towards loose coupling for some very good reasons, but I'm not sure that many architects out there building SOAs understand the motives behind this.

Breaking this concept down to its essence, we can state that tightly coupled systems/architectures are dependent on each other, thus changes to any component may prompt changes to many other components. Loosely coupled systems/architectures, in contrast, leverage independent components, and so can operate independently. However, it's not as simple as all that.

Keep in mind that how loosely or tightly coupled your architecture is is a matter of requirements, and not as much about what's popular. Indeed, architects need to understand the value of SOAs and loose coupling, and make the right calls to insure that the architecture matches the business objectives. So it's helpful to walk through this notion of coupling as you approach your SOA.

Hang Loose!
With the advent of Web Services and SOA we've been seeking to create architectures and systems that are more loosely coupled. Loosely coupled systems provide many advantages including support for late or dynamically binding to other components while running, and can mediate the difference in the component's structure, security model, protocols and semantics, thereby abstracting volatility.

This contrasts to compile-time or run-time binding that requires that you bind the components at compile-time or run-time (synchronous calls) respectively, and also requires that changes be designed into all components at the same time due to their dependencies. As you might imagine, this kind of coupling makes testing and component changes much more difficult.

The advantages of loosely coupled architectures, as found in many SOAs, are apparent to many of us who have built architectures and systems in the past, at least from a technical perspective. However, they have business value as well.

First and foremost, a loosely coupled architecture allows you to replace components, or change components, without having to make reflective changes to other components in the architecture/systems. This means businesses can change their business systems as needed, with much more agility than if the architecture/systems was more tightly coupled.

Second, developers can pick and choose the right enabling technology for the job without concerning themselves with technical dependencies, such as security models. Thus, you can build new components using J2EE, which will work and play well with other components written in Cobol or perhaps C++. Same thing goes for persistence layers, middleware and protocols. You can mix and match to meet your needs, even leverage services that may exist outside of your organization without regard for how that service was created, how it communicates, or where it's running.

Finally, with this degree of independence components are protected from each other and can better recover from component failure. If the SOA is designed correctly, the failure of a single component shouldn't take down other components in the system. Thus, loose coupling creates architectures that are more resilient. Moreover, this also lends itself better to creating a failover subsystem and moving from one instance of a component to another without affecting the other components in the SOA.

It should be noted, however, that not all tight coupling is bad. Indeed, in some cases it makes sense to more tightly couple components, such as when dependencies are critical to the design. An example would be two services that can't work apart, and must function as one, and so are better tightly coupled. You have to look at your requirements, and then determine the degree of coupling needed in your architecture, and it may not always be loose coupling.

Testing for Loosely Coupled Architecture
So, now that we know the basic differences between a tightly and loosely coupled architecture, as well as the advantages, perhaps it's a good idea to break down loose coupling in to a few basic patterns: location independence, communication independence, security independence and instance independence.