Web Services事务性应用

2.5 基于数据中心的公共界面

　　在这个服务网络中，除交换中心外，我们还设置了一个数据中心，设置的目的是多方面的。第一个目的是为统一管理市民的基本信息，从这个意义上讲，数据中心也是一种服务结点，在数据中心上对市民信息进行更新，同样需要通过数据同步和消息队列的机制将这一更新事务传递到其他相关的服务结点。第二个目的是为对外的面向市民、面向企业的公共服务提供数据，如此就无需在运行时刻频繁地对各个服务结点进行数据请求。同时，当某个服务结点崩溃，需要重建的时候，可以从数据中心下载所有其管理和使用的数据。

2.6 体系架构
　　其技术核心就是各个服务结点之间的数据同步事务的实现。而这一机制的实现，在服务网络的第一期目标下，基本可以归结为两点：

·      数据库事务的XML表示；
·      在Web Services环境下事务性的保证。

3 数据库事务的XML表示

　　由于在第一期工程中，所有的服务节点是同构系统，使用了相同的数据库结构，而且为了最大化地减小每个服务节点的实现代价，因此我们采用了完全基于数据库事务的数据同步方式。每条数据同步消息将包含一个事务（transaction）的描述，而一个事务可以包含多个操作（operation），每个操作要么是在某张表中更新（或添加）记录，要么是在某张表中删除记录。

　　根据这样的设计思想，我们可以定义transaction元素（包括其子元素）来表示一个事务消息，具体的Schema定义如下。

　　在这个模式定义中，核心是对数据的操作，这里为简便性起见，仅仅定义了两个操作save_data和delete_data，这也符合国际惯例的定义。理由是，新增数据（记录级）和更新数据（记录级）可以使用相同的调用。相似的模式定义我在第1节中已经提及。

　　这里采用的描述方法是针对通用的数据库操作的，也就是说，无论具体数据库的结构如何，只要每个端系统都是相同的，那么这个消息模式就可以应用。在save_data元素下，包含了以下三个元素。

·      tableName：这个元素指明了需要操作的记录所在的数据库表（Table）的名字。
·      primaryKey：这个元素用于描述待操作的数据记录（record）的主键，系统通过这个主键可以准确定位到需要操作的记录（Record），如果没有找到由该主键标识的记录，那么对应的操作就是新增记录（insert record），如果找到了由该主键标识的记录，那么对应的操作就是更新记录（update record）。
·      allField：这个元素用于描述待操作的数据记录中除主键字段外的所有字段，值得注意的是，主键字段也可以是多个的。

　　而对于delete_data，其结构与save_data是类似的，惟一的差别就是没有allField元素，原因相信大家也很容易理解，在删除数据时，只要知道主键就足够了。

　　有了Schema的模式定义文档，我们就能够生成SOAP消息了。下面首先给出的是一个由单个save_data操作和单个delete_data操作组成的事务的例子。该事务从candidate_employee中删除一条记录，而在employee中添加了一条记录。

4 事务性的保证

　　由于我们使用Web Services架构来架构我们的交换中心，因此在我们定义好了事务消息的XML描述之后，就需要实施如何通过SOAP消息来传输所需要传播的事务消息了。对于这个服务网络而言，其核心问题就是要将服务节点的事务（目前是数据库事务，以后将延伸到业务事务）在各个相应的服务结点上同样以满足事务性的条件下执行。由于我们采用的是Web Services架构，Web Services架构的现有技术中尚未有正式的支持事务的规范或技术。因此在这部分，我们将首先围绕当前这个服务网络中的应用来讨论Web Services的事务性，当解决了当前这个应用实例中的问题之后，我们将从通用全面的角度继续考察更复杂情况下的Web Services事务性的保证。

4.1 基本分布式事务同步

　　在Web Services的环境下，当我们定义好了事务消息的XML描述之后，就需要实施如何通过SOAP消息来传输所需要传播的事务消息了。

　　如果我们在传输事务消息的时候，总能保证单个事务消息使用单个SOAP消息来传输的话，那么这就是最简单的情况。此时，SOAP仅仅是传输事务数据的机制，而并不包含事务控制的功能。

具体的流程可以描述如下。

