Cross-Service Transaction

How can a transaction 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 should can not 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.
Principles Service Statelessness	Architecture Inventory, Composition

Table 5.6 – Profile summary for the Cross-Service Transaction pattern.

Problem

During the course of a runtime service activity, a variety of issues can arise, relating either to the delivery of data between participating services or to problems occurring within service boundaries.

If a serious failure condition is encountered and insufficient exception handling logic is available within all affected services, then the overarching business process will not be allowed to complete successfully nor will it be allowed to complete a pre-defined failure condition. Instead, services may simply be left hanging in suspension indefinitely or until they time out. Outstanding changes that some services may have made to databases or other resources can end up causing problems or even corrupting parts of the enterprise, because other required changes were never completed.

Figure 6.28 – This figure shows three services beings sequentially invoked in support of automating a parent business task. The first two services successfully complete their required database updates (1, 2), but the third service fails at its attempt to update its database (3). According to the rules of the business process, either all three updates must succeed or none at all. However, because the first two updates have already been completed, the failed update of the third database compromises the quality of the data in the first two (4).

Solution

A transaction system can require that services within a particular composition register themselves as part of a transaction prior to completing their changes. Then, as the service activity is underway, participating services communicate with the transaction system as to their status.

At some point, the system queries all services to ask whether their functions were carried out successfully. If any one service responds negatively (or if any one service does not respond at all), a rollback command is issued, requesting that all services up until that point now restore any changes they may have made back to the original condition. However, if all services respond favorably, then a commit command is issued asking all services to commit their changes.

Figure 6.29 – 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.

Application

Depending on the transaction management system being used, the application of this design pattern can vary. Fundamentally, though, some mechanism needs to be in place so that all services within a given composition can be tracked at runtime and then contacted to receive status updates and for notification of commit or rollback commands.

For services delivered as components, runtime transaction management systems are capable of natively establishing transaction boundaries across services, especially when they rely on traditional binary protocols that create persistent connections.

When services are built as Web services, the WS-Coordination and WS-AtomicTransaction standards provide an industry standard mechanism to support transaction propagation across Web service implementations. Figure 6.x illustrates how a coordinator service is positioned to define the transaction boundary and manage transaction activity.

Figure 6.30 – The transaction coordinator establishes the transaction boundary as per participating services that register for this transacted activity. These services are then queried as to whether the transaction should be committed or rolled back. Because Service CÕs database update attempt failed, it votes to abort the transaction, which is what subsequently happens.

Impacts

For services to participate in this type of transaction, they need to capture a snapshot of a resource prior to making changes to it. This previous condition is often loaded into memory as state data and will continue to consume memory until the service receives the commit or rollback command. In larger transactions involving multiple services, this amount of memory consumption can add up and reduce overall service scalability (an issue especially important to shared agnostic services).

Relationships

Transactions can touch on many runtime activity-related parts of an inventory architecture, which is why this pattern has so many relationships with patterns concerned with messaging, agent, and composition processing.

Transactions are often initiated and coordinated via the parent business process layer (as per Process Abstraction) and are extra effective when all participants can be physically isolated (as per Composition Autonomy).

However, asynchronous-based messaging patterns, such as Event-Driven Messaging and Asynchronous Queuing, are often incompatible with this pattern due to its need to lock resources and its common reliance on synchronous data exchanges.

Figure 6.31 – The Cross-Service Transaction pattern establishes a framework for coordinating transactions that involve numerous services, and therefore relates to a variety of other patterns that provide runtime processing features.

When centralizing process logic as part of an orchestration environment, the scope and complexity of service compositions can increase, primarily due to the rich feature set usually provided by orchestration products. Orchestration logic therefore benefits from the runtime control provided by Cross-Service Transaction, which is why this pattern represents a common extension for the Orchestration compound pattern (Figure 6.x).

Figure 6.32 – The Cross-Service Transaction pattern represents an optional part of the Orchestration compound pattern described in Chapter 9.

Case Study Example

Case study content is not available on this Web site.