工作流管理系统

3.4　工作流管理系统

如果说操作系统、数据库管理系统已经进入“天下初定，诸侯割据”的时代，那么工作流管理系统（Work Flow Management System，WFMS）则还处于群雄逐鹿的阶段。

早在中世纪，一般僧侣的工作就是坐在桌旁认真抄写经文，而较高级别的神父的工作则是布置并分配所要完成的任务，他们会将这份工作中最精彩的部分交给最有才华的艺术家；将校对的工作交给最博学的长者。

几个世纪过去了，这项工作就这么一直延续着没有发生多大的变化，依旧是由神父根据工作的性质、僧侣们个人的能力和不同的经验水平将不同的工作分配给不同的人。最开始，所有的工作只能由人工来完成；慢慢地发展到后来，人们逐渐可以利用一些辅助工具诸如打字机、打印机、加法机等设备来协助完成任务；再后来，随着技术的发展，在一些领域内，机械自动化逐步地取代了人工。即使这样，即一件工作的执行过程中至少有部分是由机器自动完成的，但管理工作还是没有发生多大的变化：依旧是神父分配工作然后监督工作的执行。而神职人员的任务则是将所要完成的工作从一个地点转移到另一个地点，并将工作的进度详细地记录下来，以便在发现问题后易于找到症结所在，也为正确评估生产能力提供了有效的途径。通过这种方法，调查小组的人员就可以根据整个工作的流程查找错误并发现问题，使得整个工作有序的进行下去。

在这个场景中，大部分体力工作都被机械自动化所取代，但管理工作一直是由人来完成的。随着计算机在企业中的应用日渐深入，人们希望把越来越多的工作交给计算机来完成，尤其那些记录工作状况、分配工作任务、监督任务执行之类日复一日、具有很大重复性的管理工作。这些工作正是工作流管理系统的基本工作。

3.4.1　工作流及工作流管理系统

工作流技术最初来源于办公自动化领域。

流通常反映了一种变化以及变化的过程，在企业的经营管理与生产组织中，可以表示物料传输过程的物料流、资金流动的资金流、反映信息处理和传递过程的信息流、价值流、控制流、决策流等。在企业中，同样经常会出现一项工作由几个部门串行或并行共同完成，如零部件在不同部门之间流转，进行加工装配；一个保险申请在保险公司不同职员间流转，直至最后审批通过或拒绝投保……工作流正是用于描述企业活动及活动之间变化的业务过程。

作为一个新的管理应用尝试，工作流产品出现在20世纪80年代中期，一些企业、公司建立了自己专用的或者可商品化的表单传递应用系统。这种系统可看作现在工作流管理系统的一个雏形。之后，一些软件供应商把图像扫描、复合文档、结构化路由、实例跟踪、关键字索引以及光盘存储等功能结合在一起，提供一种全过程支持某些业务流程的集成化的软件（包），这便是早期的工作流管理系统。

不同的研究者根据各自的理解，提出了不同的工作流定义。Georgakopoulos认为工作流是将一组任务组织起来完成某个经营过程。在工作流中定义了任务的触发顺序和触发条件。每个任务可以由一个或多个软件系统完成，也可以由一个或一组人完成，还可以由一个或多个人与软件系统协作完成。任务的触发顺序和触发条件用来定义并实现任务的触发、任务的同步和信息流（数据流）的传递。IBM Almaden研究中心认为工作流是经营过程的一种计算机化的表示模型，定义了完成整个过程所需用的各种参数。这些参数包括对过程中每一个单独步骤的定义、步骤间的执行顺序、条件以及数据流的建立、每一步骤由谁负责以及每个活动所需要的应用程序。类似的定义还有很多。1993年工作流管理联盟（Work Flow Management Coalition，WFMC）成立之后，为工作流提出了较为权威的定义，即工作流是一类能够完全或者部分自动执行的经营过程，根据一系列过程规则，文档、信息或任务在不同的执行者之间传递、执行。这里隐含着由计算机技术作为底层支持。

