关于分散型工作流设定的模型和基础结构

摘要：如今，Web服务流程的设定通常是由一种集中型工作流设定服务作为工作流管理系统的一部分完成的，这一方式在众多参与者中的流程适应性和流程分布方面暴露出许多缺点。为了克服集中型流程导航的不足，我们提出一个关于灵活的、可适应的分布式流程的模型，它是一套可自适应的部件，不需要中央协同。

关键词：分布式工作流；自适应组件；元组空间

1　引言

面向服务的体系结构(SOA)是一种以灵活和松散耦合的方式进行整台服务的方法，可以根据服务请求通过分布式网络对松散耦合的应用群件进行部署、组合和使用，为了实现灵活的集成，必须明确地区分开服务的计算逻辑和服务与其他组件相互关联的协同逻辑。

目前，典型的集成平台包括面向消息的中间件(MOM)和工作流管理系统(WfMS)。在基于MOM的应用中，计算逻辑的单独片段(以下称之为“组件”)以网络信息通道中信息交换的方法进行协同；各组件之间的信息流，即应用的联合协同逻辑，通过消息系统的配置预先确定应用的部署。

本文提出了分布式执行协同逻辑的方法。即每个组件在全局流程的局部实现，与集中型导航相比有下列好处：

(1)流程导航所产生的工作量被一个工作流中的所有个体组件分担。

(2)工作流执行期间，在组件故障的情况下。独立执行路径仍然可以正常执行。

(3)由于工作流设定流程按照预先的定义分发给每一个参与组件，因此把某一个参与组件执行的流程变成任何参与者都没有引入额外导航复杂性的流程片段。

(4)随着协同逻辑在参与者之间被分配，在不影响全局流程模型的情况下，个别组件可以更改为一个单一的流程实例。

2　分散型工作流设定

分布式的、不需要集中型向导的自我导航组件的方法是基于工作流和元组空间技术的结合协同产生的，协同逻辑(即流程定义)在所有的参与者中是分离的，它直接被使用共享元组空间配置和协同的单独组件实现。

当分布式的元组空间是一个关于分布式组件的灵活、可适应和松耦合的协同的平台时，由于相对低级的协同元，在元组空间级别上设计应用组件的协同是复杂的和易错的。囿于分布式的协同逻辑和“全局流程视图”的缺乏。大量组件经由模板连接组成的基于空间的应用几乎无法处理。因此，为了保持像单独组件组成工作流一样的设计应用时的优点。当用一个松耦合的元组空间环境的优势对其进行扩展时，提出包含三个阶段生命周期(设计期、部署期和运行期)的应用模型。在设计期，应用在流程级别上用一个高级工作流语言如WS-BPEL定义；在部署期，流程模型转换为一组单独组件，部署在上面描述的扩展的基于空间的中间件系统上；在流程运行期，经由在组件之间传递控制和数据令牌触发分布式组件执行的完成，用分布式的元组空间作为通讯缓冲器和协同、同步的方法。

3　实行的工作流网络

基于空间的协同依赖于组件之间的同步共享访问对象(代表控制或数据流)。一个与基于空间的协同模型密切相关的模型是Petrl网。它是一个用来描述分布式组件之间的相互作用公认的规范，其基础是一个简洁的数学模型，这个数学模型考虑到正式的分析和仿真。即检查结构性能、简化网络、构造事件图表和计算系统不变量。一个Petri网是一个二分图，它有两个节点类型，称为Places和Transitions。Places是通过转换来进行消耗和生产令牌的容器。一个Transition在其前提条件满足时是可行的，即它的每一个输入的places都包含至少一个令牌。

基于元组空间的协同模式以活动实体(即空间客户)和被动实体(即空间)为基础。Petri网里的Places表现为容器，它可以容纳很多令牌，且能因此而作为元组空间的代表。令牌能够存储在Places里，可以由Transitions来消耗，作为元组的代表在元组空间交换。

4　体系结构要求

由于作为单个行为里的工作流的分裂表现为元组空间对象应用、潜在区域调度、管理分配调度，所以其支持的基础结构(设施)必须具备远程调度、配置和组件管理控制特征。工作流中执行单个行为的组件，在程序进行调度时必须进行配置。描述全部流程的流程定义被转化为一种基于Linda的应用。因此我们可以从流程定义中导出如下内容：

(1)为了触发单个行为的执行，哪种令牌被使用；

(2)哪些计算逻辑需要特殊组件执行；

(3)为了触发后续行为的执行，组件会产生什么样的令牌。

为了使基于空间的组件具有动态的配置，每个组件都要求额外地提供一个配置接口，通过此接口使用一些含有配置信息的元组。上述配置元组不仅可以影响组件间的协同逻辑(如修改描述组件输入的模板)，而且还可以影响执行计算的逻辑(如提供可供选择的计算逻辑或是修改通过参数已经确定的计算逻辑)，这样，组件的配置就可以在整个流程生命周期的不同阶段完成。

在时分调度中，流程模型被“编译”成一系列的组件，每一个Place都被认为是一个元组空间容器。每一个Transitions都被描述成一次在空间上代替其输入位置的指令应用。因此支持的基础结构必须：

(1)为组件配置设置必要的空间；

(2)配置的组件可以识别进程。

5　相关工作

在工作流中描述了各种公共模式，并提出它们相应的Petri网表示法，介绍了一个基于模式的Petri网关于BPEL的语义。包括BPEL的特殊性质，如故障和补偿处理。在Petri网中这个利用关于死路径消除的“死令牌”方法首先引入了布尔网络范围内的事件驱动流程链(EPC)。这些所有提到的方法的共同点是它们明显地着重查证和最大限度的表达性，从而允许非确定性选择结构。我们的方法与平衡折衷可执行性和可验证性不同，明确地把重点放在基于Linda的中间件上的直接可执行性，同时还支持必不可少的工作流模式。

一种关于BPEL流程的分割的可行的办法，经由多个合作组件的流程执行确保了依赖的行为之间的同步，但在构造的时候，它仍然需要一个关于BPEL范围内处理的中央协同。流程通过相应的调用／接收的介绍而区分，可以有效地改变原始的流程模型，使之符合UML由行为图表得到结果的形式的映射流程模型。

6　结论和展望

在这篇论文中，提出了一个基于不同的Petri网的分散型工作流设定的模型和需要给予支持性基础结构的一个总体观点。最后，提出的技术使集中型工作流设定转为分布式的、分散的组件的自我导航，为让单独的、松散耦合组件的执行更加便利，提供了在可设定地址的和可远程访问的元组空间容器之上的基于空间的通讯。通过提供一个合适的基础结构。我们不仅可以分散导航，同时还支持高级的工作流功能，如死路径消除，由于组件行为(和配置)能够在流程运行中适应不断变化的需求，我们还能提高流程的灵活性。