Home arrow Web Services arrow Page 5 - Dealing with Loose Coupling in a Service-Oriented Architecture

Dealing with Loose Coupling in a Service-Oriented Architecture

In this conclusion to a two-part article series on loose coupling in SOA, we wrap up our discussion of the forms of loose coupling, and explain how to handle its complexity. This article 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 / 2
January 19, 2010
  1. · Dealing with Loose Coupling in a Service-Oriented Architecture
  2. · 4.2.5 Binding
  3. · 4.2.8 Compensation
  4. · 4.2.9 Control of Process Logic
  5. · 4.3 Dealing with Loose Coupling

print this article

Dealing with Loose Coupling in a Service-Oriented Architecture - 4.3 Dealing with Loose Coupling
(Page 5 of 5 )


The forms of loose coupling discussed in this chapter are only some (more or less typical) examples. Again, note that there are no hard and fast rules: you will have to decide on the appropriate amount of loose coupling for your specific context and architecture.

I have seen very different decisions made with regard to different types of coupling. As I mentioned earlier, the policy of one of my customers was to avoid asynchronous communication whenever possible, based on the experience that it led to race conditions at runtime that were very hard, or even impossible, to reproduce in a development environment, and therefore almost impossible to fix. Another customer in the same domain had a policy that synchronous calls were allowed only for reading service calls because the performance was not good enough for writing service calls.

Note that you might also have to decide about combinations of forms of loose coupling. For example, one important decision youíll have to make is whether an ESB should be separated from a backend via a protocol, or via an API (see Section 5.3.3). Separating via an API usually means that the ESB provides libraries each backend or backend adapter has to use. So, deployment and binding become issues. On the other hand, using a common API, you can hide some aspects of synchronous or asynchronous communications inside the ESB.

You might ask which forms of loose coupling are typical. To my best knowledge, there is no answer. All I can say is that the larger systems are, the more loosely they should be coupled.

4.4  Summary

  • Loose coupling is a fundamental concept of SOA (and large distributed systems in general) aimed at reducing dependencies between different systems.
  • There are different forms of loose coupling, and you will have to find the mixture of tight and loose coupling thatís appropriate for your specific context and project.
  • Any form of loose coupling has drawbacks. For this reason, loose coupling should never be an end in itself.
  • The need to map data is usually a good property of large systems.


DISCLAIMER: The content provided in this article is not warranted or guaranteed by Developer Shed, Inc. The content provided is intended for entertainment and/or educational purposes in order to introduce to the reader key ideas, concepts, and/or product reviews. As such it is incumbent upon the reader to employ real-world tactics for security and implementation of best practices. We are not liable for any negative consequences that may result from implementing any information covered in our articles or tutorials. If this is a hardware review, it is not recommended to open and/or modify your hardware.

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