Home arrow Web Services arrow Page 2 - 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 - 4.2.1 Asynchronous Communication
(Page 2 of 4 )

Probably the most well-known example of loose coupling is asynchronous communication (see Figure 4-1). Asynchronous communication usually means that the sender of a message and its receiver are not synchronized. Think of it like sending an email. After you send a message, you can continue your work while waiting for an answer. The recipient might not be available (online) when you send the message. When she comes online, the message gets delivered, and she can process it and send a response if necessary (again, with no requirement that you be available/online when she sends it).

Figure 4-1.  Decoupling by asynchronous communication 


One problem with asynchronous communication occurs when the sender needs a reply. With asynchronous communication, you don’t get replies to your messages immediately. Because you don’t know when (or whether) a reply will arrive, you continue your work and start to perform different tasks. Then, when the response arrives, you have to deal with it in an appropriate way. This means that you have to associate the answer with the original request (e.g., by processing something like a “correlation ID”). In addition, you have to process the reply, which usually requires knowledge of some of the initial state and context when the request was sent. Both correlating the response to the request, and transferring the state from the request to the response, require some effort.  


See Chapter 10 for a discussion of different message exchange patterns (MEPs) and Section 15.3.3 for details about correlation IDs.

The situation gets worse when you send a lot of asynchronous messages. The order in which you receive responses might be different from the order in which you sent the messages, and some of the awaited responses might not arrive (or arrive in time). Programming, testing, and debugging all the possible eventualities can be very complicated and time consuming.

For this reason, one of my customers who has hundreds of services in production has the policy of avoiding asynchronicity whenever a request needs a reply. Having found that debugging race conditions (situations caused by different unexpected response times) was a nightmare, and knowing that maintainability was key in large distributed systems, the customer decided to minimize the risk of getting into these situations. This decision involved a tradeoff because performance was not as good as it might have been with more asynchronous communication.

As this discussion demonstrates, there are two sides to introducing asynchronous communication in SOA (or distributed systems in general):

  1. The advantage is that the systems exchanging service messages do not have to be online at the same time. In addition, if a reply is required, long answering times don’t block the service consumer.
  2. The drawback is that the logic of the service consumer gets (much) more complicated.

Note that when discussing asynchronicity, people do not always mean the same thing. For example, asynchronous communication from a consumer’s point of view might mean that the consumer doesn’t block to wait for an answer, while from an infrastructure’s (ESB’s) point of view, it might mean that a message queue is used to decouple the consumer and provider. Often, both concepts apply in practice, but this is not always the case.

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