Home arrow Web Services arrow Loose Coupling in a Service-Oriented Architecture

Loose Coupling in a Service-Oriented Architecture

If you're looking for an introduction to one of the key concepts behind building a service-oriented architecture (SOA), you've come to the right place. This two-part article explains why loose coupling is important to SOA, the forms of loose coupling, and how to deal with it. It is excerpted from chapter four of the book SOA in Practice: The Art of Distributed System Design, written by Nicolai Josuttis (O'Reilly, 2008; ISBN: 0596529554). Copyright © 2008 O'Reilly Media, Inc. All rights reserved. Used with permission from the publisher. Available from booksellers or direct from O'Reilly Media.

Author Info:
By: O'Reilly Media
Rating: 5 stars5 stars5 stars5 stars5 stars / 3
January 15, 2010
  1. · Loose Coupling in a Service-Oriented Architecture
  2. · 4.2.1 Asynchronous Communication
  3. · 4.2.2 Heterogeneous Data Types
  4. · 4.2.3 Mediators

print this article

Loose Coupling in a Service-Oriented Architecture
(Page 1 of 4 )

SOA applies to large distributed systems. Scalability and fault tolerance are key to the maintainability of such systems. Another important goal is to minimize the impact of modifications and failures on the system landscape as a whole. Thus, loose coupling is a key concept of SOA.

This chapter will discuss the motivations for this concept (for large distributed systems), exploring variations of loose coupling from the technical and organizational points of view. This topic will demonstrate that SOA is a paradigm that leads to special priorities when designing large systems. However, again, there is no rule prescribing which kind or level of loose coupling you should employ. This decision must be made based on your specific circumstances.

4.1  The Need for Fault Tolerance

We live in crazy times. The market rules, which means you wonít usually have enough time to create well-elaborated, robust system designs. If youíre not fast enough, flexible enough, and cheap enough, youíll soon find yourself out of the market. Thus, you need fast, flexible, and cheap solutions. 

Fast and cheap solutions, however, canít be well designed and robust. Consequently, you will have to deal with errors and problems. The important point here is fault tolerance. The most important thing is that your systems run. According to [ITSecCity02] , a flight-booking system failure may cost $100,000 an hour, a credit card system breakdown may cost $300,000 an hour, and a stock-trading malfunction may cost $8 million an hour. As these figures show, fault tolerance is key for large distributed systems. When problems occur, it is important to minimize their effects and consequences.

4.2  Forms of Loose Coupling

Loose coupling is the concept typically employed to deal with the requirements of scalability, flexibility, and fault tolerance. The aim of loose coupling is to minimize dependencies. When there are fewer dependencies, modifications to or faults in one system will have fewer consequences on other systems.

Loose coupling is a principle; it is neither a tool, nor a checklist. When you design your SOA, it is up to you to define which kinds and amount of loose coupling you introduce. However, there are some typical topics you might want to consider when you think about loose coupling in your system. Table 4-1 lists them (this list is an extension of a list published in [KrafzigBankeSlama04], p. 47).

TABLE 4-1 . Possible forms of loose coupling in SOA

Tight coupling Loose coupling
Physical connections Point-to-point Via mediator
Communication style Synchronous Asynchronous
Data model Common complex types Simple common types only
Type system Strong Weak
Interaction pattern Navigate through complex object trees Data-centric, self-contained message
Control of process logic Central control Distributed control
Binding Statically Dynamically
Platform Strong platform dependencies Platform independent
Transactionality 2PC (two-phase commit) Compensation
Deployment Simultaneous At different times
Versioning Explicit upgrades Implicit upgrades

This table is far from being complete, but itís pretty typical for large distributed systems. Note again that this is not a checklist. There is no SOA certification saying you conform when all or at least 50 percent of the forms of loose coupling are in use. However, it would be very strange if none of these forms of loose coupling were used in your SOA. If this were possible, your system would appear not to have the common requirements of large distributed systems with different owners. Thatís OK, but you shouldnít call your solution SOA. (Well, it may help you get money and resources for it, but beware of false impressions.)

If there is such a fine list of aspects of loose coupling, and minimizing dependencies is good, you might be wondering why you donít simply use all these forms of loose coupling in each SOA. The answer is that there is a price to pay for loose coupling, in that it makes systems more complex. That means more development, and/or maintenance effort.

To explore how the forms of loose coupling listed in Table 4-1 can help and the costs they can incur, letís examine some more closely. Most of these topics will be discussed in more detail later in the book, so Iíve included references to future chapters where appropriate.

blog comments powered by Disqus

- Dealing with Loose Coupling in a Service-Ori...
- Loose Coupling in a Service-Oriented Archite...
- Safety, Idempotence, and the Resource-Orient...
- The Resource-Oriented Architecture in Action
- Features of the Resource-Oriented Architectu...
- The Resource-Oriented Architecture
- Getting Started with Flex
- Automated Billing and Faxing for the Web
- An Introduction to Web Services
- The Foundations of Web Services: From Novice...
- Web Services Reengineering: Finishing Touches
- Fault Handling with Web Services
- Flow and Web Services
- Process Lifecycles and Web Services
- Business Processes and Web Services

Watch our Tech Videos 
Dev Articles Forums 
 RSS  Articles
 RSS  Forums
 RSS  All Feeds
Write For Us 
Weekly Newsletter
Developer Updates  
Free Website Content 
Contact Us 
Site Map 
Privacy Policy 

Developer Shed Affiliates


© 2003-2019 by Developer Shed. All rights reserved. DS Cluster - Follow our Sitemap
Popular Web Development Topics
All Web Development Tutorials