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

 

4.3     SMDWE的调度算法

www.jiedichina.com 南京捷帝科技

为实现负载均衡，对执行工作流引擎采用轮转法进行调度，其调度算法如下：

(1) 执行引擎注册：执行引擎启动时，通过EJB远程调用主控引擎的分布式引擎管理器，将自身注册到主控引擎的主控状态机上；

(2) 过程实例加载：当主控引擎收到客户启动流程的请求后，引擎调用过程实例加载器，将需要启动的流程定义加载到运行库；然后过程实例加载器调用过程定义解释器，将xml流程定义转化为Process流程定义对象；

(3) 初始活动执行：主控引擎调用活动执行处理器执行流程的第一个初始活动；

（4）发送状态变更通知：活动执行处理器执行完毕后将此活动作为参数调用分布式引擎管理器的addNotification()方法发送已执行的通知；

（5）取得后继活动：分布式引擎管理器根据已执行活动取得其后继活动及工作流相关数据；

(6) 动态调度执行引擎：分布式引擎管理器取得执行引擎的观察器列表，调用动态调度机采用轮转法确定执行引擎的URL，然后将此URL、（5）中的后继活动作为参数调用自身的triggerNotification()方法给主控状态机发送消息；

(7) 主控状态机给执行引擎发送通知：主控状态机监听到消息后，调用setChanged()方法改变自身状态，调用NotifyObservers()方法通知所有注册的执行引擎的观察器，回调每个执行引擎的观察器的update()方法；

(8) 执行引擎执行活动：如果执行引擎的URL与参数中的URL一致，则执行引擎的观察器调用自身的活动处理器，执行当前活动。活动执行完毕，活动处理器再调用分布式引擎管理器的addNotification()方法再次循环执行(4)－(8)直到整个流程结束。

(9) 流程结束。整个流程执行完毕调用清除器清除相关的实例数据。

4.4     分布式工作流中的关键问题及解决方法

4.4.1 工作流相关数据和控制数据的处理

为保证分布式工作流相关数据的同步，本实现中将工作流的相关数据以实例变量的形式，采用实体Bean进行存贮；而在工作流的流程实例或活动实例中，对工作流的实例变量采用工作流命名空间二元组（WorkflowNameSpace

 

 

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

variableList>）的形式进行封装，为此我们引入具有面向对象脚本语言特性的Java代码解释器BeanShell的NameSpace对工作流实例变量进行封装。然后将WorkflowNameSpace对象的实例序列化作为流程实例（InstProcess）或活动实例(InstActivity)的成员变量在执行引擎之间进行传递，从而实现了工作流相关数据传递的可靠传递。

 

工作流的控制数据主要包括工作流实例的一些数据，例如流程实例数据、活动实例数据、工作项数据。在分布式的工作流中主控引擎负责以实体Bean的形式持久化流程实例数据、活动实例数据和工作项数据，这样在应用层实现对工作流的监控时，就可以统一调度工作流的各种实例数据。执行引擎通过EJB远程调用的方式对实体Bean的数据进行维护，即各个执行引擎负责工作流活动实例数据和工作项数据的生成。对于人工型的活动，执行引擎的活动处理器先调用工作流表管理器为此活动生成工作项，如果成功则更改活动状态。对于自动型的活动，则调用应用程序代理器执行外部应用。

4.4.2 分布式事务的处理

工作流中的事务与仅仅满足ACID（Atomicity原子性、Consistency一致性、Isolation隔离性、Durability持久性）属性的经典事务模型是完全不同的：1）经典的事务模型主要是面向数据库的，而工作流中的事务主要是面向活动对象的，需要更复杂的逻辑控制；2）经典的事务模型活动时间很短，工作流中的事务活动时间很长，有可能是一天、一个月或更长；3）经典的事务模型要求一个事务如果不全部成功，就全部回滚，而工作流的事务不能因为一个活动的失败，就回滚整个流程实例（除非有极特殊的需求）；4）经典的事务模型的恢复由数据库的事务控制，而工作流的恢复需要工作流数据和业务数据同时进行恢复，这时可能就会用到复杂的补偿操作。针对于工作流事务的以上特点，在本实现中只采取对某个工作流的活动进行事务控制，只有某一个活动完全执行成功后才去更改流程的状态，分布式执行引擎的活动处理器负责将当前的执行活动和状态两个参数传回给主控引擎的分布式引擎管理器，例如，当执行引擎的活动处理器执行工作流的活动时失败，活动处理器先调用已经根据实际的业务需求定义的一个补偿操作对业务数据进行恢复，然后调用分布式引擎管理器的addNotification()方法时，将当前执行的活动对象和错误标志传回主控引擎，分布式引擎管理器判断如果接收到的是一个错误标志，则调用动态调度机为此失败的活动重新分配一个执行引擎。

4.5     性能分析

4.5.1       可靠性

