Transaction policy: Client Orchestration Strategy-Learn how to implement a reliable client-based transaction strategy

Introduction: Sometimes, the presentation layer of an application must handle coordination between multiple API layer method invocations to complete a single transactional unit of work. In this article, the transaction policy family author Mark Richards will discuss client-side choreography (clients orchestration) transaction policies and explain how to implement it in the Java™ platform.

If you have been reading this series, you should know that you now need an effective and reliable transaction strategy to ensure the high degree of consistency and integrity of your data, regardless of the language, environment, framework, and platform you are using. In this article, I'll discuss the client Orchestration transaction strategy, which I outlined earlier in the "Model and Policy overview" article. My advice is still to use this policy when the client layer of the application must initiate one or more calls to the API layer to complete a single transactional unit of work. I'll use the EJB 3.0 specification in my code example, which is the same concept for the Spring Framework and Java Open Transaction Manager (JOTM).

Sometimes an application is written using a fine-grained API layer, which requires a client to initiate multiple invocations to the API layer to implement a single logical unit of work (LUW). This may be because complex and diverse client requests cannot be aggregated using coarse-grained API models, or are simply caused by poor application design. For whatever reason, when multiple API layer method invocations from the client exceed a reasonable scope for refactoring to a single API layer call, the simpler API layer policy should be discarded and the client Orchestration transaction strategy adopted.

Basic structure

In the API layer policy, I outlined the two golden rules for building a transaction strategy:

The method to start a transaction is specified as the transaction owner.

Only the transaction owner can roll back the transaction.

I mentioned these rules again, because they also apply to client orchestration transaction policies. It is important that the transaction owner is the only way to manage transactions and perform commits or rollback, regardless of where the method of starting the transaction is located.

Figure 1 shows a typical logical application layer stack for most Java applications:

Figure 1. Architecture Hierarchy and Transaction logic

The architecture in Figure 1 implements the client Orchestration transaction strategy. The class that contains the transaction logic is displayed as a red shadow. Note that in this policy, the client layer and API layer contain transaction logic. The client layer controls the transaction scope. The transaction starts, commits, and rolls back from here. The API layer method contains transaction directives that instruct the transaction manager to consolidate and use the transaction scope that starts with the client layer. Business and persistence layers do not contain transaction logic, which means that they do not start, commit, or roll back transactions, nor do they contain transaction annotations, such as @TransactionAttribute in EJB 3.0.

Do not be restricted to the 4 levels shown in Figure 1. Your application architecture can have more or less layers. You can combine the presentation layer with the domain layer in a WAR file, or your domain class can be included in a separate EAR file. You can include business logic in domain classes and combine them into one level. This does not affect the operation and implementation of the transaction policy.