可自管理的分布式工作流(workflow)引擎的设计与实现 (2-1)

摘要：针对当前企业和政府对分布式工作流应用的需求趋势，给出了一个基于JMX（Java Management Extensions）－Java管理扩展框架和Observer观察者模式的可自管理的分布式工作流引擎（Self-Management Distributed Workflow Engine）的设计与实现。在该实现中以观察者模式作为主控引擎与各个执行引擎进行分布式协作的实现机制。利用JMX Notification Model（JMX通知模型）和JMX Timer Service(JMX时间服务)实现观察者模式的异步特性。主控引擎充当目标对象,所有的执行引擎充当观察者并关注主控引擎的状态改变。主控引擎的调度机采用轮转法为所有的实例活动动态分配执行引擎。执行引擎通过在启动时自动注册到主控引擎，关闭时自动从主控引擎注销，实现了整个系统的可自管理性，而以工作流命名空间（WorkflowNameSpace）的形式对工作流相关数据的封装和EJB容器提供的良好的事务特性，保证了整个系统的可靠性。
关键词：java管理扩展框架；观察者模式；分布式工作流引擎
www.jiedichina.com, 南京捷帝科技
1 引言
工作流技术是实现企业业务过程建模、业务过程仿真分析、业务过程优化、业务过程管理与集成，从而最终实现业务过程自动化的核心技术[1]。早期的工作流应用系统都是集中式的，即由一个工作流引擎去完成整个流程实例的执行。随着计算机和网络技术的发展更加迅速和成熟，特别是Internet 应用日益普及的情况下，现代企业和政府的信息资源越来越表现出一种异构、分布、松散耦合的特点，信息共享、资源整合、协同办公已成为当前众多企业和政府的共同需求，而随着EJB、RMI、Web Service等分布式技术的日益成熟，分布式工作流的研究已成为当前众多组织和厂商的共同方向。
1.1 分布式工作流引擎概述
“分布式工作流引擎”的概念是相对于早期的集中式工作流引擎而言的，即整个工作流管理系统只有一个核心引擎，这个核心引擎负责解析工作流的流程定义，将工作流定义加载为运行时定义，然后调度和监控流程中每个活动的执行。对于人工活动结点，负责为参与者生成相关的工作项，对于自动活动结点，负责调用外部的具体应用（如企业中的HR、CRM等应用，或者是执行某项操作的一个JavaBean）[2]，这种集中式的工作流管理系统由于主要的负荷全集中在一个工作流引擎上，因此在可扩展性、健壮性以及吞吐量等方面都不能满足企业执行大规模复杂应用的需求，尤其是当基于此集中式的工作流引擎的应用同时被大量用户访问时，将有可能导致工作流服务器的过载而瘫痪[3]。
所谓分布式工作流引擎是指采用一组分布在不同节点上的工作流引擎来共同协作完成整个工作流实例的执行。每个工作流引擎负责完成其中一部分活动实例的执行，不同的工作流引擎之间通过可靠的通信机制实现协作[4]。通过分布在不同网络节点上的多个工作流引擎的协作来运行工作流流程，可以明显改善集中式工作流引擎的性能瓶颈问题。
1.2 研究现状
在分布式工作流的研究领域，以IBM公司的基于“持久消息队列”、瑞士苏黎士大学的基于“事件驱动”和美国达特茅斯大学的基于“可移动代理”的分布式工作流系统较具典型性和可行性[1]。
基于“持久消息队列”的分布式工作流―Exotica/FMQM(FlowMark on Message Queue Manager)，以“消息传送”为实现机制。执行节点接收到消息后，执行当前活动，执行完当前活动后，根据当前活动的输出连接弧向其它节点发送消息，从而推动整个过程实例的进程。
基于“事件驱动”的分布式工作流―EVE（Event Engine－事件引擎），主要由事件引擎服务器和Broker（代理）组成。事件引擎服务器负责接收来自本地代理及远程事件引擎服务器的事件，并根据ECA（Event Condition Action）规则定义，把事件发送给“感兴趣”的代理，当代理接到相应的事件后，就开始执行一个工作流实例的某一个活动，在这期间，代理还会产生新的事件。这些事件被通知到事件引擎服务器后，服务器将继续以事件的方式推动整个过程实例的进程。
基于“可移动代理”的分布式工作流―DartFlow，由可移动的代理将代码与数据传递到另外的网络节点上去执行，从而实现工作流过程的分布式执行。
Yan等人采用Petri网来对分布式工作流系统进行建模，进而提出标准的工作流结构和工作流块的概念，
以此支持复杂的分布式工作流管理系统的实现[5],Alonso等人考虑了分布式工作流引擎中的数据管理问题[6]，Pallec等人采用MOF(Meta-Object Facility)来达到工作流管理系统中的互操作性[7]。这些方法或多或少都能达到分布式工作流管理系统的目的，但在系统的自管理性、可扩展性方面并不令人满意。本文针对当前企业和政府对分布式工作流管理系统应用的这种需求趋势，提出了一种分布式工作流引擎的实现方案，即使用JMX（Java Management Extensions）－Java管理扩展框架和Observer（观察者）模式，实现可高效自管理的分布式工作流引擎，同时利用观察者模式所具有的异步调用的特点，实现了整个工作流引擎的高效性和低耦合性。
2 可自管理的分布式工作流引擎(SMDWE--Self-Management Distributed Workflow Engine)的设计
2.1 SMDWE设计原理
SMDWE的设计分为二个部分，即数据存储的设计和逻辑控制的设计。
2.1.1 数据存储的设计
基于关系数据库的多表结构，以EJB的CMP（Container-Managed Persistence容器管理的持久性）作为持久化策略统一以实体Bean的形式存储工作流模型定义的相关数据及运行实例数据。运行时采用一组实体Bean将静态定义加载为运行时定义。同时，该CMP也就是运行时实例。将运行时工作流的定义划分为小的对象，即如下的核心实例：流程（InstProcess）、活动（InstActivity）、工作项（Workitem）、转移（InstTransition）、其它相关数据。将运行时工作流的定义划分为小的对象，减少了资源冲突的可能，既提高了效率，又保证了线程安全性。同时可以将这些对象序列化之后方便地在执行引擎之间进行传递。
2.1.2 逻辑控制的设计
Observer(观察者)模式，是一种典型的设计模式，我们通常采用它来减少互相通信的组件之间的耦合从而实现异步调用。传统的观察者设计模式有两个主要的参与者：一个 subject（目标）和一个 observer（观察者），其中观察者关注目标的状态改变。
JMX是具有高度可伸缩性的管理框架，是 Java 应用程序的管理规范，目前已成为新的J2EE规范中一部分。JMX可以实现应用程序组件的热插拔、热配置和热管理。另外，JMX 的功能不仅仅是对组件进行管理，对那些基于组件进行开发的应用程序，JMX也提供了一个统一的、可配置的管理框架[8]。JMX管理框架中的MBean通知模型类似于Java中的事件监听器模型。MBean或管理应用程序可以作为MBean事件的监听器注册。在本实现中，我们将实现了NotificationListener接口的主控状态机（MainEngineObservable）作为MBean事件的监听器注册到MBeanServer上，用来接收由JMX框架提供的时间服务Timer所循环发出的通知。
SMDWE由一个主控引擎和分布在网络中的多个执行引擎构成。执行引擎作为观察者注册到主控引擎上，主控引擎和执行引擎分别作为目标对象和观察者。主控引擎由一个分布式引擎管理器充当具体的目标对象与执行引擎的观察代理器进行通信。主控引擎负责执行流程的初始活动和动态调度执行引擎去执行流程中的其它后续活动。当初始活动执行完毕时，目标对象（主控引擎）的状态发生改变，然后主控引擎调用动态调度机根据动态调度算法决定后续活动的执行者，同时观察者（执行引擎）得到一个状态变更通知（此通知中包括当前活动及其转移的相关数据和执行此活动的执行引擎的名称），然后目标对象（主控引擎）回调每个执行引擎的观察代理器的update()方法，如果执行引擎的名称与通知中的名称一致，则此执行引擎的观察代理器调用活动处理器执行相关的动作（执行流程的第二个活动），依次类推，此执行引擎在执行完自己的任务后，将回调主控引擎的addNotification()方法重新设置主控引擎的状态，此时其他的观察者（执行引擎）再次得到主控引擎的状态变更通知，然后符合条件的观察者（执行引擎）继续执行自己的动作，从而推动整个工作流流程的前进。
3 系统结构
根据对SMDWE的设计原理的分析，下面给出其整体结构图：



