随着公司的系统架构逐渐向分布式SOA化的方向衍变，未来不可避免的需要涉及到分布式事务问题。最近这段时间主要对一些公开的分布式事务解决方案进行了比较粗略的了解，包括企业级的解决方案X/Open DTP，WS-transaction协议簇以及支付宝的分布式事务框架。由于支付宝的事物框架和业务结合的非常紧密，因此在这里只记录对DTP以及ws-transaction的理解（内容可能包含一些错误，欢迎指正）。
DTP
DTP模型对于大部分Java程序员来讲并不陌生，实际上主流Java应用服务器很早就实现了基于DTP模型的分布式事物，简单的DTP事务模型如下：
模型中的几个关键组件以及在模型中的作用：
- Application Program(AP) - 包含业务的应用程序，通过调用TM的相应接口控制事务的生命周期。
- Transaction Manager(TM) - 事务协调器，主要负责协调各个RM达到事务的全局一致性。
- Resource Managers(RM) - 事务资源，如JDBC连接JMS会话等。Java语言中的事务资源必须实现XAResource接口才能参与DTP模型中。
- TX - AP与TM之间的访问协议
- XA - TM与RM之间的访问协议
上图中的DTP模型仅适合工作在只有一个事务协调器的场景中，随着系统分布化的程度越来越深入，系统架构中会出现多个TM（通常对应着多个业务系统）并且需要在TM之间协调事务一致性，这时的DTP模型则演化为下图的版本：
相比于DTP version1模型，version2模型中新增了以下组件：
- 主/从事物域 - 由于涉及到了多个事务域，系统需要定义一个主事务域并通过主事物域的TM来协调和其他从事务域之间的事务一致性。通常主事物域都是整个业务中最关键的业务系统。
- Communication Resource Manager(CRM) - 通讯资源管理器，用于在各个事务域之间传递全局事务上下文
- TxRPC/XATMI - AP和CRM之间的访问协议
- XA+ - TM和CRM之间的访问协议
v1版本的DTP模型相对简单，实现分布式事务资源虽然有一定代价但是还算可控，但是由于适用的场景非常有限。v2版本的DTP模型理论上可以适用于绝大多数分布式系统，但是因为大幅度增加了复杂度，所以使用的代价非常高（系统规模达到一定数量之后事务资源的占用情况将非常严重）。
目前Java语言环境下，JavaEE应用服务器能够完整的实现DTP v2事务模型，但是必须使用EJB的声明性事务，JTS以及RMI/IIOP，其中JTS（基于OTS的Java实现）承担TM和CRM的角色，IIOP负责事务上下文在各个域之间的传递。Spring框架则只能够实现DTP v1事务模型，如果要实现v2模型，还需要做很多额外的工作。
ws - transactionws-transaction协议簇中包含了ws-coordination, ws-atomictransaction, ws-businessactivity核心事务协议以及ws-address, ws-security等辅助协议。对于大部分的业务来说，主要是使用ws-coordination和ws-atomictransaction来实现系统间的分布式事务（ws-businessactivity主要是实现需要非系统自动协调的长事务）。
本质上，ws-transaction的运行模式与DTP并无大的差别：ws-coordination结合了和TM和CRM的角色，包括将事务资源加入全局事务中（通过ActivationService以及RegistryService），以及在系统之间传递事务上下文（在SOAP header中加入上下文信息）；而ws-atomictransaction则和TM的角色类似，用于协调事务的一致性（都使用2PC算法）。
ws-coordination的结构如下:
架构中的组件说明（结合分布式事务）：
- Client/Server - 应用程序，主要包含业务逻辑的实现
- Coordinator/Participant - 事务协调者，类似于DTP中的CRM组件。Coordinator/Participant可以通过调用jta来实现内部的多事务资源协调。Client通过调用ActivationService创建一个新的CoordinationContext，Server通过调用CoordinationContext中的RegistryService将自己做为participant加入到全局事务中。
- Request/Response/Context - 业务消息，其中消息头中会包括CoordinationContext，在ws-transaction中即事务的上下文信息
- Coordination Message - Coordinator/Participant之间传递的协调消息，在ws-transaction中即事务的协调信息。
- Transaction protocol - coordination框架本身可以支持多种protocol，ws-atomictransaction提供了transaction protocol的支持
由于在ws-transaction架构下，Client/Server/Coordinator/Participant之间都是通过web-service进行交互/协调，而在整个分布式事务过程中包括了Coordinator/Participant的enlist，Client/Server之间业务调用，应用/Participant之间的交互以及Coordinator/Participant之间的事务协调，真正业务相关的操作只有Client/Server之间的业务web-service调用，因此非业务资源的消耗会变的非常巨大。
综合来看，当系统架构不太复杂并且支撑的业务量不大时，DTP v1模型是个比较合适的选择。一旦系统规模开始上升并且业务量达到一个数量级之后，DTP v1模型无法很好的支持而无论是DTP v2或ws-transaction都会带来性能和维护方面的潜在问题，因此往往基于业务的分布式事务解决方案会是更加好的选择。