1995年1月，工作流管理联盟（WFMC）公布的工作流管理系统的参考模型，更是为工作流应用技术从软件实现的角度定义了标准接口，以期达到工作流技术的理想——在企业内外进行面向过程的管理和控制。

3.4.2　工作流应用的系统定位

在企业信息系统环境中，建立在裸机之上的第一个软件系统是计算机操作系统，它是人机之间的第一道桥梁，通过操作系统，普通用户才能利用计算机为其工作。操作系统是最早标准化的软件产品，除微软系列操作系统之外，UNIX、LINUX等在企业中也有广泛应用。由于操作系统的多样性，也就要求其上的系统软件具有异构特性，即要能在不同操作系统环境下运行。工作流管理系统、数据库管理系统、其他软件工具以及各类设备驱动程序都是直接安装在操作系统之上，为其上的应用软件构造应用环境的。

企业应用环境系统是建立在系统环境之上，针对企业业务特殊性而开发的软件系统。典型系统如企业的管理信息系统、客户关系管理系统以及辅助生产、辅助设计的计算机应用系统等，它们都独立完成企业的某些功能。工作流应用系统则不同，它贯穿企业主营业务始终，和企业其他业务系统都要发生联系。企业工作流应用系统是实例化的企业经营过程的缩影，每种实例化的工作流反映企业对一种问题的解决方法和手段。因而，工作流应用系统需要调用或启动企业其他的应用系统，注重监控任务的执行情况，如是否出现异常情况，是否需要人工干预等；对于其他应用系统反馈的任务执行结果进行分析，决定如何导航、如何推进流程继续执行下去，也因此工作流应用系统被称作企业的业务操作系统。图3-14是对上述定位的图形化描述。

图3-14　企业计算机应用环境

工作流管理系统定位于实现工作流管理的核心理念和功能，为在企业内实现过程管理提供系统软件支持。在通用的工作流管理系统之上，企业根据各自不同的经营过程，定义本企业的过程模型，在工作流引擎中进行工作流实例化，得到工作流应用系统。

综上所述，工作流技术是过程管理的计算机实现。它首先是面向经营过程的，其目的是经营过程总体效益最优，与传统面向应用的系统相比，它更要求打破原有面向功能的树形组织结构、扁平式或网络式的组织结构。其次，工作流技术需要大量计算机底层支持，这不仅表现在其核心软件——工作流引擎——对任务的调度、分配，对过程执行的监控和导航（有时工作流引擎本身也是分布异构的，彼此之间也需要协调、通信），还体现在它需要在分布异构的环境下与所有可能的企业计算机应用系统兼容或通信，记录和分析监控信息，及时触发预警，在必要时刻采取一定的应对措施。而这些内容和技术中大部分本身在计算机领域也是待深化待解决的技术难题。最后，工作流技术涉及资源的协调问题，这里的资源包含人力资源和物资资源。它只关心一个工作由谁来做，需要哪些资源，启动的初始和终止条件是什么，而不关心这个任务怎么做。工作流应用系统是工作流技术的企业实现。

3.4.3　工作流管理系统组成

工作流产品发展初期缺乏统一标准，从术语的定义和使用、系统结构的设计到与应用之间的接口规范，都存在较大差异，导致工作流产品之间、产品与其他应用之间的集成十分困难，阻碍了工作流产品的推广和发展。

1995年，工作流管理联盟公布了工作流管理系统参考模型，建议工作流管理系统应该包括工作流模型和建模工具、工作流执行服务与工作流机、系统管理与监控工具、工作流客户端功能，以及被调用的WAPI五个部分和五个接口，如图3-15所示。

图3-15　工作流参考模型

（1）工作流模型和建模工具