图1 SMDWE系统结构图
定义态系统主要包括可视化的过程建模定义工具，用户根据实际的业务流程进行建模，然后建模定义调用过程定义存储服务将业务模型存入数据库。
运行态系统是由部署在网络上的一个主控引擎和多个执行引擎共同组成。主控引擎和执行引擎之间通过EJB远程调用进行通信。SMDWE由工作表管理器、活动执行处理器（主控引擎、执行引擎）、过程实例加载器、过程定义解释器、分布式引擎管理器、动态调度机、主控状态机、观察代理器、观察器、应用程序代理器、工作表生成器等组成。下面对各部分做简单的说明：
工作表管理器：负责与流程参与者交互，为其生成相关的工作项，供办理人拾取、提交工作项；
活动执行处理器（主控引擎、执行引擎）：负责执行具体的活动，对于人工活动负责生成相关的工作项，对于自动活动负责调用外部的具体应用（主控工作流引擎只负责执行初始活动）；
过程实例加载器：主要负责接收用户的流程启动请求，然后对静态的流程定义进行加载；
过程定义解释器：负责将xml形式的流程定义与流程对象进行互相转换；
分布式引擎管理器：负责维护网络上所有的执行引擎的URL（Uniform Resource Locator统一资源定位符）及它们各自观察代理器的JNDI（Java Naming and Directory Interface － Java命名和目录接口），网络上所有的执行引擎都首先要注册到此管理器上，然后再由其注册到主控状态机上。流程执行时负责接收执行引擎发送的已执行活动的信息，取得其后继活动，调用JMX的时间服务向主控状态机发送状态变更通知。此管理器用EJB实现，由执行引擎的观察代理器远程调用；
动态调度机：主要根据负载均衡原理，利用轮转法，动态调度各个执行引擎；
主控状态机：作为目标对象维护执行引擎的观察者列表，负责记录每个流程实例中执行活动实例的状态，同时负责监听分布式引擎管理器发出的状态变更通知。状态变更时，负责向观察者（执行引擎）发送通知。最后调用动态调度机，决定下一个活动的执行者；
观察代理器：是执行工作流引擎负责观察目标对象的观察器的远程代理，由EJB实现；
观察器：执行引擎的本地观察者，启动时负责调用分布式引擎管理器将自身注册到主控引擎上，执行
流程时负责观察主控工作流引擎的状态，并提供update()回调方法；
应用程序代理器：负责代理执行外部的应用程序，如JavaBean、EJB、特定应用程序等；
工作表生成器：在执行引擎中只负责生成工作项；
4 系统实现方案
4.1 主控引擎的Observable组件模型