（1）服务结点SA完成了数据库事务T，事务处理模块使用我们先前制订的XML Schema将事务T表示为XML格式FXML（T）。
（2）服务结点SA的SOAP Service将FXML（T）包装在SOAP Body里面，组成SOAP消息，向服务结点SB发送。
（3）服务结点SB接收到事务消息FXML（T），在SOAP Service中将FXML（T）从SOAP消息中剥离并交给下层的事务处理模块。
（4）服务结点SB的事务处理模块将FXML（T）通过XML解析，转换成内部的事务，并实施运行。

4.2 通过消息中间件

　　服务结点之间直接进行事务交换是最简单的方式，在很多情况下是能够适用的。然而，当服务结点之间的通信并不很通畅，或是由于服务信任方面的考虑不能直接通信时，一般而言，我们会使用消息中间件作为中介来实现服务之间的消息通信（在Web Services环境下就是SOAP消息通信）。

　　当通过消息中间件来完成事务消息的交换同步的时候，流程被调整如下（在这里，消息中间件在功能上进行了一些扩展，它不仅完成消息转发，还控制着事务的传播）。

（1）服务结点SA完成了数据库事务T，事务处理模块使用我们先前制订的XML Schema将事务T表示为XML格式FXML（T）。
（2）服务结点SA的SOAP Service将FXML（T）包装在SOAP Body里面，组成SOAP消息，向消息中间件发送，此时消息在消息中间件中位于服务结点SA的“out” 消息队列中。
（3）消息中间件获得服务结点SA的“out” 消息队列中的事务消息，并分析出与之相关的需要实施事务同步的服务结点集合（假设在这里我们仅找到一个相关的服务结点SB）。
（4）消息中间件将这则事务消息FXML（T）传送或复制到服务结点SB的“in” 消息队列（当然也可以不复制，而采取指针的方式，不过采取这种方式的话，在维护方面的复杂度会有稍许的提高）。
（5）服务结点SB上线之后，检查交换中心的消息队列，获得事务消息，在SOAP Service中将FXML（T）从SOAP消息中剥离并交给下层的事务处理模块。
（6）服务结点SB的事务处理模块将FXML（T）通过XML解析，转换成内部的事务，并实施运行。

4.3 从单条消息到多条消息

　　然而，并不是在任何情况下，使用一条SOAP消息就能够传输一则事务的。由于SOAP消息最终是要和某一种网络协议进行绑定并在网络上进行传输的，大多数网络连接很难保证在一个连接内能稳定地传输大量的数据，比如HTTP。我们在下载/上传大文件的时候，经常会发生中断，此时我们就不得不重传，重传需要耗费同样长的时间，同时传输时间越长，发生错误的可能性也越大，因此，传输大文件如果不加以特别的措施的话，常常会变成一场噩梦。我们通常的方法是将大文件分割成多个小块，分别传输，等全部传输完毕后在对等方组合。由于单个文件块比较小，传输稳定性得到了提升，同时，即使传输失败，重传也比较快。

　　我们将这一用于文件传输的方法，延伸到事务消息的传输中。由于这是一个平台级的特性，因此，我们按照SOAP规范的推荐，使用SOAP Header来控制事务消息的合并执行，同时，为了提高响应率，我们的算法并不一定要等到关联单个事务的消息全部收到才会执行事务，而采取了一定的提前执行的机制，具体细节将在下面详细阐述。

　　首先，我们给出transactionControl这个SOAP Header Extension的模式定义。

　　在这个模式定义中，我们看到，transactionControl这个SOAP Header Extension包含了一个子元素simpleTransaction，我们在下面就使用这个子元素来描述事务消息。不直接使用transactionControl元素，而要在其下再定义一层子元素，是为了以后对事务控制特性进行进一步的扩展，我们会在这基础上实现两阶段提交和三阶段提交等。

　　simpleTransaction元素包含了五个子元素：transactionID、begin、commit、rollback和part。它们的含义分别如下。

·      transactionID：事务的标识ID，两个描述事务的SOAP消息当且仅当具备相同的transactionID时，我们才认为它们是一个事务的两个组成部分。
·      begin：表示事务可以开始执行。
·      commit：表示事务可以提交。
·      rollback：表示事务可以回滚。
·      part：这是一个整数类型的值，表示SOAP Body中的内容是当前事务的第几个部分，整个事务应当按照part值所描述的顺序依次执行。

