Home > Articles > Web Services > XML

  • Print
  • + Share This
This chapter is from the book

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

Level

Tight Coupling

Loose Coupling

Physical coupling

Direct physical link required

Physical intermediary

Communication style

Synchronous

Asynchronous

Type system

Strong type system (e.g., interface semantics)

Weak type system (e.g., payload semantics)

Interaction pattern

OO-style navigation of complex object trees

Data-centric, self-contained messages

Control of process logic

Central control of process logic

Distributed logic components

Service discovery and binding

Statically bound services

Dynamically bound services

Platform dependencies

Strong OS and programming language dependencies

OS- and programming language independent


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.

  • + Share This
  • 🔖 Save To Your Account

InformIT Promotional Mailings & Special Offers

I would like to receive exclusive offers and hear about products from InformIT and its family of brands. I can unsubscribe at any time.

Overview


Pearson Education, Inc., 221 River Street, Hoboken, New Jersey 07030, (Pearson) presents this site to provide information about products and services that can be purchased through this site.

This privacy notice provides an overview of our commitment to privacy and describes how we collect, protect, use and share personal information collected through this site. Please note that other Pearson websites and online products and services have their own separate privacy policies.

Collection and Use of Information


To conduct business and deliver products and services, Pearson collects and uses personal information in several ways in connection with this site, including:

Questions and Inquiries

For inquiries and questions, we collect the inquiry or question, together with name, contact details (email address, phone number and mailing address) and any other additional information voluntarily submitted to us through a Contact Us form or an email. We use this information to address the inquiry and respond to the question.

Online Store

For orders and purchases placed through our online store on this site, we collect order details, name, institution name and address (if applicable), email address, phone number, shipping and billing addresses, credit/debit card information, shipping options and any instructions. We use this information to complete transactions, fulfill orders, communicate with individuals placing orders or visiting the online store, and for related purposes.

Surveys

Pearson may offer opportunities to provide feedback or participate in surveys, including surveys evaluating Pearson products, services or sites. Participation is voluntary. Pearson collects information requested in the survey questions and uses the information to evaluate, support, maintain and improve products, services or sites, develop new products and services, conduct educational research and for other purposes specified in the survey.

Contests and Drawings

Occasionally, we may sponsor a contest or drawing. Participation is optional. Pearson collects name, contact information and other information specified on the entry form for the contest or drawing to conduct the contest or drawing. Pearson may collect additional personal information from the winners of a contest or drawing in order to award the prize and for tax reporting purposes, as required by law.

Newsletters

If you have elected to receive email newsletters or promotional mailings and special offers but want to unsubscribe, simply email information@informit.com.

Service Announcements

On rare occasions it is necessary to send out a strictly service related announcement. For instance, if our service is temporarily suspended for maintenance we might send users an email. Generally, users may not opt-out of these communications, though they can deactivate their account information. However, these communications are not promotional in nature.

Customer Service

We communicate with users on a regular basis to provide requested services and in regard to issues relating to their account we reply via email or phone in accordance with the users' wishes when a user submits their information through our Contact Us form.

Other Collection and Use of Information


Application and System Logs

Pearson automatically collects log data to help ensure the delivery, availability and security of this site. Log data may include technical information about how a user or visitor connected to this site, such as browser type, type of computer/device, operating system, internet service provider and IP address. We use this information for support purposes and to monitor the health of the site, identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents and appropriately scale computing resources.

Web Analytics

Pearson may use third party web trend analytical services, including Google Analytics, to collect visitor information, such as IP addresses, browser types, referring pages, pages visited and time spent on a particular site. While these analytical services collect and report information on an anonymous basis, they may use cookies to gather web trend information. The information gathered may enable Pearson (but not the third party web trend services) to link information with application and system log data. Pearson uses this information for system administration and to identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents, appropriately scale computing resources and otherwise support and deliver this site and its services.

Cookies and Related Technologies

