事务策略: 客户端编排策略-了解如何实现可靠的基于客户端的事务策略

事务策略: 客户端编排策略-了解如何实现可靠的基于客户端的事务策略2011-10-21 IBM Mark Richards简介：有时，应用程序的表示层必须处理多个 API 层方法调用之间的协调，以完成单个事务工作单元。在本文中，事务策略系列作者 Mark Richards 将讨论客户端编排（Client Orchestration）事务策略，并阐述如何在 Java™ 平台中实现它。

如果您一直在阅读本系列，那么应该知道现在需要一个有效且可靠的事务策略来确保数据的高度一致性和高度完整性，而与您所使用的语言、环境、框架和平台无关。在本文中，我将讨论客户端编排事务策略，而我之前在 “模型和策略概述” 一文中简要介绍了这方面的内容。我的建议仍然是，在应用程序的客户端层必须向 API 层发起一个或多个调用才能完成单个事务工作单元时使用此策略。我将在我的代码示例中使用 EJB 3.0 规范；其概念对于 Spring Framework 和 Java Open Transaction Manager （JOTM）是相同的。

有时，应用程序是使用细粒度的 API 层编写的，这需要客户端向 API 层发起多个调用才能实现单个逻辑工作单元（LUW）。这可能是因为复杂和多样的客户端请求不能使用粗粒度的 API 模型进行聚合，或者仅仅是由较差的应用程序设计造成的。无论何种原因，当来自客户端的多个 API 层方法调用超过一个合理的范围来重构为单个 API 层调用时，则应该摒弃较为简单的 API 层策略并采用客户端编排事务策略。

基本结构

在 “API 层策略” 中，我概述了构建事务策略的两条黄金法则：

开始事务的方法被指定为事务所有者。

只有事务所有者才能回滚事务。

我再次提到了这些规则，因为它们同样适用于客户端编排事务策略。无论开始事务的方法身处何处，事务所有者都是管理事务和执行提交或回滚的惟一方法，这一点非常重要。

图 1 展示了一个适用于大多数 Java 应用程序的典型逻辑应用层栈：

图 1. 体系结构层次和事务逻辑

图 1 中的体系结构实现了客户端编排事务策略。包含事务逻辑的类显示为红色阴影。注意，在此策略中，客户端层和 API 层包含事务逻辑。客户端层控制事务作用域。事务从此处开始、提交和回滚。API 层方法包含一些事务指令，它们指示事务管理程序整合和使用由客户端层开始的事务作用域。业务层和持久层不包含事务逻辑，这意味着这些层不会开始、提交或回滚事务，它们也不包含事务注释，比如说 EJB 3.0 中的 @TransactionAttribute。

不要受限于图 1 显示的 4 个层次。您的应用程序体系结构可以拥有更多或更少的层次。您可以将表示层和域层结合在一个 WAR 文件中，或者您的域类可以包含在一个单独的 EAR 文件中。您可以让业务逻辑包含在域类中，并将它们结合为一个层次。这不会对事务策略的运行以及实现造成影响。