　　由于这五个子元素可能同时出现（rollback和commit不会同时出现），当服务结点接收到事务消息时，上述的五个子元素被解释执行的先后次序为：transactionID、begin、part（触发解析SOAP Body）、commit & rollback。它们的工作原理可描述如下。

　　当服务结点收到一个事务SOAP消息之后，首先解析出transactionID，如果是新的transactionID，那么在服务器端的事务池中，新建一个事务，并将transactionID赋予之。如果事务池中已经有了这个transactionID，那么就将这个事务消息与之关联。当完成transactionID的识别之后，如果消息中带有begin，那么就启动这个被关联的事务池中的事务。如果消息中带有part，假设part的值为n：

·      将当前消息的SOAP Body作为事务的第n部分存入事务的缓存控件；
·      检查当前事务的缓存空间，如果发现已经包含了1到m之间所有的事务部分，那么就依次执行从1到m之间所有未执行的事务部分。

　　如果消息中带有commit，那么在缓存事务部分的时候（这一定是最后一个事务部分），对其加上标志：“这是该事务的最后一个部分。”当该部分被执行时，整个事务将被提交。

　　如果消息中带有rollback，那么对应的事务被立即回滚，然后该事务失效，如果之后仍然收到该事务空间中的消息的话，服务结点将丢弃这些消息。

　　例如，服务结点可能以如下次序接收到关联同一事务的事务消息：

[part(2)],[part(4)],[begin,part(1)],[part(3)],[commit,part(6)],[part(5)]

　　那么服务结点的动作序列应当如下。

·      接收到[part(2)]，在事务池中创建一个事务空间，并缓存该事务部分，现在缓存的状态为(2)；(2)表示缓存中包含了第2部分；
·      接收到[part(4)]，缓存该事务部分，现在缓存为(2, 4)；
·      接收到[begin，part(1)]，启动事务，缓存该事务部分，现在缓存为(1, 2, 4)，事务1,2两个部分被执行；
·      接收到[part(3)]，缓存该事务部分，现在缓存为(…,3,4)，事务3,4两个部分被执行；
·      接收到[commit,part(6)]，缓存该事务部分，现在缓存为(…,6)，同时第6部分被置commit标志；
·      接收到[part(5)]，缓存该事务部分，现在缓存为(…,5,6)，事务5,6两个部分被执行，然后事务被提交。

　　在这一节中介绍的方法解决了在分布式的环境中，在单点数据库中完成了事务的执行。这个机制有效地解决了我们这个服务网络应用实例的当前需求。

　　然而，我们考虑在将来整个服务网络将向公众开放，包括个人用户和企业用户在内的各种用户都可以访问和使用服务网络。虽然一开始只有一些数据查询的事务开放给他们使用，不过随着整个服务网络的成熟，我们将会在数据中心层次上对外提供业务处理服务，而这些服务被使用时，势必发生一些业务事务。根据整个服务网络的设计原则，这些业务事务需要在整个服务网络上被执行，在这种情况下，与前面我们介绍的单个事务的重复广播有所不同，这里发生的是一个涉及到多个服务结点的分布式事务。例如，这个事务可能同时涉及某个市民的医疗记录和保健记录，而这两者分别是由两个服务结点来管理的。前面的机制已经无法解决这一问题，下面我们将两阶段提交协议(2PC)引入到我们的Web Services环境中来，以尝试解决这一分布式事务的问题。

4.4 两阶段提交

　　分布式系统中处理用户提交的事务时，事务管理器通常使用两阶段提交协议保证所有操作所涉及到的分布式环境中的各个数据库中的相应数据被锁定，从而最后被正确地更新。如果因为某种原因操作不能完成，则要求统一执行“回滚”操作，回到事务开始前的状态。如果事务被成功执行，那么所有相关的数据库都被正确更新，此时这些更新应当被分布式环境中的所有数据库系统都了解。最后，解除相关数据库中相关数据的锁定状态，以便进行下一个事务的执行。

　　以下我们描述一个扩展的两阶段提交的协议过程（这个扩展的2PC比标准的2PC多了预先准备的三个步骤，也被称为3PC）。