This site uses cookies and similar technologies to personalize content, measure traffic patterns, control security, track use and access of information on this site, and provide interest-based messages and advertising. Users can manage and block the use of cookies through their browser. Disabling or blocking certain cookies may limit the functionality of this site.

Do Not Track

This site currently does not respond to Do Not Track signals.

Security


Pearson uses appropriate physical, administrative and technical security measures to protect personal information from unauthorized access, use and disclosure.

Children


This site is not directed to children under the age of 13.

Marketing


Pearson may send or direct marketing communications to users, provided that

  • Pearson will not use personal information collected or processed as a K-12 school service provider for the purpose of directed or targeted advertising.
  • Such marketing is consistent with applicable law and Pearson's legal obligations.
  • Pearson will not knowingly direct or send marketing communications to an individual who has expressed a preference not to receive marketing.
  • Where required by applicable law, express or implied consent to marketing exists and has not been withdrawn.

Pearson may provide personal information to a third party service provider on a restricted basis to provide marketing solely on behalf of Pearson or an affiliate or customer for whom Pearson is a service provider. Marketing preferences may be changed at any time.

Correcting/Updating Personal Information


If a user's personally identifiable information changes (such as your postal address or email address), we provide a way to correct or update that user's personal data provided to us. This can be done on the Account page. If a user no longer desires our service and desires to delete his or her account, please contact us at customer-service@informit.com and we will process the deletion of a user's account.

Choice/Opt-out


Users can always make an informed choice as to whether they should proceed with certain services offered by InformIT. If you choose to remove yourself from our mailing list(s) simply visit the following page and uncheck any communication you no longer want to receive: www.informit.com/u.aspx.

Sale of Personal Information


Pearson does not rent or sell personal information in exchange for any payment of money.

While Pearson does not sell personal information, as defined in Nevada law, Nevada residents may email a request for no sale of their personal information to NevadaDesignatedRequest@pearson.com.

Supplemental Privacy Statement for California Residents


California residents should read our Supplemental privacy statement for California residents in conjunction with this Privacy Notice. The Supplemental privacy statement for California residents explains Pearson's commitment to comply with California law and applies to personal information of California residents collected in connection with this site and the Services.

Sharing and Disclosure


Pearson may disclose personal information, as follows:

  • As required by law.
  • With the consent of the individual (or their parent, if the individual is a minor)
  • In response to a subpoena, court order or legal process, to the extent permitted or required by law
  • To protect the security and safety of individuals, data, assets and systems, consistent with applicable law
  • In connection the sale, joint venture or other transfer of some or all of its company or assets, subject to the provisions of this Privacy Notice
  • To investigate or address actual or suspected fraud or other illegal activities
  • To exercise its legal rights, including enforcement of the Terms of Use for this site or another contract
  • To affiliated Pearson companies and other companies and organizations who perform work for Pearson and are obligated to protect the privacy of personal information consistent with this Privacy Notice
  • To a school, organization, company or government agency, where Pearson collects or processes the personal information in a school setting or on behalf of such organization, company or government agency.

Links


This web site contains links to other sites. Please be aware that we are not responsible for the privacy practices of such other sites. We encourage our users to be aware when they leave our site and to read the privacy statements of each and every web site that collects Personal Information. This privacy statement applies solely to information collected by this web site.

Requests and Contact


Please contact us about this Privacy Notice or if you have any requests or questions relating to the privacy of your personal information.

Changes to this Privacy Notice


We may revise this Privacy Notice through an updated posting. We will identify the effective date of the revision in the posting. Often, updates are made to provide greater clarity or to comply with changes in regulatory requirements. If the updates involve material changes to the collection, protection, use or disclosure of Personal Information, Pearson will provide notice of the change through a conspicuous notice on this site or other appropriate way. Continued use of the site after the effective date of a posted revision evidences acceptance. Please contact us if you have questions or concerns about the Privacy Notice or any objection to any revisions.

Last Update: November 17, 2020