分布式任务域工作流系统的设计和实现

申请免费试用、咨询电话：400-8352-114

在工作流技术的研究中，分布式工作流系统成为研究的热点。一些分布式工作流系统如通过基于持久消息队列的Exotica，基于可移动代理的DartFlow等，已经在一定程度上解决集中式工作流系统的性能瓶颈，单节点失败和扩展性等问题，为工作流系统在企业的实施提供了基础。

但是从企业的需求来看，这些系统在实用性上仍然存在一些问题：完全分布的结构增加了系统应用和维护的复杂性；将流程分散定义造成工作流模型动态修改时一致性维护的困难；细粒度的流程调度造成应用过程中流程管理不方便的问题等。从企业的实际情况看，企业往往希望工作流系统能够提供集中的流程管理，动态分散的任务执行，以及支持部门或企业级别的多工作流协作执行。
　　
基于这些问题的考虑，本文从工作流应用的实际要求出发，提出了多任务域结构的工作流系统实现方案。该系统通过把企业划分成不同的功能领域，将任务动态分配到相应的领域执行。这样以任务的方式对工作流进行调度，和企业业务的人工调度过程非常一致，方便的实现企业环境中的流程任务的分布执行。

企业功能领域

在工作流的应用过程中，需要首先根据企业的特点，利用通用功能视图模型的基本构件生成对企业需求分析阶段的功能模型。而工作流在企业中的应用可以看作一个三维模型，它们分别是流程逻辑，组织结构模型和应用资源模型。其中，组织模型和资源模型分别代表了企业的人力资源和物资资源，两者结合形成若干相互正交的企业领域。每个领域都有其目标、功能和领域过程，并拥有实现领域目标的相应的资源。领域的划分和确定受到企业经营目标和限制条件集合（如企业资源分配状况）决定，通常表现在企业当中就是企业中不同职责的部门机构。不同的领域之间通过流程进行协作，这也正是工作流在企业应用的基本思想：流程逻辑表示企业的核心商业规则，是企业面向客户的总体任务目标。它跨越职能与组织边界,对企业的各个部门领域进行的协作，集成分散在企业部门的各种资源，实现企业最终的目标。

根据流程和企业领域的交互特性，我们将工作流管理系统中的核心组件与企业的建模过程有机结合，使运行系统能够与企业模型紧密集成。从流程的角度看，我们将这些企业不同的工作域称为任务域。在建立工作流过程模型的时候，针对最基本的活动单元，将它们与适当的任务域相关联。而流程运行时，它的调度被分为两个层次，面向企业业务的流程层和面向组织功能的任务层。流程实现对企业的资源集成，而任务则是绑定在不同领域的过程活动的实例，任务在运行时根据属性和需要被分配到不同的任务域上，由任务域上的处理单元完成任务的处理工作。这样，将企业的任务执行分配到相应的领域，体现了企业部门的职责和划分边界，实现了了工作流的分布执行能力。

多任务域结构的工作流系统

按照WFMC提出的工作流参考模型，一个工作流系统包括过程定义工具、工作流引擎、工作流管理工具、客户应用和工作流应用等功能模块。在该参考模型的基础上，我们提出了面向企业的多任务域结构的分布式工作流系统，系统主要由开发管理平台，一个中央流程服务器和多个任务服务器组成。

从流程服务器和任务服务器的关系来看，流程服务器和多个任务服务器构成了星型拓扑结构模型（如图2所示），流程服务器位于中心，他们为流程层面的调度提供了支持，任务服务器则分散在企业的各个部门，它们作为任务调度的处理单元，为任务层次的处理和调度提供了的支持。流程服务器采用消息队列和任务服务器进行通信，它监控每个任务服务器，并对它们进行管理；任务服务器则向流程服务器报告自己的状态，协助完成流程的执行。从功能上看，流程服务器和任务服务器实现了工作流运行时服务。其中流程服务器负责创建和激活流程实例、对流程进行动态调整，维护任务服务器的状态信息，以及根据活动规则分配任务到不同的任务服务器上执行等等。而任务服务器则实现了任务分布处理，它负责任务实例(Task)的生成，应用资源的调用和工作项（WorkItem）的管理。

开发管理平台使用可视化的开发工具创建工作流的流程模型、组织模型和资源模型。模型的信息保存在中央数据库中，为工作流的分布运行提供共享的库环境。并且，在工作流流程投入运行后，由开发管理平台的流程监控工具来跟踪流程运行和对流程进行实时监测。

