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, thus abstracting volatility.

This is in contrast to compile-time or runtime binding, which requires that you bind the components at compile time or runtime (synchronous calls), respectively, and also requires that changes be designed into all components at the same time due to the dependencies. As you can imagine, this type of coupling makes testing and component changes much more difficult.

The advantages of loosely coupled architectures, as found within 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 were 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 goes for persistence layers, middleware, protocols, etc. You can mix and match to exactly meet your needs, even leverage services that may exist outside of your organization without regard to how that service was created, how it communicates, nor where it is 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 should not 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, 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 the dependencies are critical to the design. An example would be two services that can't work apart and must function as one, and thus are better tightly coupled. You have to look at your requirement, and then determine the degree of coupling required in your architecture, and it may not always be loose coupling.

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 into a few basic patterns: location independence, communication independence, security independence, and instance independence.

Location independence refers to the notion that it matters not where the service exists, the other components that need to leverage the service can discovery it within a directory and leverage it through the late binding process. This comes in handy when you're leveraging services that are consistently changing physical and logical locations, especially services outside your organization that you may not own. Your risk calculation service may exist in LA on Monday and in New York on Friday, and it should make no difference to you.

Dynamic discovery is key to this, meaning that calling components can locate service information as needed, and without having to bind tightly to the service. Typically, these services are private, shared, or public service as they exist within the directory.
Communications independence means that all components can talk to each other no matter how they communicate at the interface or protocol levels. Thus, we leverage enabling standards, such as Web services, to mediate the protocol and interface difference.
Security independence refers to the concept of mediating the difference between security models in and between components. This is a bit difficult to pull off, but necessary to any SOA. To enable this pattern, you'll have to leverage a federated security system that's able to create trust between components, no matter which security model is local to the components. This has been the primary force behind the number of federated security standards that have emerged in support of a loosely coupled model and Web services.

Instance independence means that the architecture should support component-to-component communications, using both a synchronous and asynchronous model, and not require that the other component be in any particular state before receiving the request, or the message. Thus, if done right, all of the services should be able to service any requesting component, asynchronously, as well as retain and manage state no matter what the sequencing is.

The need for loosely coupled architecture within your SOA is really not the question. If you have a SOA, you should have a loosely coupled architecture, if done correctly. However, analysis and planning are also part of the mix...understanding your requirements and how each component of your architecture should leverage the other components of your architecture. With a bit of up-front work, you'll find your coupling loose and your SOA successful.