企业的工作流模型，实际上是企业完成某个经营过程的一个缩影。企业管理人员，从企业利益出发，制定某个经营过程由企业中哪些成员参加、需要哪些资源和条件。这样描述的企业经营过程，就是企业工作流模型的逻辑描述。

如同任何信息化过程一样，企业工作流模型的逻辑描述需要转化为一些计算机能够识别的标准模型形式，工作流管理系统识别之后才能依次执行下去。这一标准模型形式就是工作流模型。工作流模型包含了描述一个能够由工作流执行服务软件系统执行的过程所需要的所有信息。这些信息包括过程的开始和完成条件、构成过程的活动以及进行活动间导航的规则、用户所需要完成的任务、可能被调用的应用、工作流机的引用关系，以及所有与工作流相关数据的定义。通常，在工作流参考模型中，工作流建模工具完成这一工作。所谓工作流过程建模工具，即以计算机能够处理的形式进行过程的定义。

可见，工作流模型是由企业管理人员根据企业具体情况制定、相关人员通过过程定义工具来定义的。过程定义需要引用组织/角色模型中关于组织结构、组织中的角色等信息，指定完成某项活动的组织实体或角色，而不是具体的人员。

描述工作流模型的工具有多种，比较常见的有基于活动网络的过程模型、基于语言行为理论的工作流模型、事件驱动的过程链模型、基于Petri网的工作流模型、工作流事务模型等，这里就不一一介绍了。图3-16是用Petri网对保险申报工作流程的工作流建模的例子；图3-17是用基于活动的建模技术对订票过程进行建模的例子，该例子中每个节点表示一项工作，并标注了完成该工作的组织角色和时间期限。

（2）工作流执行服务与工作流机

在工作流执行环境中，工作流执行服务负责将组织实体或角色功能与特定的参与者连接。

工作流执行服务与工作流机是WFMS的核心，是企业经营过程的任务调度器，某种程度上也是企业资源分配器。工作流执行服务由一个或多个工作流机（Work Flow Engine，也叫作工作流引擎）组成，提供过程实例执行的运行环境。工作流执行服务主要功能如下：

图3-16　用Petri网对保险申报工作流建模的示例

图3-17　用基于活动的建模技术对订票过程进行建模示例

①实例化并执行过程模型（接口1）。工作流执行服务（工作流机）需要解释企业经营过程的过程定义，根据过程执行需要的初始条件和参数生成过程实例，运行过程实例并管理其运行过程。

显然，一个过程模型实际上是企业经营过程的一个模板，可以被执行多次，也可以有多个关于这个过程模型的实例同时运行。如订单处理过程。

为此，工作流管理联盟定义了工作流参考模型中的接口1。接口1描述了过程定义的输入与输出接口。这个接口为在不同物理或电子介质之间传递过程定义信息提供了交互的形式和API调用函数，能够实现工作流定义阶段和运行阶段的分离，而且是能使不同的工作流产品实现协作运行。

②为过程和活动的执行进行导航（接口5）。工作流执行服务（工作流机）根据过程的进入和退出条件启动和终止一个过程实例；根据活动之间的关联和活动的执行条件，决定并行或串行执行后续活动；给用户提供需要操作的工作流任务项信息；根据所需激活的应用程序信息启动相应的应用程序等。

③与外部资源交互完成各项活动。与外部资源交互由接口2和接口3共同完成。其中，接口2是客户应用接口方式，属非自动化活动，通过任务项列表管理器对应用的执行进行管理，记录监督工作项完成情况，修改反馈信息；接口3是直接调用应用接口方式，是自动执行接口，由工作流机直接调用相应的应用来完成，执行完毕需要把反馈信息传回工作流机。例如设计图纸电子会签后的版本发布与归档。

④维护工作流控制数据和工作流相关数据，包括不同过程和活动实例的内部状态信息，以及用于协调和恢复的各种检查数据和恢复/重起信息，用户传送的必要的相关数据，本功能也属于接口5定义的功能。

