Home arrow Web Services arrow Page 4 - 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.2.9 Control of Process Logic
(Page 4 of 5 )

Process-control decisions can also lead to different forms of coupling. Having one central component controlling the whole process logic creates a bottleneck because each involved system must connect with it. Failure of such a central component will stop the whole process.

On the other hand, if you have decentralized or distributed control (where each component does its job and knows which component will continue after) you avoid bottlenecks, and if some systems fail, others can still continue to work. See Section 7.6 for details.

4.2.10  Deployment

Whether you require that system updates be deployed simultaneously, or at different times, is related to coupling. Of course, systems are bound more tightly to each other if it is required that they update synchronously. The more loosely coupled approach of updating at different times, however, leads to a very important drawback: the need for migration, which leads to versioning (see Chapter12).

4.2.11 Versioning

Your versioning policy also has something to do with tight or loose coupling. If a system provides certain data types that are used by a consumer, youíll have problems when the provider adds new attributes. If the provider introduces a new type version, the consumer will have to upgrade explicitly to this new type; otherwise, the provider will have to support both types. If, on the other hand, the provider just adds the attribute to the existing type, this might cause binary compatibility issues, and require the consumer to recompile its code or use another library.

With a more loosely coupled form of data type versioning, the consumer wonít have to do anything as long as the modifications are backward compatible.

However, as discussed in Section 12.3, achieving loose coupling here can be very complicated. Again, itís up to you to decide on your policy by discussing the pros and cons.

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