Service Oriented Architecture: Inventory of Distributed Computing Concepts

This chapter is from the book

Enterprise SOA: Service-Oriented Architecture Best Practices

Learn More Buy

This chapter is from the book

This chapter is from the book 

Enterprise SOA: Service-Oriented Architecture Best Practices

Learn More Buy

3.5 Tight Versus Loose Coupling

Recently, a lot of attention has focused on comparisons between loose coupling and tight coupling approaches to application interactions. On the technology side, this has mainly been driven by the potential of Web services to dynamically discover and bind to other services, such as through UDDI (Universal Description, Discovery and Integration). On the business side, this has been driven by the growing need of enterprises to increase flexibility with respect to changes in their own business processes and the ways in which they interact with partner companies.

Traditionally, business processes have been designed within the boundaries of an enterprise, or even within the different business units of the enterprise. These activities were managed with the help of detailed, real-time information. Processes that span multiple business units or enterprises typically have to deal with a very different set of requirements, needing a higher degree of flexibility. In these kinds of scenarios, one sees a much higher degree of uncertainty, a much more frequent change in terms of participants and their roles, and a constant evolution of the types of interactions required.

There appears to be a consensus that for these types of "in-flux" situations to operate, a loosely coupled architecture is required because loose coupling is seen as helping to reduce the overall complexity and dependencies. Using loose coupling makes the application landscape more agile, enables quicker change, and reduces risk. In addition, system maintenance becomes much easier. Loose coupling becomes particularly important in the B2B world, where business entities must be able to interact independently. The relationships between business partners often change rapidly—alliances are settled and cancelled, and business processes between trading partners are adopted to new market requirements. Two companies that are partners in one market might be competitors in another market. Therefore, it is essential that the underlying IT infrastructure reflect this need for flexibility and independence. Ideally, no business relationship should impact another—new business relationships should be able to be established without any effect on existing ones. Functionality that is offered to one business partner might not necessarily be available to others. A change that is relevant for one business partner should have no impact on other partners. One trading partner may not cause another to block while waiting for a synchronous response, nor may one IT system depend on the technical availability of the IT system of a business partner.

The term coupling refers to the act of joining things together, such as the links of a chain. In the software world, coupling typically refers to the degree to which software components depend upon each other. However, the remaining question is: "What are these dependencies, and to what degree can one apply the properties of tight and loose?" Software coupling can happen on many different levels. One of the first issues is to differentiate between build time (compile time) dependencies and runtime dependencies. However, this is typically only sufficient when looking at monolithic applications. In a distributed environment, we believe that in order to determine the degree of coupling in a system, one needs to look at different levels. Table 3-1 provides an overview of these levels and shows how they relate to the tight versus loose coupling debate.

Table 3-1 Tight Versus Loose Coupling

In the following, we will examine the items in Table 3-1 in detail.

For distributed systems, the way that remote components are connected is possibly the most obvious technical factor when looking at the problem of "coupling." A physical intermediary enables loose coupling on this level. Therefore, MOM systems are loosely coupled on the physical level, with message queues acting as an intermediary, decoupling senders and receivers of messages. RPC-style applications are tightly coupled on this level because clients and servers interact directly with each other—clients require servers to be alive and accessible in order to interact with them.

The impact of synchronous versus asynchronous communication on the level of coupling is often closely related to the physical linking of the distributed components, as described previously. Asynchronous communication is generally associated with loose coupling. However, this assumes that the underlying middleware is capable of supporting the asynchronous communication in a loosely coupled manner. Assume a one-way RPC call: There is still a notion of tight coupling here, even if the client does not wait for the reply of the server—the client will only be able to send the one-way request to the server if it is directly connected and if the server is up and running. This is a good example for the varying degrees of "coupledness"—asynchronous communication through a proper MOM is more loosely coupled than asynchronous one-way RPC calls.

Looking at the type system of a distributed application as the next level of "coupledness," we find that the stronger the type system, the stronger the dependencies between the different components of the system. This is true not only during the application development phase, but also (and perhaps more importantly) when changing or reconfiguring the running system. Earlier, we differentiated between interface semantics and payload semantics. Interface semantics provide an explicit interface and operation names and also strongly typed arguments. Effectively, this means components are tightly coupled together on this level because every change of an interface ripples through the entire application, as far as dependent components are concerned. The benefit is that we discover the affected parts of the application that need to be adapted to reflect these changes at compile time, thus avoiding runtime exceptions due to incompatible message formats. Payload semantics, on the other hand, enable a looser coupling of components because message formats are generally more flexible. In some cases, message format validation might be applied, such as through XML Schema validation. However, this requires efficient management of the up-to-date schema definitions between participants. Notice that the problems with changes to message formats is not eliminated by employing payload semantics: One must still know those parts of the system that are affected by changes in order to ensure that they can act appropriately on the new format. In many cases, this means that the problem has simply moved from build time to runtime.

Another important factor to examine is the interaction patterns of the distributed components. For example, an ORB-based system will typically impose an OO-style navigation of complex object trees. The client has to understand not only the logic of each individual object, but also the way to navigate across objects, again resulting in a fairly tight coupling. Given that RPC-style interfaces do not enable such complex navigation, the degree of coupling is lower when compared to a distributed object system. MOM-based systems typically impose a much simpler interaction model, where often a single queue is sufficient as an entry point for clients, and all input for server-side transactions is provided in a single message.

Related to this discussion is the question of whether we generally assume that the system is structured around RPC-style services or around queues and topics. Generally, topics and queues provide more flexibility for changing the system at runtime by rearranging the configuration of queues and how they are related to each other. The powerful configuration management of most MOM systems greatly increase the "looseness" of the coupling between system components.

Another important factor is the ownership or control of process logic. If processes are managed centrally, this results in tight coupling between the different sub-processes and transactions. For example, database mechanisms might be used for ensuring referential integrity and general consistency of the data owned by the different sub-processes. This is often the case, for example, with large, monolithic ERP (Enterprise Resource Planning) systems. If business processes are highly distributed, as in a B2B environment, the different sub-processes and transactions are generally more independent of each other, or more loosely coupled, in the context of our current discussion. Often, this means that one must accept the fact that there is no globally defined consistent process state. Similarly, the data owned by the different participants might not always be consistent—one system might have already cancelled an order for which another system still owns an invoice.

Finally, the way in which participants in the system locate each other has a great impact on the level of coupling in the system. Statically bound services yield very tight coupling, whereas dynamically bound services yield loose coupling. Looking up services in a naming or directory server reduces the tightness with which components are tied together, although it still requires the client to know the exact name of the service to which it wants to bind. Services such as UDDI enable a more flexible location of services, using constraints such as "Find me the next printer on the second floor." Notice that dynamic service discovery as provided by UDDI for Web Services is not a new concept; it has previously been provided by other standards such as the CORBA Naming Service. Notice also that past experience has shown that the number of applications requiring completely dynamic service discovery has been fairly limited.

When making architectural decisions, one must carefully analyze the advantages and disadvantages of the level of coupling. Generally speaking, OLTP-style (online transaction processing) applications, as they are found throughout large enterprises, do not normally require a high degree of loose coupling—these applications are tightly coupled by their nature. When leaving the scope of a single enterprise or single business unit, especially in B2B environments, loose coupling is often the only solution. However, in most cases, the increased flexibility achieved through loose coupling comes at a price, due to the increased complexity of the system. Additional efforts for development and higher skills are required to apply the more sophisticated concepts of loosely coupled systems. Furthermore, costly products such as queuing systems are required. However, loose coupling will pay off in the long term if the coupled systems must be rearranged quite frequently.