⑤分布式的工作流执行服务中，不同工作流机之间存在大量协作工作，因此工作流机需要翻译和解释协作工作流机发来的信息。工作流管理联盟在这里定义了接口4，它包括一个共同的命名机制，支持共同的过程定义对象和属性，能够传递相关的工作流相关数据，并控制过程实例的生成，能够在异构的工作流机间传递过程、子过程及活动信息，支持共同的管理职能等。

综上所述，工作流机主要完成了对过程定义的解释，控制过程实例的创建、激活、挂起、终止；控制活动实例间的转换，包括串行或并行操作、工作流相关数据的解释等；提供支持用户的接口，维护工作流控制数据和工作流相关数据，在应用或用户间传递工作流相关数据；提供用于激活外部应用程序和访问工作流相关数据的接口，提供控制、管理和监督工作流过程实例执行情况的功能。

工作流管理联盟除了制定了工作流管理系统的参考模型，还提供了一定数量的API函数，这些函数以参考标准的身份出现，为工作流管理系统的研发提供了便利。

（3）系统管理与监控工具

工作流管理联盟在标准参考模型中建议包括用户管理、角色管理、资源控制、过程监督功能等，并建议通过接口5定义的API函数与工作流执行服务（工作流机）进行交互，如图3-18所示。

（4）工作流客户端功能

工作流管理系统的客户端要执行WFMS分配的任务或活动。通常这部分要由工作流任务表管理器和用户操作共同完成。

工作流任务表是分配给一个特定用户（或一组用户）处理的任务项组成的队列，工作流任务表管理器是一个软件模块，负责管理任务表，并完成与最终用户的操作进行交互。该软件可以作为WfMS的一部分提供给用户，也可以是用户自己编写的程序。工作流管理联盟发布的工作流参考模型中还特别说明了工作流任务表的几种实现模式，如图3-19所示。

图3-18　管理工具和接口

图3-19　工作流任务表的实现模式

3.4.4　工作流管理系统与企业其他应用系统的关系

企业计算机应用系统涵盖了计算机管理信息系统、辅助产品设计系统以及辅助生产控制系统等，以下从几个方面与工作流应用系统进行对比：

（1）系统目标不同

传统企业计算机应用系统是为了尽可能地用计算机应用替代原有的手工操作，完成某种企业功能，如销售记录登记，销售报告汇总等。因而在这类系统中，通常是以企业内各功能部门为描述对象，把各个功能部门的手工操作模型化，以计算机为工具实现自动化或半自动化操作。

企业采用工作流应用系统，是为了理顺企业内部的管理流程和环节，进行企业内资源的合理调配，推进各个功能环节之间的自动化。工作流应用系统的出发点是企业经营的全过程，在工作流应用系统设计人员眼里，只有企业的最终经营目标，以及实现这一最终目标的过程和方法。他们在实例化工作流应用系统的时候，会充分考虑到每个活动的资源要求和启动、终止条件，在工作流引擎中推进其执行。

（2）核心技术不同

传统的企业计算机应用系统的核心技术是数据库技术，其目的是把大量企业信息记录下来，其核心软件是数据库管理系统。数据库技术有严密的数学理论基础，其基本操作查询以及增、删、改记录都与关系代数中的关系操作对应。严密完备的数学理论基础使得数据库技术在计算机实现上得到了标准化，出现了一大批支持数据库核心技术的管理软件——数据库管理系统，如Oracle，DB2，SQL Sever等；著名的标准查询语句（Standard Query Language，SQL）通用于任何一个数据管理系统，开放式数据库互连接口（ODBC）进一步加强了数据库应用系统之间的互通互连。

与数据库技术相比，工作流技术的核心功能过程导航、任务推进至今并无完备的数学基础。很多学者试图利用Petri网来进行工作流建模的理论论证，市场上也出现了多种执行工作流核心技术的软件产品——工作流管理系统，但由于彼此之间缺乏标准性，很难达到互通互连，这一点大大限制了工作流技术的推广和使用。