·      事务管理器部署在中央服务器上，它处于中心控制结点的位置，以事务发起者的身份开始工作。它首先在事务管理器日志中写入一条“Prepare Transaction”的记录，然后将相应的事务请求发送到所有相关的服务结点（需要执行事务的部分）上。
·      当每个参与事务的服务结点接收到“Prepare Transaction”，服务结点可以按照自己的负载状况选择是“Accept”还是“Reject”，并将“Accept”或“Reject”消息发回事务管理器。
·      当事务管理器收到所有服务结点的响应后，如果全部都是“Accept”消息，那么继续下一步。如果至少有一个服务结点返回的是“Reject”消息，那么这个事务将不会真正开始，事务结束。当然，在处理“Reject”消息的时候，可以有一些优化的方法，我们可以在收到第一条“Reject”消息的时候，即时将事务结束（当然也可以选择缓存在队列里，等过一段时间后重试），并且丢弃以后收到的和这个事务相关的“Accept”或“Reject”消息。
·      当所有服务结点发回“Accept”消息后，事务管理器准备真正开始执行事务。它在事务管理器日志中写入一条“Begin Transaction”的记录，然后将相应的事务执行内容发送给所有相关的服务结点。
·      各个服务结点将此事务写入自己的日志，然后锁定资源以供该事务使用，当资源准备完毕后，服务结点向事务管理器所在的计算机发送“Ready”消息。
·      当事务管理器所在的中心控制结点接收到所有的“Ready”消息后（即参与事务的所有服务结点都必须发回“Ready”信息），它在日志上记录“Commit Transaction”，要求该事务被提交，并通知所有相关的服务结点。如果在一定的时间内，至少有一个服务结点没有返回“Ready”信息，那么它视该事务执行失败。将会在日志上记录“Rollback Transaction”，并发送给所有服务结点，要求回滚事务，并将该事务结束。
·      当这些相关的服务结点接收到“Commit Transaction”通知后，这些服务结点将自身承担的事务部分提交（Commit），并解除对资源的锁定，同时通知事务管理器执行完毕。
·      如果服务结点接收到“Rollback Transaction”通知后，这些服务结点将自身承担的事务部分回滚（Rollback），并解除对资源的锁定。

　　在这里，我们有两个假设。

·      事务管理器总是工作正常的，否则服务结点在无限期等待事务管理器的“Commit”或“Rollback”消息时，将处于无法工作状态，因为服务结点是不能自主地选择提交或是回滚的，否则就有可能与其他服务结点的数据不再同步。此时，其他服务结点可能已经提交或者回滚了。
·      当服务结点锁定事务执行时需要的资源，并且发送了“Ready”消息之后，我们只能认为它一定能完成事务的执行，否则如果在提交阶段发生错误，很可能其他结点已经提交了，提交了的事务是无法回滚的。

　　在仔细地分析了两阶段提交之后，我们来扩展先前定义的transactionControl元素，为这个SOAP Header Extension增加新的功能。

　　simpleTransaction那部分基本上没有什么大的变化，只是将transactionID提取到transactionControl下，以供公共使用。而twoPhaseCommit元素就是供我们描述的扩展两阶段提交协议使用。

　　twoPhaseCommit元素共有以下子元素：serviceNode元素、prepare元素、begin元素、rollback元素和commit元素。下面分别来讲解这几个元素的用途。

·      serviceNode元素：描述服务结点的标识，该元素的值惟一标识了一个服务结点。
·      prepare元素：完成“Prepare Transaction” 阶段的交互。事务管理器发出的“Prepare Transaction” 消息使用prepare元素及其子元素request来表示，同时，如果发往服务结点A，那么该消息中的serviceNode元素取值也应该是A。而服务结点对“Prepare Transaction” 消息的响应则使用prepare元素及其子元素response来表示，具体的response元素的值是“accept”，则表示可以执行事务，如果是“reject”，则表示不能执行事务。同样，服务结点A发回的响应消息，则消息中的serviceNode元素取值也应该是A。
·      begin元素：完成“Begin Transaction” 阶段的交互。事务管理器发出的“Begin Transaction” 消息使用begin元素及其子元素request来表示。事务管理器发出的描述事务内容的消息应当使用begin元素的子元素part来表示，part中的数值为其在事务内容消息序列中的序号，而此时SOAP Body中的内容就是相应的事务内容。这一分块传输的机制与先前的simpleTransaction中描述的是类似的，其中，最后一则消息分块的part元素应当带有值为“true” 的final属性（参照前面的模式文档，part元素可带有一个属性final, final的类型是xs:boolean）。当服务结点接收到所有的消息分块后，即申请所有所需的资源，并使用begin元素及其子元素response来响应。如果资源申请成功，则response的值为“ready”，否则为“failure”。
·      rollback元素：如果某个服务结点返回的begin/response的值为“failure”，那么事务管理器就需要向每个服务结点发送rollback消息。
·      commit元素：如果每个服务结点返回的begin/response的值都是“ready”，那么事务管理器就需要向每个服务结点发送commit消息。