图2 主控引擎的Observable组件模型图
主控引擎的Observable组件模型如图2所示，其中MainEngineObservable类继承java.util.Observable类，作为主控引擎的流程状态机，其作用如下：
1） 实现目标对象（Subject）的身份，负责维护所有观察者（执行引擎观察器）的一个列表；
2） 实现javax.management.NotificationListener接口，负责监听分布式引擎管理器发出的状态变更通知；
3） 接到通知后，先调用父类Observable的setChanged()方法改变自身状态，然后调用notifyObservers()方法通知所有的观察者主控状态机的状态发生改变；
4） notifyObservers()方法分别调用注册表中的每个观察器的update()方法；
DistributeEngineManagerBean分布式引擎管理器类实际上是MainEngineObservable的一个远程代理，由SessionBean实现，远程观察者（执行引擎）通过EJB远程调用分布式引擎管理器的方法，将自己注册到目标对象MainEngineObservable上。DistributeEngineManagerBean主要完成以下功能：
1） 保存远程观察者的URL；
2） 接受远程观察者的注册；
3） 调用MainEngineObservable类的addObserver()方法进行真正的注册；
4） 提供addNotification()方法接收已执行活动的信息，供主控引擎和执行引擎的活动处理器调用；
5） 提供triggerNotification()方法，给主控状态机发送真正的状态变更通知；
4.2 执行引擎的Observer组件模型



图3 执行引擎的Observer组件模型图
执行引擎的Observable组件模型如图3所示，其中ExcuteEngineObserver类充当执行引擎对主控引擎的观察者身份，实现了java.util.Observer接口类，提供一个update()回调方法，供主控引擎调用。在update()方法中实现对活动执行处理器的调用，从而完成工作流活动的执行。
ExcuteEngineObserverProxyBean类是ExcuteEngineObserver类的一个远程代理，实现了EJB 2.0的Home接口和Remote接口。主控引擎通过对此代理的远程调用，然后再由此代理通过本地调用ExcuteEngineObserver类的update()方法，间接实现对执行引擎的活动处理器的执行调用。

www.jiedichina.com,南京捷帝科技