除了有较高的软件间互通互连要求外，工作流应用系统还对网络支持有较高的要求。目前，企业的信息系统都是建立在分布式的环境下，工作流应用系统掌管流程的推进，负责把任务分配给下一个过程的执行者，在过程执行者之间进行信息传递，都需要有网络技术的坚强支持。

（3）灵活性不同

在传统的企业计算机应用系统中，过程管理被融入业务处理系统，很难适应企业的流程变化。工作流应用系统可以通过流程的再定义，灵活地重组其应用系统组件，快速完成企业整个系统的搭建。这是由于工作流管理能实现应用逻辑与过程逻辑的分离，可以在不修改具体功能实现方式的前提下，通过修改过程模型来改进系统性能，从而实现对生产经营过程部分或全部的集成管理，并且提高软件的重用率。

（4）企业决策者对系统的参与程度不同

传统的企业计算机应用系统中，参与系统运行的大部分是具体操作人员，企业决策人员即使进入系统也只是查询相关信息，而不是参与企业系统来行使决策职能。这样的工作方式把企业决策者放在了系统之外。而在工作流应用系统中，所有与业务流程有关的人员都会被纳入到系统中来，企业决策者作为系统中定义的角色将履行审批、决策等职能。

3.4.5　常用工作流管理系统

作为业务操作系统的工作流应用系统需要与企业已经建立的多种信息系统进行信息交换，这无疑增加了开发基于原有企业信息系统的工作流应用系统的技术难度。目前还没有非常强势的工作流管理系统。欧美在工作流领域起步较早，出品的工作流管理系统也相对较多，但对中国用户来讲都相对遥远和陌生，例如较有名气的Staffware，TeamwareFlow，IBMWebSWF，OracleWorkflow等；近年来，国内也出现了多家工作流产品厂商，如针对中小企业管理办公业务的“金和办公软件”、“明基协同办公管理软件”等，它们结合中国企业实际情况开发出不少优秀的作品。除了软件厂商开发的有偿软件外，软件爱好者们也开发了一些性能较好的开源工作流引擎产品，如OpenWFE、Shark、jBPM等。

这里简单介绍一下这几款开源工作流引擎。源代码开源具有很大的灵活性，开源产品源码本身就可以审查，通过网络的公开性，使来自于不同领域和区域的开发者参与进来，共同完成项目的开发，所有的缺陷都完全暴露出来，每一个参与者既可以做使用者，也可以做源代码的修正者，这样就减少了软件本身的漏洞，提高了系统的安全性，并可以加入自己的签名机制；开源产品允许在前人的基础上进行开发，不需要从头开始，软件技术的发展将会比以往快很多，方便了软件技术的交流并促进了软件技术的持续发展。

（1）OpenWFE引擎

OpenWFE是基于J2EE的工作流平台，因此能充分利用J2EE平台所提供的所有特性和优势。通过使用和扩展工作流管理系统所提供的类库和配置文档创建业务管理系统，使因业务流程、组织结构等变化引起的系统开发工作变得简单、快速和直接。

该工作流管理系统符合WFMC提出的工作流参考模型的体系结构。它由一系列组件构成，包括工作流引擎、工作列表处理器、反应器、Web客户端和流程定义工具。具体体系结构如图3-20所示。

图3-20　OpenWFE的体系结构

客户端分为两类客户：一类是管理员，另一类是普通用户。管理员通过管理员用户界面建立工作流模型并管理；普通用户则通过Web界面完成一般的工作流节点所要完成的工作。工作流管理系统中各组件协调完成业务流程的处理。

工作流引擎是执行系统的核心，它相当于操作系统的内核程序。管理员通过Web客户端启动某一业务流程激活工作流系统，工作流引擎开始工作，它依据在设计阶段对流程的定义进行流程实例的创建，把流程实例动态地分配给人、应用代理（Agent），或人与应用代理共同完成。同时，根据当前业务流程相关数据（如流程实例的触发条件值、状态值及与过程相关的数据值）进行流程的运行控制。工作流引擎还跟踪工作项的执行状态，维护工作流系统的控制和审核数据，这些数据包括工作项的状态、历史记录、异常情况的记录。