　　下面我们给出一个消息序列来解释这些元素的使用方式，这个消息序列的应用背景是一个涉及两个服务结点A、B的事务执行。

4.5 从数据库事务到商务事务

　　在前面的讨论中，我们主要是针对数据库事务表示、交换和控制的。我们使用了XML格式对数据库事务进行表示描述，然后将XML格式的数据库事务嵌在SOAP消息中进行交换和控制。当从数据库事务的应用领域延拓到商务事务的应用领域中后，与事务描述相关的XML格式就需要进行更改，更改为可用于描述商务事务的XML格式，比如RossetaNET、ebXML体系中的相关部分，同时，在Web Services实现中需要涉及的XML格式解释的部分也要相应进行修改。而基于SOAP机制的消息交换和事务控制等仍可以保持原样不用更改。

4.6 安全性事务控制

　　所谓安全性事务控制，在我们这个使用SOAP消息来描述事务控制的方案中，结合SOAP消息的安全扩展应当是一个比较有效的方式。Web Services Security（WS-Security）是一个SOAP Header Extension，为Web Services提供了一种保障服务安全性的语言。WS-Security通过消息完整性、消息机密性和简单的消息认证来实现消息安全的目的。这些机制能够被用来适应现有的大量的安全模型以及加密技术。WS-Security同时也提供了一个通用的机制用于将许可证（签署了的信任声明，如x509信任状或者Kerberos tickets等）与消息关联，而不需要指定特殊的格式。我们可以尝试使用这种技术来为事务控制提供安全性。

4.7 长事务支持

　　LRUOW（Long-running Unit of Work）模型是由IBM公司研究小组提出的一种扩展的事务模型。这个模型允许长时间运行的商业流程可以执行多个事务性ACID步骤，同时保证整个处理流程的原子性和独立性。每个LRUOW上下文创建一个版本空间（version space）。每个步骤都操纵版本化的对象（versioned object）。当进入一个LRUOW上下文时，对象的最初状态与全局的版本空间相关联。当一个LRUOW完成时，它的版本空间与全局版本空间重新协调（reconcile）。这个扩展的事务模型弱化了传统事务特性，但提供模型应用者更多的适用性和灵活性。为使系统的并发事务不因长事务而被阻塞，这个模型不强制长时间运行的事务对访问的对象加锁，并允许因此引发的对象数据版本冲突由特定的应用程序方法解决。这个模型也允许单个子事务的失败不强制整个事务的撤销，而允许应用程序采用补偿事务修复失败损失，然后让这个事务继续处理流程。这个模型还支持嵌套事务的提交与回滚。所以，这个扩展的事务模型可以适应企业内部集成应用程序以及企业之间集成Web Services的需求。我们可以尝试将该模型应用到Web Services环境中去。

5 相关的技术发展

　　目前，各大技术提供商都在研究和开发Web Services的事务性支持，目前走得最领先的不是Microsoft，也不是IBM，目前他们主要的工作还是集中在基础平台和框架上，为Web Services的互操作性（J2EE与.NET）而竭尽全力。而HP在这一领域比较领先，HP主导开发了一个商业事务协议BTP（Business Transaction Protocol）。我们知道事务的关键特性包括ACID（原子性、一致性、独立性和持久性）以及加锁，而BTP正是在Web Services环境下实现这些事务特性的一个规范协议。BTP是通过XML表示，并通过SOAP传输的。在消息中包含了对ACID的控制表示。HP实现了BTP，具体的软件产品是HP-WST，提供了完整的API以支持在J2EE Web Services平台上实现Web Services事务性。