面向异构中间件的工作流事务完整性研究

《面向异构中间件的工作流事务完整性研究》由会员分享，可在线阅读，更多相关《面向异构中间件的工作流事务完整性研究（9页珍藏版）》请在金锄头文库上搜索。

1、http:/ 面向异构中间件的工作流事务完整性研究 面向异构中间件的工作流事务完整性研究 杜楠1 王柏2 1,2北京邮电大学计算机科学与技术学院， （100876）北京 E-mail（dunantseg.org, ） 摘 要:摘 要:在电信业务支撑领域， 一些业务流程通常需要逻辑完整性， 因此就要考虑到异构中间 件对工作流事务完整性的影响。本文参考了模型驱动架构（Model Driven Architecture， MDA）的思想，试图从技术的角度找出一种较为通用的解决方法，满足面向异构中间件的工 作流事务性的要求。 关键词:关键词:事务性工作流、Saga 事务模型、 模型驱动架构 一、引一、

2、引 言言 工作流技术已经成为当前研究的一个热点，市场上也出现了很多基于工作流技术的产品。工作流一般都由若干工作流程组成，一个流程包含若干步骤，一个步骤完成一项基本功能。在电信业务支撑领域，一些业务流程通常需要逻辑完整性1，它们要么不被执行，要么所包含的所有步骤都成功执行，这就是工作流中的事务完整性2。 在分布式计算环境下， 同一流程中的不同步骤可能涉及到不同的业务系统， 这些业务系统可能采用不同的中间件产品， 虽然每一种事务中间件都有其自身的机制来保证局部事务的完整性，但是在整个流程的层次上，我们面对的是一种全局性事务，因此需要考虑到异构中间件对工作流事务完整性的影响。 模型驱动架构（MDA）

3、是 OMG 组织定义的软件开发框架，其核心思想是强调在软件开发过程中模型抽象的重要性， 在 MDA 框架中软件的开发过程是通过对软件系统进行建模及自动转换等一系列活动来驱动的。 本文首先讨论了保证面向异构中间件的工作流事务完整性的两种可能的解决方案， 然后以此为基础在 MDA 的框架之内实现了适用于电信业务流程的一个简单的事务性工作流执行引擎。 二、解决方案探讨二、解决方案探讨 传统数据库事务模型仅仅满足短生命周期的事务对于共享数据库的访问要求， 无法有效的支持工作流的事务处理， 特别是一些电信业务支撑领域中的业务流程往往跨越多个基于不同中间件平台的信息系统， 而且执行时间可以长达几天甚至几个

4、月， 具有典型的分布式长事务的特征。因此针对传统数据库事务模型的不足，我们需要研究一种高层次的事务模型，以满足面向异构中间件的工作流事务完整性的要求。 2.1 基本概念 2.1 基本概念 事务是一个原子工作单元，它是一组预先定义好的逻辑操作序列，执行这一组操作后，1http:/ 系统将由初始的一致状态变换到下一个一致状态， 并完成预定义的功能。 事务具有以下特性： ? 原子性（Atomicity） ：事务保持原子性。一个事务内的所有操作要么全部“提交” ，要么全部“回滚” 。 ? 一致性（Consistent） ：事务所产生的结果具有一致性。无论事务成功与否，事务结束后系统将处于一致状态。 ?

5、 隔离性（Isolated） ：事务具有隔离性。事务的中间状态对于其他事务来说是不可见的。 ? 持久性（Durability） ：一个事务一旦完成，它所产生的结果是持久的。 任何满足 ACID 特点的工作单元都可以被称为事务。事务只能以两种方式结束：提交或回滚。 事务提交意味着该事务中的所有操作都成功执行， 所有相关操作所做的修改就永久地保存下来，系统进入一个新的一致性状态。如果事务中的部分操作失败，则整个事务被视为失败并回滚，由相关操作所做的修改必须全部撤销，系统恢复到事务开始时的一致性状态。 事务性工作流2是对高层事务模型的研究与探索。基于工作流的事务完整性模型既不同于本地数据库的事务处理

6、模型， 也不同于基于二阶段提交协议的分布式事务处理模型， 我们是通过调用中间件所提供的各种接口服务来实现我们的商务逻辑， 是在中间件的层面上来保证事务的完整性，因此基于以上考虑有两种可能的解决方案来保证工作流的事务完整性： 1) 基于两阶段提交协议模型的解决方案。基于两阶段提交协议模型的解决方案。 该解决方案的核心思想就是通过在中间件层之上再架构一层“全局事务协调者”将“二阶段提交”2扩展成“三阶段提交”以满足工作流的事务完整性。 2) 基于“补偿”机制的解决方案。基于“补偿”机制的解决方案。 这种解决方案的核心思想源于传统的数据库事务模型， 即通过系统日志记录的目前正在执行的流程自动构建一种

7、“补偿”流程来实现工作流级别的事务“回滚”从而保证工作流的事务完整性。 下面分别加以说明： 2.2 基于两阶段提交协议模型的解决方案 2.2 基于两阶段提交协议模型的解决方案 事务管理器通过两阶段提交协议（2PC）协调事务提交过程，它根据参与事务资源的表决情况来做出决定，如果所有资源都“预提交”成功则返回“提交”消息给管理器，然后管理器将进行正式 “提交” 并向所有资源发出正式提交的消息； 只要有一个资源没有 “预提交”成功并返回“回滚”消息，则管理器将向所有资源发出“回滚”消息以将整个事务“回滚” 。 基于以上考虑， 我们在中间件层的基础上再实现一个基于流程的全局事务协调者， 流程每一步的事