工作列表处理器确保工作项被分配给参与者。当工作项被分配给某人后，便出现在赋予这个人的角色store内，store中包含那些仍然需要被执行的任务列表。通过从store内选择一个工作项，这个人就可以执行该任务。通常一个角色分配一个store，store中存储不同用户的任务列表，用户不是直接的参与者，通过配置文档worklist/passwd.xm l将角色及流程授权给某用户。

反应器管理应用代理（Agent）的调用和返回。Agent是内部流程中各业务活动的具体执行者，如将工作项的数据写入数据库中。这些业务活动有的可由Agent自动完成，有的需要在工作人员的干预下由Agent完成，其中工作流引擎和各Agent之间就是通过反应器调用和控制。

Web客户端关心的是如何将工作列表处理器中存储的工作项显示给每个用户；如何将流程中的数据显示给用户处理；如何对用户的操作请求进行处理。客户端表示使用HTML文件格式，结合JavaScript技术和Jsp/Serverlet技术来实现。

基于Web的流程定义工具是一个相对独立的工具，管理员可以通过图形化的工具建立业务模型（业务流程），或直接从业务模型库中选取适合的业务模型，业务模型描述被转换为xml文档，也可直接编辑xml文档进行业务模型描述。业务模型描述支持嵌套的业务模型，也就是说，业务模型的每一个活动本身又可以是一个完整的子业务模型。该系统使用XML Schema来描述xm l文档的合法结构、内容和限制，定义了可共享的词汇表，使用这些词汇表的xml文档结构并提供了它们之间的联系手段。

图3-21　客户端应用程序及配置

（2）Shark引擎

Enhydra Shark（简称Shark）是一个著名的开源工作流引擎，它完全基于工作流管理联盟（WFMC）和对象管理组（Object Management Group，OMG）标准。其源代码开放，便于使用者借鉴其内部架构和实现方式。Lutris公司在其开源网站http://www.enhydra.org上发布了这一工作流系统框架，在http://Shark.Objectweb.org上可下载各个版本的执行程序和源代码。Shark主要由服务器管理控制台、包管理器、持久层服务、日志管理器、流程库、过程实例运行模块、客户端等功能模块组成，每个组件都是按照标准实施的，而且可被具体项目的模块扩展和替换。

目前，工作流引擎大部分采用了微内核的原则，就是尽量将引擎所需的服务与引擎内核调度计算分离。通常情况下，一个微内核工作流引擎，都或多或少包含七个层次：外设层、对外接口层、交互代理层、引擎内核处理层、引擎运行服务层、扩展实现层、基础组建层。Shark主要有几种组件：Kernels（引擎内核层）；Plugins（服务层和扩展层）；Wrappers（对外包装层，类似外设层）；Tool Agents（一些应用程序的处理，内容基本上属于扩展层）。Shark的内部调度机制不是很复杂，整个调度方法也基本上是基于WfProcessImpl类的run方法，采用的是遍历循环的方式。它的遍历是遍历已经完成的活动实例，然后往下推进。Shark的run调度方法，是比较常用的调度机制，因此，Shark很难支持复杂的运行模型。

Shark具体体系结构如图3-22所示。

图3-22　Shark内部配置

Shark完全遵循WFMC标准和规范，其流程定义语言采用XPDL，XPDL中的Activity是基于UML1.x中的活动图的概念，活动图天生适于工作流程建模，相对于状态图，它的一个最大的优点是容易做并发线程的分叉控制；缺点有不能很好地支持复杂应用，由于是开源软件，还有很多细节问题未考虑好，而且它的架构很庞大，需要独立运行一个工作流引擎服务。