分布式工作流由于在引擎协作的过程中存在很多的远程数据传递，因此保证其数据传递的可靠性是分布式工作流首先要解决的问题。在本设计中传递的主要是实例数据，而这些实例数据以实体Bean的形式持久化到数据库，在数据传递失败时，从EJB容器的实例池中重新取得实体Bean的实例进行传递，因此有效地解决了数据远程传递失败时的恢复问题。第二种可能的问题是系统中的某个执行引擎在执行活动的过程中失败，此时则采用4.4.2一节中的方法进行恢复。第三种是数据的并发访问问题，为了在应用层实现工作流监控功能时对数据统一处理，所以在主控引擎中统一持久化实例数据。此时由于多个执行引擎通过会话Bean远程调用实体Bean来生成过程实例数据和工作项数据，因此由可能引起并发访问的冲突问题，解决办法是采用主控引擎的EJB容器提供的事务隔离策略控制实体Bean的访问，从而有效地解决了并发访问数据库的冲突问题。

4.5.2       可扩展性

可扩展性包括功能可扩展性和结构可扩展性。功能扩展性，由于本系统采用JMX作为整体的功能管理框架，JMX本身的对应用程序组件的热插拔、热配置、热管理的特性决定了本系统具有良好的功能扩展性。在结构扩展性方面，大多数的分布式引擎不能满足企业的分布式需求，因为这些分布式引擎只是静态意义上的分布，即在流程定义期，将过程的活动定义与执行引擎所在的网络节点进行绑定（如基于消息的Exotica），这样导致了流程定义与执行引擎的紧偶合。而SMDWE是基于观察者模式实现，因此活动的执行是在运行期通过负载均衡算法动态决定的，所以是真正意义上的可动态柔性扩展的系统。在实现时编写一个可由容器自动启动的Servlet，每个执行引擎启动时，此Servlet自动执行，调用观察代理器，由观察代理器远程调用分布式引擎管理器的addObservers()方法将自身注册到主控引擎上。主控引擎的分布式引擎管理器将每个注册过的执行引擎的URL存入数据库，动态调度机动态调度执行引擎时首先调用分布式引擎管理器的getObservers()方法获得所有注册成功的执行引擎列表，然后根据轮转法进行调度。系统需要扩展时，在相应的网络节点上重新部署一个执行引擎，然后启动执行引擎，执行引擎按照上面的方法注册到主控引擎，实现了动态扩展。

4.5.3       容错性

当分布式环境中的某个分布式工作流引擎出现故障时，只有那些正在此分布式工作流引擎执行的过程实例会受到影响，不会使整个系统瘫痪。而当其他流程实例请求工作流引擎时将会绕过此工作流引擎。

5           应用实例

根据上面的设计与实现分析，下面给出一个应用实例来说明怎样应用本文中的方法实现SMDWE的可自管理性和可靠性，应用JMX的时间通知模型实现分布式引擎的异步性。

1）  执行引擎的自动扩展：执行引擎的动态扩展是通过分别调用主控引擎的分布式引擎管理器的注册

方法addObserver（）和注销方法deleteObserver（）实现的。其清单如下DistributeEngineManagerBean.java：

public void addObserver(String excuteEngineURL,String observerJNDIName,String homeInterfaceName) throws WorkflowException {

//向主控引擎注册一个观察者

observerList.add(excuteEngineURL+":"+observerJNDIName+":"+homeInterfaceName);

}

public void deleteObserver(String excuteEngineURL,String observerJNDIName,String homeInterfaceName) throws WorkflowException{

        //删除一个指定URL的观察者

        observerList.remove(excuteEngineURL+":"+observerJNDIName+":"+homeInterfaceName);

}

addObserver()和deleteObserver()方法是两个远程方法，执行引擎启动时由观察器（ExcuteEngineObserver.java）通过EJB远程调用addObserver（）方法，将自身注册到主控引擎上。如果执行引擎关闭则调用deleteObserver()方法注销自己。当系统因为性能原因需要扩展时，就在网络上新部署一个执行引擎并启动，则这个新部署的引擎通过上面的方法注册到了主控引擎。这样系统就具备了高度的可自管理性，执行引擎可随时关闭或加入到系统中来。

2）  活动执行失败时的失败转发：执行引擎执行活动完毕后，不管成功与否都调用分布式引擎管理器

的addNotification()方法，将执行完毕的活动传回主控引擎，并返回一个是否成功的标志。清单如下：

public synchronized void addNotification(InstActivity activity, boolean isSucess) throws WorkflowException {

    this.isSucess = isSucess;

    if (this.isSucess) {

        if (errorList.contains(activity)) {

            errorList.remove(activity);

        }

        List lstNextActivities = getNextActivities(activity);

        Iterator it = lstNextActivities.iterator();

        while (it.hasNext()) {

            InstActivity nextActivity = (InstActivity) it.next();

            nextActivity.setExcuteEngineURL(getDynamicExcuteEngineURL());

            toDoList.add(nextActivity);

        }

    } else {

        errorList.add(activity);

    }

}

从清单中可以看出，如果活动执行成功则取出其后继活动放入待办列表中，如果执行失败则放入失败列表errorList中，此时主控引擎可将此失败的活动继续分配给其它的执行引擎继续执行，因此结合本文中的其它提高可靠性的方法，到达了系统的可靠性要求。

6           总结

目前分布式工作流管理系统正朝着自管理的方向发展，本文提出了一种基于JMX框架和观察者模式实现高效自管理的分布式工作流引擎的设计与实现方法。执行引擎可以随时加入到自管理的分布式工作流管理系统中，加入时只需在网络上新部署一个工作流引擎即可，真正地实现了分布式工作流引擎的自管理和自扩展，每当新增一个执行引擎时，系统便自动扩展，同时具有了更好的处理能力。