8、务完整性由各个事务中间件来保证， 而这些事务中间件又是在全局事务协调者的控制之下来一起保证整个流程的事务完整性， 因此可以设想利用多线程同步来协调各个事务中间件的工作，具体的操作过程如下所述： 2http:/ 图 1 扩展 2PC 的多线程模型 如图 1 所示，由于每种线程都有“活动”和“休眠”两种状态，我们将流程每一步的工作装入一个子线程，而“全局事务协调者”是主线程，对于流程的每一步创建一个子线程，装入中间件适配模块开始执行，当执行到“提交”的前一步时我们设置一个等待信号量，这个信号量由主线程发出以协调各个子线程之间的同步，子线程因等待信号量而“休眠” ，由于事务中间件所执行的事务还未正式

9、“提交” ，所以根据“二阶段提交协议” ，此时底层数据库处于“预提交”状态。最终，主线程根据各个子线程“预提交”的情况统一发出信号量以决定是将成个流程真正“提交”还是“回滚” ，可以说这是流程的“内在”机制来保证流程自身的事务完整性的。 从表面上看来问题似乎已经解决了，但随着研究的不断深入和对实际系统的进一步了解，这种方案的固有缺陷就越发暴露出来，分析原因如下： 图 2 扩展 2PC 多线程模型的局限性 事务性操作不能被从中阻断，如果在 commit 或 rollback 之前将线程休眠将导致数据库表被锁定，因为此时数据库表正在被事务性操作所更新，正处于预提交状态，还未达到稳定的状态（ “提交

10、”或“回滚” ） ，DBMS 是不允许再有其它连接对同一张数据库表进行任何访问的，而在一个流程中，如图 2 所示，流程的下一步是要依据上一步的结果，就很有可能需要对上一步处于“预提交”状态的数据库表进行访问，而这样又是被 DBMS 所拒绝的，从而导致了流程无法正常执行。 虽然这种解决方案有其自身的局限性， 但这种局限性也让我们更加关注事务性工作流内在的特点，即：执行周期长、执行时间不可预测以及前后关联紧密等。基于这种考虑，我们可以采取“补偿”的办法来解决问题。 3http:/ 2.3 基于“补偿”的解决方案 2.3 基于“补偿”的解决方案 基于“补偿”的解决方案是一种依靠“外在”的机制，对目前

11、正在执行的流程，根据系统日志，自动生成一种新的“补偿”流程来实现“回滚” ，这种解决方案主要是借鉴了Saga高级事务模型3,4,5的思想。Saga 事务模型9将长事务分成一系列的小事务,每个小事务都有自己的ACID 属性,这个长事务就称作Saga 事务，如果所有的小事务都进行了提交，那么整个Saga 事务才算提交，如果Saga 事务执行了一部分小事务就取消了，那么必须对已经提交了的小事务进行补偿。这一过程可以用一个有限状态自动机来描述。 一个有限状态自动机M是一个五元组：M = S,L,S0,F ? S 表示一组非空状态的集合 ? 表示一组有限输入的集合 ? L 表示一个映射 SS 即一个状态

12、转移到另外一种状态 ? S0S是初始状态 ? F 是结束状态的集合 下面使用有限状态自动机来对 Saga 高级事务模型进行描述。 在基于Saga事务模型的工作流事务模型中可以将工作流Ts看作是一个可以分解为多个顺序执行的子事务的Saga事务，那么Ts可以表示为Ts = Seq (T1 T2 T3 Tn) 该式表明Ts将由顺序执行的T1 T2 T3 Tn组成，而T1 T2 T3 Ti Tn（0exists(value | value.type=targetAttribute.type) and targetAttribute.Get.type= targetAttribute.type and

13、targetAttribute.Get.parameters-isEmpty() and targetField.Class=targetAttribute.Class; bidirectional; mapping sourceAttribute.nametargetField.name; sourceAttribute.typetargetField.type; sourceAttribute.nametargetAttribute.name; sourceAttribute.typetargetAttribute.type; 3.1.2 关系数据库 PSM 转换规则定义 3.1.2 关系

14、数据库 PSM 转换规则定义 关系数据库 PSM 转换规则定义包括：UML 类向数据库表的转换、UML 类关联向数据库表的转换、UML 类属性向数据库表模式的转换等，如下所示为 UML 类向数据库表的转换定义 Transformation ClassToTable (UML, SQL) params tidName : String = “ID“ ; tidType : SQLDataType = INTEGER; source class : UML:Class; target 7http:/ table : SQL:Table ; primary : SQL:Key ; tid : SQL

15、:Column; target condition table.primary = primary and tid.type = tidType and tid.table = table and tid.key = primary and tid.nullable = false; unidirectional; mapping class.name + tidName tid.name; class.name table.name; class.attributes() table.column; class.associationEnds() table.foreign; 3.2 C#

16、PSM 与关系数据库 PSM 3.2 C# PSM 与关系数据库 PSM 由于这两种 PSM 模型都是从同一个 PIM 模型转换过来的， 因此它们之间也可以互相转化， 比如说在PIM模型中有一个元素是Interface， 根据转换规则定义， 我们可以知道在C#PSM模型中它被转换成了哪一个 C#类，同样也可以知道在关系数据库有哪些关系表格用来描述这个 Interface 元素，这样就很容易在 C#类与关系数据库表格之间建立“桥接”关系，我们可以将一个配置好的 Interface 对象很容易地存储到数据库中， 同理， 我们也可以轻松地从数据库中读取相关数据来实例化 Interface 类对象。 四、结束语四、结束语 综上所述，本文的主要工作有以下两个方面： ? 研究了一种较为通用的方