在建模的过程中，首先利用开发管理平台建立企业的功能模型，包括企业的组织模型和应用资源模型。与其它的工作流系统不同的是，我们在建立企业的功能模型时，要为企业资源建立任务域信息。通常，任务域按照地理位置或组织结构来划分，如图2中，按照企业的部门将它划分成不同的任务域，每个任务域拥有任务执行过程中需要的相关资源，并且配置一个任务服务器来支持任务项的执行和资源的处理工作。不同的任务服务器使用ID进行标识，这些ID在企业内是全局唯一的。对于任务域内的应用资源，将它们和某个任务服务器ID进行关联，表明资源属于该任务服务器所对应的任务域。任务服务器拥有对任务域内的资源的访问控制权限。

该资源可以存放任务服务器上，也可能是该任务域内的任务服务器可以访问的其他的设备上，在流程运行时，任务服务器可以使用这些资源完成任务操作。同样，对于企业部门的不同角色，他们也通过使用ID与任务服务器相关联，划分企业的任务域角色集合，帮助实现人工活动的分派工作，以及部门的角色相关权限控制。

在建立好企业的功能模型后，需要将流程活动映射到任务域上。对于每个活动，它都有任务实例化规则，规则描述了流程活动绑定的应用资源和角色信息。值得注意的是，流程活动并不直接绑定到任务域上，它只和逻辑资源名和角色名关联，至于资源和角色的任务域信息，在流程运行时，由流程服务器对关联规则解析得到，由此确定相关的任务域，动态分配任务到不同的任务服务器上执行。

有了上面的这些准备，流程就可以开始投入运行了。假设，使用流程开发工具建立流程P，它包括三个串行活动X，Y，Z。企业中有三个任务服务器，用来支持流程的运行。在流程运行前，管理员将流程P部署到任务服务器A上，分配启动权限给用户。这样，拥有该权限的用户可以启动该流程的执行了。图3给出了流程运行的主要步骤和操作：

1) 首先，任务服务器A，B，C在流程服务器S启动后，发送注册消息给流程服务器，建立系统的结构信息；
2) 由于流程P部署在任务服务器A上，用户通过任务服务器A的Web客户端启动流程，任务服务器则通过消息队列向流程服务器S发送流程启动消息；
3) 流程服务器获得开始活动，并得到活动的实例化规则。由于该活动是自动型的活动，根据活动实例化规则得到活动绑定的资源在任务域的分配信息，确定任务服务器A为活动执行者,流程服务器将活动的启动消息和上下文数据传递给任务服务器A；
4) 任务服务器A根据接收的数据，获取资源内容，进行服务激活调用,并在完成服务激活后向流程服务器发送任务完成信息；
5) 流程服务器取到后继活动Y，由于Y是人工型活动，根据Y绑定的角色所在的域信息，S向任务服务器B发送活动Y的上下文信息；
6) 由于工作项分配采取用户主动PULL方式，B生成WORKITEM项，并插入相应的角色的WORKLIST队列，等待该角色的用户进行处理；
7) 用户通过任务服务器的Web客户端访问自己的工作项，提交工作项数据，并通知流程服务器完成任务项的执行；
8) 类似的，流程服务器得到第三个活动的信息，由于该活动的资源是全局共享资源， S将根据任务服务器管理信息选择负荷最小的任务服务器C，由C完成服务激活；
9) 流程完成后，流程服务器进行统计分析工作，收集流程执行数据，供管理分析工具使用。

与[2，3]不同的是，它们实现了流程的全分布运行。但是，它们是通过将流程进行切片，分布到不同的执行机上，在运行时，执行机从本地直接得到活动副本并执行，实现了一种全分布的体系结构。然而，这种结构的系统在流程重组和动态修改时容易引起流程的不一致，造成修改上的不便。并且，流程的切片和分布发生在流程运行前，使得流程与系统结构关系过于紧密。而在我们的系统中，通过对流程进行集中的控制，方便了流程相关的管理；流程活动通过规则的资源属性关联到不同的任务域上，在运行时通过对规则解析动态分配任务执行，实现流程执行的动态性；而且根据企业的人员和资源分配情况，就近获取资源，利用角色部门划分方便对任务的控制，提高了流程的执行效率。

基于J2EE工作流系统的实现

