Home arrow Web Services arrow Page 3 - Dealing with Loose Coupling in a Service-Oriented Architecture
WEB SERVICES

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
TABLE OF CONTENTS:
  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
SEARCH DEVARTICLES

Dealing with Loose Coupling in a Service-Oriented Architecture - 4.2.8 Compensation
(Page 3 of 5 )

Compensation is an interesting form of loose coupling. It has to do with the question of transaction safety. If you have to update two different backends to be consistent, how can you avoid problems that occur when only one update is successful, resulting in an inconsistency? The usual approach to solving this problem is to create a common transaction context using a technique such as two-phase commit (2PC). With this approach, you first perform all the modifications on both backends, except for the final “switch to the updated data”; then, if no system signals a problem, the final commit performs the update on both systems.

2PC is one of the most overhyped attributes of middleware. Whenever there is an evaluation of middleware, the question of whether 2PC is supported arises. However, in practice, 2PC is rarely used in large systems because all the backends have to support it, it requires some programming effort, and it binds resources. The main problem is that all systems have to be online, and have to provide resources until the modifications are complete on the last system. Especially when there is concurrent data access, this can lead to delays and deadlocks.

A more loosely coupled way to ensure overall consistency is compensation. In this approach, you modify the first backend, and then modify the second backend; if only one modification is successful, you then “compensate” for the problem appropriately. For example, you might revert the successful modification to restore the consistent situation that existed before the modifications began, or send a problem report to an error desktop where somebody can look into the details and deal with it manually.

The advantage of compensation is that system updates don’t have to be performed synchronously (some backends might even be offline while they are being updated). The drawback is that you have to explicitly provide and call services that revert previous services or programs for manual error handling.

BPEL, the process execution language of Web Services, directly supports compensation (see Section 7.4.2).


blog comments powered by Disqus
WEB SERVICES ARTICLES

- 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 
Support 

Developer Shed Affiliates

 




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