How can a transaction with rollback capability be propagated
across messaging-based services?
Problem
When runtime activities that span multiple services fail, the
parent business task is incomplete and actions performed and
changes made up to that point may compromise the integrity of
the underlying solution and architecture.
Solution
Runtime service activities can be wrapped in a transaction with
rollback feature that resets all actions and changes if the parent
business task cannot be successfully completed.
Application
A transaction management system is made part of the inventory
architecture and then used by those service compositions that
require rollback features.
Impacts
Transacted service activities can consume more memory
because of the requirement for each service to preserve its
original state until it is notified to rollback or commit its
changes.
As per the previous figure, Services A and B complete their respective tasks successfully. However each time
they do, they initiate a local transaction, temporarily saving the current state of the database prior to making
their changes (1, 2). After Service C fails its database update attempt (3), Services A and B restore their
databases back to their original states (4, 5). The business task is effectively reset or rolled back across
services within the pre-defined transaction boundary.
This page contains excerpts from:
SOA Design Patterns by Thomas Erl
Foreword by Grady Booch
With contributions from David Chappell, Jason Hogg, Anish Karmarkar, Mark Little, David Orchard, Satadru Roy, Thomas Rischbeck, Arnaud Simon, Clemens Utschig, Dennis Wisnosky, and others.
(ISBN: 0136135161, Hardcover, Full-Color, 400+ Illustrations, 865 pages)
For more information about this book, visitwww.soabooks.com.
Arcitura IT Certified Professionals (AITCP)
Arcitura IT Certified Professionals (AITCP)
Arcitura IT Certified Professionals (AITCP)
Arcitura YouTube Channel
This page contains excerpts from:
