图 1: 定单获得和定单处理应用
Dr. Subrahmanyam Allamaraju
© Subrahmanyam Allamaraju 1999. All rights reserved.
This document is protected by copyright. No part of this document may be reproduced in any form without prior written consent of the author. This document is for electronic distribution only.
All trademarks acknowledged.
译者的声明
(1)版权声明中声明了“未经版权持有者的书面允许不得以任何形式复制本文内容，本文档只以电子版的形式发布”，很显然，版权声明没有限制对电子版的翻译和在网络上传播。
(2)译者对译文不做任何形式的担保。译者对译文不拥有任何权利并且不负担任何义务。
(3)任何人在对译文进行任何处置(包括但不限于复制、传播)之前，应当认真阅读版权声明，译者对其他人的行为不负任何责任。
译序：译者添加的图 6 引自介绍 ORBacus OTS 的网页。译者乃一介草莽，译文中难免存在疏失错讹，祈望仁者指正。
原文: http://www.subrahmanyam.com/articles/transactions/NutsAndBoltsOfTP.html
事务管理是对企业应用最紧要的要求之一。在贸易、金融和电子商业领域中，多数大的企业应用依赖于递送它们的商务的事务处理功能。 鉴于当今商务对灵活性的要求，在建造、部署和维护企业级别的分布式应用中，事务处理占据的是其中最复杂的部分之一。
本文把以下内容介绍给读者:
本文不特定于任何产品，力图在描述各种要点和概念时保持普遍性。本文不打算比较各种事务处理的技术/标准，只是提供对此的一个讨论。
为了完成对数据的操作，企业应用经常要求并发访问在多个构件之间共享的数据。这些应用在下列条件下应该维护数据的完整性(由应用的商务规则来定义):
在这种情况，可能要求在(分布式)资源上的一组操作被当作一个工作单元(unit)。在一个工作单元中, 操作的所有部分一起成功或失败并恢复。在下面的情况下这个问题更加复杂:
在所有情况下, 都要求应用维护一个工作单元的成功或失败。在失败的情况下，所有资源要把数据状态返回到以前的状态 (比如说，工作单元开始前的状态)。
事务的概念和和事务管理器(或者一个事务处理服务)在一个工作单元中的维护数据完整性，这就简化了这样的企业级别分布式应用的构造。
一个事务是有下列属性的一个工作单元:
这些属性叫做 ACID 属性，担保一个事务是永远不会不完整，数据永远不会不一致，并发事务是独立的，一个事务的效果是持久的。关于在分布式系统什么能出错的简要的一个描述，请参见 在事务处理系统中的容错和恢复。
为了引出在建造事务性应用中涉及的要点，考虑一个定单获得和定单处理应用，它的体系在 图 1 中展示：
|
图 1: 定单获得和定单处理应用 |
这个应用由两个客户构件组成，分别实现定单获得和定单处理操作。这两个操作构成了一个工作或事务单元。分别基于产品，定单，库存清单和货运信息。在这个图中，点断尖头指示的只读的数据访问，而连续尖头指示指示的是修改数据的事务性操作。下面是在这个应用中的事务性操作:
当作为一个事务来实现这些操作时，应致力于下述要点:
看到了从头开始建造一个事务性应用的要点，考虑在一个在 图 2 中展示的事务处理体系下建造相同的应用。注意，尽管有多种可能的体系，它们将在后面的章节中讨论， 图 2 中所展示的代表了本质的特征。
 ` 图 2: 事务处理体系 |
这个体系介入了一个事务管理器和每个数据库(资源)一个的资源管理器。这些构件从应用构件(定单获得和定单处理)中抽象出了特定于事务的大多数要点，并分担事务实现的职责。下面讨论这个体系的各种构件。
| 应用构件:职责 | |
|
应用构件是事务性资源的客户。它们是应用开发者用于实现商务事务的程序。
在事务管理器的帮助下，这些构件建立全局事务， 如果需要的话传播事务上下文，并在这些事务的范围内操作事务性资源。这些构件不负责实现保护事务的 ACID 属性。但是作为应用逻辑的一部分 ，这些构件通常做是提交还是回滚一个事务的决定。
| 资源管理器:职责 | |
|
一个资源管理器是一个管理持久和稳定的数据存储系统的构件，并且参与同事务管理器的两段提交和恢复协议。
一个资源管理器典型的是一个稳定的存储系统上的一个驱动器或一个包装，有操作数据的接口(给应用构件), 并且为了参与由事务服务器协调的两阶段提交和恢复协议。这个构件也可以，直接的或间接的，向事务管理器注册资源，这样事务管理器就可以追踪所有参与事务的资源。这个过程叫做资源征集。为了实现两阶段提交和恢复协议，资源管理器应该实现可能被恢复所使用的附加机制。
资源管理器提供两套接口: 一套给应用构件用来连接和完成对数据的操作，另一套给事务管理器用来参与两阶段提交和恢复协议。
| 事务管理器:职责 | |
事务管理器是一个事务处理环境的核心构件。它的主要职责是当应用构件要求时建立事务，允许资源征集和遣散,并指挥同资源管理器的两阶段提交或恢复协议。
一个典型的事务性应用通过向事务管理器发出一个发起事务的请求来开始一个事务。作为响应，事务管理器开始一个事务并把它同一个呼叫线程联系在一起。事务管理器也建立一个事务上下文。在事务中的所有应用构件和/或线程共享事务上下文。初始发起开始事务的请求的线程，或者如果事务管理器允许的话，任何其他线程可以通过发起提交或回滚请求来最终终止事务。
在一个事务被终止之前，在事务管理器所知道的多个数据上，多个构件和/或线程可以完成事务性操作。如果事务管理器允许的话，在事务最终完成之前，一个事务可以被挂起或被继续执行。
一旦应用发起了提交请求，事务管理器为一个提交操作准备所有资源(通过指挥一次投票表决)，并基于是否所有的资源都准备好了(就绪)提交，来发起对所有资源的一个提交或回滚请求。
下面的章节讨论事务处理相关的各种概念。
指定一个事务叫做事务界定(demarcation)，通过把分布式的构件绑定到一个全局事务上来完成事务界定工作，它是标记构成一个事务的一组操作的一种方法。
最常用的界定的途径是为事务处理标记执行操作的线程。这叫做编程界定。这样建立的事务可以通过去除标记而被挂起，并在以后通过从挂起点向恢复点显式的传播事务上下文来恢复执行。
事务界定在向事务管理器的一个提交或一个回滚请求之后结束。提交请求指导所有参与的资源管理器永久的记录事务中的操作的效果。回滚请求使资源管理器撤消事务中所有操作的效果。
一个可替代编程界定的是声明界定。基于构件的事务处理系统如 Microsoft 事务服务器、和基于应用服务器的事务处理系统如企业 Java Beans 规范支持声明界定。在这种技术中，构件在部署时被标记为事务性的。这暗示了两件事。首先，界定的职责从应用转移到了容纳构件的容器(container)。为此，这种技术也叫做管理容器界定。其次，界定从应用建造期间(静态)延期到构件部署期间(动态)。
因为多个应用构件和资源参与了一个事务，对于事务管理器建立和维护发生的事务的状态是必须的。这通常以事务上下文的形式完成。
事务上下文是在资源上的事务性操作和调用操作的构件之间的一个关联(association)。在一个事务执行期间，所有的参与事务的线程共享事务上下文。所以事务上下文在逻辑上封装(envelop)了在一个事务期间在事务性资源上的完成的所有操作。事务上下文通常由底层的事务管理器透明的维护。
资源征集是资源管理器向事务管理器报告它们参与一个事务的过程。这个过程使事务管理器可以跟踪参与一个事务的所有资源。资源管理器使用这些信息协调资源管理器完成的事务性工作，以及驱动两阶段提交和恢复协议。
在事务结束时(一个提交或回滚之后)事务管理器遣散资源。在此之后，不再保持事务与资源之间的关联。
这个事务管理器与所有应征一个事务的资源之间的协议确定是所有的资源管理器都提交事务还是它们都终止(abort)。在这个协议中，当应用要求提交事务时，事务管理器向所有涉及的资源管理器发起一个准备请求 。每个这些资源可以依次发送一个回应来指示出它是否准备好(就绪)提交。只有当所有的资源管理器都准备好提交，事务管理器才向所有的资源管理器发起一个提交请求。否则， 事务管理器发起一个回滚请求接着事务被滚回来。
X/Open 分布式事务处理(DTP)模型是 Open Group 提出的一个分布式处理模型，Open Group 是一个厂商财团。这个模型是在事务处理和数据库领域中多数商业厂商间的一个标准。
这个模型由四个构件组成:
这个模型还定义了下列接口:
| 函数 | 功能 |
tx_open |
打开一个事务管理器和相关联的一组资源管理器。 |
tx_close |
关闭一个事务管理器和相关联的一组资源管理器。 |
tx_begin |
开始一个新事务。 |
tx_rollback |
回滚事务。 |
tx_commit |
提交事务。 |
tx_set_commit_return |
提交事务。(译注：原文如是) |
tx_set_transaction_control |
在链状和非链状模式间选择。在链状事务的情况下，工作被分成片段(piece)，每个片段在一个平坦的(flat)事务控制之下。一旦完成了工作的一个片段，这个片段的提交或回滚不依赖于其他的片段的状态。 |
tx_set_transaction_timeout |
设置一个事务超时间隔。 |
tx_info |
返回事务信息，如它的标识符、事务的状态等。 |
xa_*()
函数，由资源管理器实现，被事务管理器使用。 | 函数 | 功能 |
xa_start |
指导一个资源管理器把应用程序的后续的请求与一个被提供的标识符所标识的事务关联起来。 |
xa_end |
结束一个资源管理器与一个事务的关联。 |
xa_prepare |
资源管理器为提交操作做准备。由事务管理器发起，是两阶段提交操作的第一阶段。 |
xa_commit |
提交事务性操作。由事务管理器发起，是两阶段提交操作的第二阶段。 |
xa_recover |
检索一个就绪的(prepared)列表，启发式的(heuristically)提交或启发式的回滚事务。 |
xa_forget |
忘记同给定事务标识符相关联的启发式(heuristic)事务。 |
ax_*() 函数，由事务管理器实现，被资源管理器使用。 |
函数 |
功能 |
|
ax_reg |
动态的向一个事务管理器应征。 |
|
ax_unreg |
动态的从一个事务管理器撤出。 |
X/Open DTP 模型在产业界中被确立的。一些商业事务管理产品，象 TXSeries/Encina (完全附属于 IBM 的 Tranarc 的产品), Tuxedo 和 TopEnd (BEA Systems 的产品), 还有 AT&T GIS 支持 TX 接口。尽管 Microsoft 的 Transaction Server 不支持 TX 接口，它还是能够同象 Oracle 这样的遵从 XA 的数据库互操作。类似的，多数商业数据库象 Oracle, Sybase, Informix 和 Microsoft SQL Server, 以及消息中间件产品如 IBM 的 MQSeries, 和 Microsoft 的 MSMQ Server 提供了 XA 接口的一个实现。
对象事务服务(OTS)是由对象管理组织(OMG)规定的分布式事务处理服务。这个规范扩展了 CORBA 模型并定义了一系列跨越(across)多个 CORBA 对象完成事务处理的接口。
OTS 模型基于 X/Open DTP 模型之上并提供下列增强:
OTS 可以同 X/Open DTP 模型互操作。一个使用了事务性对象的应用可以使用事务管理器的 TX 接口来进行事务界定。
OTS 体系由下列构件组成:
除了通常的事务性语义，CORBA OTS 还提供了下面的:
 |
|
图 6: ORBacus® OTS 体系 (译者添加) |
下面是 CORBA OTS 规范的原理上的接口：
| 接口 | 职责 |
| Current |
|
| TransactionFactory | 显式的事务建立 |
| Control | 显式的事务上下文管理 |
| Terminator | 提交或回滚一个事务 |
| Coordinator |
|
RecoveryCoordinator |
在失败的情况下协调恢复 (replay_completion) |
| Resource | 参与两阶段提交和恢复协议 (prepare, rollback, commit, commit_one_phase, forget) |
Synchronization |
在两阶段提交开始之前和完成之后的应用同步 (before_completion, after_completion) |
SubtransactionAwareResource |
提交或回滚一个子事务 ，被事务服务调用 (commit_subtransaction, rollback_subtransaction) |
TransactionalObject |
所有事务性对象都实现的一个指示器(marker)接口 |
下述产品提供 OTS 的实现: Integrated Transaction Service (Inprise 的产品), OrbixOTM (Iona 的产品), OTSARjuna (Arjuna Solutions Limited 的产品), 和 TPBroker (Hitachi Software 的产品).
Java 事务服务 和 Java 事务 API 是分布式计算领域中最新的竞争参加者。作为企业 Java 的发起者，Sun Microsystems Inc. 在 1999 年提出了规范。(译注：1999年12月8日推出正式规范)
图 3: Java 事务的发起 |
JTS 规定一个 Java 事务管理器的实现。这个事务管理器支持 JTA，应用服务器可以使用它建造支持事务性 Java 的应用。 JTS 的内部实现 OMG OTS 1.1 规范的 Java 映射。Java 映射被规定在两个包中: org.omg.CosTransactions 和 org.omg.CosTSPortability。尽管 JTS 是 OMG OTS 1.1 规范的一个 Java 实现，JTA 仍是简化了的 X/Open DTP 模型中的 XA 和 TX 的函数形式的接口。
JTA 规定一个建造事务性应用服务器的体系，并为这个体系中各种构件定一系列的接口。 这些构件是: 应用构件, 资源管理器, 应用服务器, 它们在 图 3 中展示。
JTS 为事务性应用服务器和应用提供了一个新的体系，而在内部遵从 OMG OTS 1.1 接口。这就允许遵从 JTA 的应用程序同其他的遵从 OTS 1.1 的应用程序通过标准的 IIOP 来互操作。
象在 图 3 中展示的那样，在 Java 事务模型中，Java 应用构件能通过 JTS 在遵从 JTA 的资源上指挥事务性操作。JTS 扮演的是 OTS 之上的一个薄层。应用可以发起全局事务来包含其他 OTS 事务管理器，或参与到一个其他遵从 OTS 的事务管理器发起的全局事务。
关于 JTS 和 JTA 的更详细的叙述请参见 Java 事务服务。
Microsoft 事务服务器(MTS) 是一个基于构件的事务服务器，它的构件基于 Microsoft 的 构件对象模型 (COM)。MTS 编程模型为建造事务性 COM 构件提供接口，而 MTS 运行环境提供一个部署和管理这些构件和管理事务的方法。使用了 MTS，由多个 COM 构件做的工作可被组合在一个单一的事务中。
不象本章讨论的其他技术，MTS 是一个产品并且不基于开放的规范。还要注意，尽管 MTS 环境提供了一些其他特征，如资源缓冲池(pooling), 对象重复利用(recycling), 访问控制等，本节只聚焦于 MTS 的事务性的功能，并尝试把各种事务管理的概念映射到 MTS 环境。
高层的 MTS 体系在 图 4 中展示：
 图 4: Microsoft 事务服务器 |
MTS 环境由下列部分组成:
一个 MTS 对象是一个 MTS 构件的一个实例(一个构件在 MTS 上被部署，并被 MTS 管理)。对于每个 MTS 对象，MTS 建立和维护一个上下文对象(ObjectContext)，它为一个 MTS 对象提供执行上下文。上下文对象也维护事务上下文的信息。资源分发器和 DTC 可以为事务界定，资源征集，遣散，两阶段提交等，访问这个事务上下文信息。注意，在 MTS 中，为每个 MTS 对象都维护事务上下文信息，而不是为所有参与一个事务的对象维护一个单一的事务上下文对象。
每个 MTS 对象可以通过调用 ObjectContext 对象的一个方法，来参与决定一个事务的结果(outcome):
MTS 同时允许事务的编程界定和声明界定。对于在 MTS 上部署构件，声明界定是强制的。除此之外，MTS 客户也可以通过编程发起和结束事务。
MTS 进行自动的资源征集。当一个 MTS 对象向资源分发器要求到一个资源的连接时，资源分发器获取调用对象的事务上下文，并用来它注册连接。
经管 MTS 只能在 Microsoft Windows 平台上获得，MTS 可以同遵循 XA 协议的资源管理器互操作，并且在非 Windows 平台上操作的这样的资源管理器可以参与由 DTC 协调的事务。
关于 MTS 的更多的信息请参阅 MSDN library。 要得到 MTS 和其他竞争技术的一个快速而详细的特征汇编请参阅 MTS FAQ.
企业 Java Beans (EJB) 是来自 Sun Microsystems Inc 的一个技术规范。它规定了一个建造基于构件的分布式应用的框架。在过去六个月中，符合这项技术的应用服务器已经从不同的厂商出现，而规范当前由 Sun Microsystems Inc 来不断改善。(译注：1998年3月24日推出正式的规范1.0).
作为一个应用服务器框架，EJB 服务器致力于事务处理，资源缓冲池，安全，线程，持久性，远程访问， 生命周期等。但是同于 MTS 的情况，本节只聚焦于 EJB 框架的分布式事务性模型。
EJB 框架规定叫做 enterprise beans 的构件的构造，部署和激发。EJB 规范把 enterprise beans 分成两类: 实体(entity) beans 和 任务(session) beans。实体 beans 抽象的是持久域数据，任务 beans 提供特定的应用逻辑的任务。两种类型的 beans 被遵循 EJB 的服务器在叫做容器的东西中维护。一个容器为 enterprise beans 提供运行时环境。
图 5 展示了一个遵循 EJB 的应用服务器的简化了的体系。图中只展示了体系的各组成部分间的本质性的交互。
 图 5: 在 EJB 应用服务器中的事务 |
一个 enterprise bean 由两个接口来指定: home 接口和 remote 接口。home 接口指定如何建立和查找一个 bean。通过这个接口，一个客户或其他 bean 可以获得驻留在一个 EJB 服务器上某个容器中的某个 bean 的一个引用。 remote 指定特定于应用的与实体或任务 bean 相关的方法。
客户可以通过 Java 命名和目录接口 (Java Naming and Directory Interface: JNDI)机制获得 enterprise bean 的 home 接口的引用。一个 EJB 服务器应当为任何命名和目录服务器提供一个 JNDI 实现。通过使用这个到 home 接口的引用，一个客户可以获得到 remote 接口的一个引用。客户可以接着访问在这个 remote 接口中指定的方法。EJB 规范规定 Java 远程方法激发(Remote Method Invocation: RMI) 作为远程方法激发的应用层的协议。但是，一个实现可以使用 IIOP 作为线路层(wire-level)协议。
在 图 5 中，客户首先获得到 home 接口的一个引用，接着通过 home 接口获得到到 Bean A 的一个实例的一个引用。Bean A 的一个实例获得到 Bean B 的一个实例的一个引用并调用在其上的方法适用相同过程。
EJB 框架不规定特定于任何事务服务(例如 JTS) 或协议的事务管理。但是，规范要求把 JTS 的 javax.transaction.UserTransaction 接口暴露给 enterprise bean。下面的段落讨论的编事务界定要求这个接口。
类似于 MTS，EJB 框架提供了事务的声明界定。容器依靠在一个容器中部署一个 enterprise 的时候指定的属性(attribute)，来自动完成界定。
下列属性确定如何创建一个事务。
EJB 自动执行资源征集。EJB 容器在一个 bean 获得一个连接时、自动的把连接应征到 EJB-aware 的资源管理器上。
EJB 规范为应用同步提供 javax.ejb.SessionSynchronization 接口。当它被一个 bean 所实现，容器为在两阶段提交期间的应用同步而调用 afterBegin, beforeCompletion 和 afterCompletion 方法。
当前有一些厂商提供遵循 EJB 1.0 规范的应用服务器。这样的产品有 BEA Systems Inc. 的 WebLogic, GemStone Systems Inc. 的 GemStone/J, Sun Microsystems Inc. 的 NetDynamics, Oracle Corporation 的 Oracle Application Server, 和 Persistence Software Inc. 的 PowerTier for EJB。 请参阅 EJB Directory 来得到一个 EJB 应用服务器和 EJB-aware 数据库的列表。规范当前正在经历一次较大的彻底检修，遵循新标准的产品有望在1999年底或2000年初推出(译注: 1999年12月17日推出了规范1.1，当前的规范是2.0)。
总的来说，EJB 框架提供了极其类似于 MTS 的特征。两种技术都允许基于构件的事务性分布式应用，并从应用构件中抽象出事务界定的过程。
事务处理一直是复杂的和致关重要的。但是随着 MTS 和 EJB 的到来，事务处理同时抓住了开发者和 IT 组织的兴趣和注意。这不是没有道理的。这些新近的技术简化了分布式事务管理，并为三个重要的开发供给了燃料:
除此之外，这些技术还致力于当今企业应用要求的可伸缩性和健壮性。
本文的目标是聚焦于分布式事务管理中涉及的要点和概念。本文不能足够全面的覆盖这些底层技术的所有详细细节。同时，本文不打算比较技术 ，但尝试着把多种概念映射到每一种技术上。只讨论了 nuts 和 bolts，而不是如何建造它们以及用它们建造怎样的机器。