在实际应用中，工作流系统往往在不同的硬件平台、操作系统、网络协议和数据库的异构环境下运行，这对系统的不同模块的通讯和协作提出了很高的要求。而J2EE平台为分布式应用提供一整套的企业服务，包括事务处理、数据库访问、消息收发等。使它成为企业级别分布式软件开发领域的重要技术，为系统的实现提供了强大的软件平台。

消息队列为用户提供基于消息传递方式的工作流系统通信平台。在[2]中实现了基于持久消息队列的全分布式工作流系统。通过使用消息队列可以将消息分布到不同的节点处理，并且队列的事务特性保证消息处理的可靠性，同时消息队列的异步调用方式实现了系统单元之间的松散耦合。

在系统中，流程服务器和任务服务器的通讯采用消息队列方式。并采用JMS(Java Message Service)服务实现消息传递功能。JMS定义了在Java环境中访问消息中间件的接口，并且J2EE平台提供了消息驱动bean(MDB)进一步方便了对异步消息的处理。流程服务器和任务服务器的通信采取JMS的Peer to Peer的方式，每个任务服务器都有一个消息接收队列和一个消息发送队列，流程将消息发送到目标队列后可以继续执行其它的工作，任务服务器通过MDB完成消息的获取和解析工作，这样降低两者的耦合程度，有利于提高系统的扩展性。并且消息队列实现流程之间的并行处理和流程内部的并发活动处理，成为平缓工作流系统负载的一个有效途径。

工作流数据在系统中是集中、持久存储的，这种存储方式使得数据的一致性得以保证，并且为数据的管理和维护带来了极大的方便。同时，现在的数据库技术非常成熟，使得当数据库服务器发生异常时，能够通过日志进行错误的恢复，使系统具有很好的可靠性。

同时，为了避免数据的集中存储带来的负面影响，如数据服务器的处理效率和网络带宽可能成为系统瓶颈，我们为数据访问提供了统一访问接口(DateBase Access Interface)，通过将数据库访问服务构建在J2EE平台上，由应用服务器提供数据并发访问控制和事务的支持。应用服务器通过配置方式来建立数据库访问环境，并通过容器来管理数据库的连接，支持系统对数据库频繁的访问。同时，我们在数据访问层提供数据的存储过程访问和数据的缓存方法，减少网络流量，提高数据处理效率，降低了数据库服务器成为系统瓶颈的可能。

集成性是增强工作流系统的可扩展性的一个重要的方面。而Webservice的出现为应用的集成提供了一个统一的解决方案。J2EE作为主流的Webservice开发平台之一，实现了开放的Webservice服务的开发。在企业中的应用资源往往形式多种多样。我们都通过任务服务器的服务调用适配器对应用进行统一的调用。应用都使用Webservice方式包装发布，例如在J2EE平台上应用一般使用EJB (Enterprise JavaBeanTM) 实现。应用以EJB的方式实现之后，仅需为其编写描述文件，部署到应用服务器上，并将描述文件发布到UDDI注册中心，其他的应用就可以找到这个应用的描述文件，并按照描述文件描述的访问方式（如SOAP协议）和接口调用这个服务。对于企业现存系统、遗留系统和erp系统等，可以使用Web服务适配器将它们集成到Web服务模型中。Web服务适配器一般是一个包装成Web服务的Java应用程序，它用J2EE连接器使得遗留应用能被小服务程序（Servlet）和JSP访问，或者被远程系统通过SOAP访问。

通过Web servcie方式，不仅可以将企业中各种类型的应用进行包装，作为工作流可调用的应用(Workflow Based Application)；还可以将整个流程包装成Web service方式，将流程作为服务的实现者，作为领域的资源提供给外界使用。这样，实现了企业中分散的资源的集成功能。

基于Web的工作流系统已经成为一种趋势，许多供应商纷纷开发新产品或者在原有的产品的基础上增加对Web的支持[4]。使用Web方式实现工作流的客户端应用，用户可以方便的获取自己的任务列表和工作项，能够完成任务项的管理功能和任务的执行功能，大大提高工作流系统的实用性。在我们系统中，通过任务服务器提供了对Web方式的任务控制的支持。任务服务器在后台使用EJB实现任务处理逻辑，通过Servlet实现用户的交互控制。一方面，通过Web客户端JSP程序与客户进行交互，完成对流程的部署，启动和任务队列的管理等功能；另外一方面，使用预定义的HTML页面，JSP程序等，实现和客户的交互过程，完成流程运行时的数据获取等功能，协助流程的人工活动执行。

来源：CCW