Coupling generally refers to the act of joining two things together, such as the links in a chain. But in software development, coupling typically refers to the degree to which software components/modules depend upon each other. The degree to which components are linked defines whether they operate in a tightly coupled relationship or in a loosely coupled relationship. With tightly coupled components, each component and any auxiliary dependent objects must be present at execution time as well as compile time. On the other hand, loosely coupled components can operate independently from one another.

Learn more about service-oriented architecture

For an introduction to the service-oriented approach to architecting Web Services, check out the first installment in this series.

Compile-time coupling
Couplings are creating in software development when a developer uses normal programming techniques to relate one or more components to each other. For example, when a C or C++ developer includes an external source file in another source file, a coupling is created. Every import or include statement represents a coupling between the current class or file and the class or file being imported. The following snippet demonstrates this.
#include <externalstructs.h>
#include “externalprocs.h”
void doSomething(MyStruct* aStruct) {


In the snippet, we see two lines that import external files. The first statement includes a file named externalstructs.h. We will assume that the struct MyStruct is defined in this file. The second statement includes a file named externalprocs.h. We will assume that the procedure dumpStructContents is defined in this file.

Since the snippet is written using C language, all code dependencies are created at compile time, known as early binding. The compile-time dependencies created in the snippet form a very tight coupling, since any changes made to the structure of MyStruct or to the signature of dumpStructContents forces the file containing doSomething and the file containing dumpStructContents to be recompiled.

Runtime coupling
Coupling also occurs when two interacting components need to exist in the same processing space at runtime. This type of coupling stipulates that deployment of one component depends on the presence of the other.

A coupling of time occurs if one component makes a request to another component at runtime and the calling component must wait for the called component to return a response. This time coupling, known as a synchronous call, can cripple an application if a particular process may take more time than the caller can afford. Asynchronous calls provide a mechanism to decouple the components in relationship to time.

Keep that coupling loose
Not all coupling is bad. In fact, all nontrivial programs require some coupling. But coupling becomes problematic when it limits the ability of the application. These limitations might show up in development, testing, and deployment of the application. For most applications, minimizing the coupling between components of the application provides far-reaching dividends.

Loosely coupled components locate and communicate with each other dynamically at runtime as opposed to a static compile-time binding. This is often referred to as late binding. It allows a loosely coupled application to be deployed as desired, without the limitations that tight coupling imposes. The right deployment decisions can be made at deployment time, rather than having to design in how the application will be deployed at the outset of development.

Another way to decouple components of an application is to remove the coupling associated with request/response expectations. This can be done with asynchronous applications. Not all applications can afford time decoupling, but this powerful technology provides huge benefits for those applications where immediate response is an unrealistic expectation.

SOA ensures loose coupling
Service-oriented architectures (SOA) provide built-in mechanisms to facilitate loose couplings between services and other components of an application. SOA ensures that the service is decoupled from other components in location, protocol, and time.

Location transparency
Services must be location transparent. In other words, they must be able to be located anywhere and then be discovered and used by other components or applications dynamically. SOA provides a mechanism for location transparency using service registration.

A service is generally registered with a public or private registry, such as a database, a directory service, a UDDI registry, or an XML file. Once a service is registered, components that want to call the service may use the registry to locate the service and then call the service. The registration and discovery of the service is enabled through the SOA platform in a manner that releases the service from the need to know where or how it has been deployed.

Protocol independence
Services are also protocol independent. That is, they operate in the same manner regardless of what protocol was used to communicate with them. A service does not know or care what protocol is used to communicate with it. The communication protocol support is provided by the SOA platform. The protocol may be a language, XML, standard-based, or something else entirely, but the point is that the service is developed independently of the communication protocol. The SOA can add new communication protocols and be confident that the service can continue to be used by new and different clients without affecting the service itself.

Time independence
Services may be called synchronously or asynchronously. Since a service need only worry about performing domain-specific business logic, it can do its job without concern for how it is being called or used by other parts of the application. This ensures that the service may be reused in new and different applications that need the same business logic. Perhaps one application will use the service synchronously, while another uses it asynchronously. To the service it does not matter.

Examples of loose coupling in an SOA
Jini is a Java implementation of an SOA. Jini provides a platform to build applications using a federation of services that provide the desired functionality. Clients use the Jini platform to find a service via a lookup service, which allows the two components (the service and the code calling the service) to be location transparent. The Jini platform handles where the services are located, so that neither the service nor the code calling the service needs to know where they are.

Another example of how SOA provides loosely coupled benefits is with Web services. Web services represent an increasingly popular SOA methodology for deploying services, enabling location transparency by utilizing registries such as UDDI for runtime discovery. Clients can locate the desired service dynamically by requesting the service from the registry. The Web services architecture provides benefits of loose coupling by providing a mechanism to locate, bind, and call the service dynamically.

Web services allow service developers to implement services using any programming language such as Java or .NET. Web services clients communicate to the service using SOAP, which is XML over HTTP. In addition, Web services developers need not worry about wire-protocol issues since the SOA platforms handle these issues for them.

Building and deploying applications using a service-oriented architecture provides an environment for loose coupling between components. The benefits of loose coupling include location transparency, protocol independence, and time independence.