调研 工作流比较表格

工作流系统关键技术

比较

2012/12/20

目录

工作流系统关键技术比较 (1)

2012/12/20 (1)

目录 (2)

一、消息驱动和事件驱动工作流的区别与应用 (4)

二、典型工作流过程定义语言规范的特点与应用 (5)

过程定义语言BPEL/BPMN2/XPDL/BPML/JDPL (5)

语言功能的比较 (5)

语言结构的比较 (6)

语言具体细节的比较 (7)

其他比较 (8)

三、典型工作流引擎的功能、结构比较 (12)

1．jBPM3 (12)

2．向BPMS努力的jBPM4 (13)

3．jBPM5 (15)

4. Activiti5 (16)

5．微软工作流 (19)

6．小结 (23)

四、基于Web服务的工作流管理系统 (23)

4.1概述 (23)

4.2基于Web服务的工作滚模型 (23)

4.2.1符合Web服务的工作模型 (24)

4.2.2基于Web服务的工作流管理系统 (25)

4.3 Web服务在工作流中的应用 (27)

4.3.1 Web服务作为工作流的任务 (27)

4.3.2作流作为Web服务的实现机制 (27)

一、消息驱动和事件驱动工作流的区别与应用

基于“消息驱动”和“事件驱动”的工作流都可应用于一个可行的分布工作流系统。

信息传递的分布工作流系统强调了每个节点的功能独立性，使得一个节点的失败只影响到与该结点有关的相应工作流实例或者某一个工作流步骤，从而将影响范围缩小到最小范围，使得系统构造方面有了更好的升级性和适用性，但是它没有提供事件的历史记录，所以该机制现在正在研究如何使用日志文件来管理工作流，并尝试用非连续性的消息驱动来提高性能。信息传递的分布工作流系统目前主要应用于金融支付系统、电子商务系统（如淘宝等）。

事件驱动的机制主要是开发了Brokers/Services模型和EVE平台，从而将分布式工作流的实行分为3步：首先由高层的图形界面提供工作流建模工具，然后由中层的Brokers/Services模型执行工作流，最后由底层的EVE平台提供分布式工作流的实行框架，主要负责事件管理、历史记录和工作流执行者之间的交流。B/S模型提供了一个较完善的语言定义机制，保证建模人可以了解工作流执行者的实际行为，组成工作流说明的工作流执行过程可以被正确定义，工作流执行过程的准确性得到保证，工作流执行完毕后的分析也成为可能。但是，对于活动的工作流或者正在运行的组成部件进行修改所带来的影响还没有得到很好的解决，这将是以后的研究方向。事件驱动的分布工作流系统主要应用于医疗保险信息系统、集装箱物流信息系统

发送流程消息

消息驱动模式

用户登陆系统后，向服务器端提交Http Request 请求，接受消息线程后初始化该用户的上下文环境，读消息线程到接受队列中检索属于该用户的消息，并反馈给用户，用户查看消息后可以进行消息处理（这里的消息其实就是用户的任务列表的描述）。当用户处理消息时，依据业务规则对消息进行处理，此时消息

接受队列将用户发送的消息，自动转发到消息管理池中去，等待消息轮询查找和调用。

二、典型工作流过程定义语言规范的特点与应用

过程定义语言BPEL/BPMN2/XPDL/BPML/JDPL

BPML 和XPDL 及BPEL4WS 都是基于XML 的过程定义语言, 它们提供了一个正式模型来表达企业商务过程中的可执行过程。

XPDL 是工作流管理联盟( The Workflow Management Coalition, WfMC) 基于XML 定义的XML 过程定义语言( XML Process Definition Language)；

XPDL 构成了WfMC 工作流标准的Interface；

商业过程建模语言( Business Processes Modeling Language, BPML) 是BPMI 组织( The Business Process Management Initiative) 提出的一种新的过程定义语言, 用来全方位的描述企业商业过程中抽象的可执行过程, 其中包括基于Web Services 的某些特殊的领域。

Microsoft 的XLANG 和IBM 的WSFL 同样也是过程定义语言中的分支。

2002 年8 月, Microsoft/IBM 发布了一个新的规范: BPEL4WS, 它结合了XLANG 和WSFL。XLANG 和WSFL 共同构成了BPEL4WS( The Business Process Execution Language for Web Services)

语言功能的比较

XPDL、BPML 都基于XML 分别提出了一个用于表达企业商务（电子商务）过程的抽象模型, 这是一个工作流过程定义的元数据( metadata) 模型。在这个正式的模型中定义了各种复杂的活动、事务及事务补偿、数据管理、异常处理及操作等语义。基于元数据模型, 特定供应商的工具能够借助通用交换格式交换不同的异质系统中产生的工作流定义。由此提供了通用的方法描述和访问工作流定义, 并可以轻松实现不同的异质系统之间工作流定义互换的操作。

BPEL4WS 提供了一种XML 注释和语义, 用于指定基于Web Services 的业务流程行为。使用合作伙伴的交互方式, 定义业务流程。合作伙伴可以将服务提供给流程, 也可以向流程请求服务, 或者参与到流程的双向交互中。BPEL4WS 对每个服务分配了合作伙伴的责任, 同时指定了一组Web 服务操作的可能执行顺序、这些Web服务间共享的数据、业务流程涉及哪些伙伴以及这些伙伴在业务流程中扮演什么角色、一组Web 服务的共同异常处理以及关于多个服务和组织是怎样参与的等问题。

从语言的功能来看, BPML 和BPEL4WS 重点致力于Web Services 的定义,

反映在以下3 个方面:

(1) 活动类型明确划分为消息交换、事件处理、补偿校正、延迟指定等类型。

(2) 活动的属性支持实例的相关性、消息部分的抽取、服务实例的定位。

(3) 支持事务, 异常处理和补偿校正。

XPDL 则重点致力于分布式工作流的相关领域。这主要体现在以下两个方面: （1) 活动属性中明确规定了一项活动执行所需的资源。这是一个表达式, 在系

统运行时计算, 用以决定所需的资源。

(2) 活动属性中明确规定了完成一项活动所需的应用程序。

这表明XPDL 在语言层面上支持工作流程推进过程中的人工参与, 强调系统

运行期间的人机交互活动。

语言结构的比较

BPML 被设计为一种块结构( block-structured) 语言。递归的块状结构在作用域( scoping ) 概念中起关键作用。流程控制( 路由) 完全用块结构概念进行处理( 例如: 顺序执行块中的所有活动) 。

XPDL 被设计成一种有向图结构( graph-structured) , 再添加了一些其它的概念来处理块。作用域( scoping)体现在包( package) 和过程( process) 的层次上。过程( process) 定义不能嵌套。“路由”由活动( activities) 之间的迁移来处理。一个过程中的活动可视为一个有向图中的节点, 而迁移作为有向图中的有向边。迁移条件在系统运行时决定下一步该执行的活动。

BPEL4WS 也是一种块结构的语言。允许定义递归的块, 但是限制在顶层进行定义和声明。在一个块内, 有限支持有向图流程的概念。具体地说, BPEL 只有非循环图, 因此没有循环(loop) 。

BPML 在定义和声明中广泛使用块结构。复杂活动引用上下文关联的活动集。在上下文中可以声明或重声明属性, 定义或重定义过程( 嵌套过程) 。这些属性和过程被它们所在区域的上下文限制了作用域。具体包括: 错误处理, 事务处理, 用于消息处理的连接器。由于活动集中可以有复杂的活动, 这样嵌套循环得以实现。

XPDL 只允许在顶层定义过程, 因此没有嵌套的过程。由于工作流相关数据同样在顶层定义, 或在一个过程中定义, 因此它被限制在这两层范围内。

BPEL4WS 不支持嵌套过程的定义。工作流相关数据的等价物: 容器( container) 是全局数据。

XPDL 中的块活动( block activity ) 如同BPML 中的复杂活动。它有属性可以指派复杂活动类型, 以及定义一个活动集上下文的信息。上下文中的data field 声明, 可以起到BPML 中作用域的效果。为了实现嵌套过程,过程定义也需要被包含进来。BPML 中有关复杂活动的很多特性在XPDL 中都可用块活动替代。块活动通过引用活动集( 这种活动集没有向活动集外的迁移活动) 的名称来执行活动集。BPML 定义的所有活动如果要转换为XPDL 的活动, 可简单地在XPDL 活动集中引入一个起始活动和一个结束活动, 这里起始活动是一个与分支( and split ) , 结束活动是一个与连接( and join) 。从起始活动到块内的其它活动, 和从该块中的其它活动到结束活动之间有时可能需要一个迁移条件。因此, 虽然XPDL 不似BPML 有嵌套过程, 但它包含的块活动和活动集可以灵活地扩展实现现BPML 的复杂活动。

语言具体细节的比较

语言比较

项目BPML

XPDL BPEL4WS 包package

package 无对应的数据结构嵌套过程Nested process

在一个上下文中定义

如: 一个顶层过

程）。

需要包含一个块活动来实现无对应的数据结构过程Process

Workflow Process Process 外部引用Import

ExternalPackage Import 活动集ActivitySet 一个上下文和一个

活动集关联。在一个上下文的

实例中,属性共享。作用域被阐

明Activityset 这是除过程外, 关于活动组的唯一数据结构作用域( s cope) 用来连接补偿处理和故障处理。复杂活动Complexactivit

y 复杂活动

由一个或多个活动集

组成

blockactivity 块活动 活动集通过名称对其进行引用structuredactivities 构造活动活动

BPML

具有大量不同类型的原子

活动和复杂活动( 共有17

种活动类型)XPDL 用活动的属性来表示不同种类的活动3 种语言的高层数据结构对照

语言比较

项目BPML

BPEL4WS XPDL 动作Action 实现了

WSDL 的消息模

式：单向请求

应答公告

receive, reply, invoke( 接收, 回复, 调用)它们用来处理WSDL 的消息模式需要扩展附加的属性( 和应用程序/ 工具、库功能相关性Correlation

用来匹配消息给

正确的过程实例

。

Correlation 工作流相关数据是实例的具体描述。相关性属性用以标示关联属性。服务定位器locator

用来发现适合的

服务。参考WSCI

规范

Servicelink,par tners,servicere ference 服务连接,合作者,服务引用不支持调用call 一个行动可以完成任意

一个活动集的唯一条件

是:

行动语义上要求这些活

动按顺序执行,特别是

当执行WSDL 的请求-响

应操作不支持不支持

消息输出output 用来从状态特

征值构造息。propertyalias, assign, query, contain er

特征值别名,

赋值, 查询,

容器不支持

3种语言对应元素比较

语言比较

项目补偿处理故障处理compensat e

与上下文中

的一个异常

处理过程相

关联

BPML

BPEL4WS XPDL 与作用域中的一个补偿处理相关联。需要扩展附加属性和库功能Event

handlers t

ime out ,

fault 事件处理

超时故障event handlers, compensat ion handler,fault handler 事件处理, 补偿处理, 故障处理( 用来

连接捕获或抛出XPDL1 0 已扩展包括Deadl ine 的定义及Deadlin e 的异常处理和其

他的异常条件

3 种语言对事务和异常处理的比较

其他比较

BPMN2.0

BPMN2.0相对于旧的1.0规范以及XPDL、BPML及BPEL等最大的区别是定义了规范的执行语义和格式，利用标准的图元去描述真实的业务发生过程，保证相同的流程在不同的流程引擎得到的执行结果一致。BPMN2.0对流程执行语义定义了三类基本要素，它们是日常业务流程的“三板斧”：

?Activities（活动）——在工作流中所有具备生命周期状态的都可以称之为“活动”，如原子级的任务（Task）、流向（Sequence Flow），以及子流程（Sub-Process）等

?Gateways（网关）——顾名思义，所谓“网关”就是用来决定流程流转指向的，可能会被用作条件分支或聚合，也可以被用作并行执行或基于事件的排它性条件判断

?Events（事件）——在BPMN2.0执行语义中也是一个非常重要的概念，像启动、结束、边界条件以及每个活动的创建、开始、流转等都是流程事件，利用事件机制，可以通过事件控制器为系统增加辅助功能，如其它业务系统集成、活动预警等。

这三类执行语义的定义涵盖了业务流程常用的Sequence Flow（流程转向）、Task（任务）、Sub-Process（子流程）、Parallel Gateway（并行执行网关）、ExclusiveGateway（排它型网关）、InclusiveGateway（包容型网关）等常用图元。

现实业务所有的业务环节都离不开Activities、Gateways和Events，无论是简单的条件审批还是复杂的父子流程循环处理，在一个流程定义描述中，所有的业务环节都离不开Task、Sequence Flow、Exclusive Gateway、Inclusive Gateway，其中Task是一个极具威力的元素，它能描述业务过程中所有能发生工时的行为，它包括User Task、Manual Task、Service Task、Script Task等，可以被用来描述人机交互任务、线下操作任务、服务调用、脚本计算任务等常规功能。

User Task:生成人机交互任务，主要被用来描述需要人为在软件系统中进行诸如任务明细查阅、填写审批意见等业务行为的操作，流程引擎流转到此类节点时，系统会自动生成被动触发任务，须人工响应后才能继续向下流转。常用于审批任务的定义。

Manual Task:线下人为操作任务，常用于为了满足流程图对实际业务定义的完整性而进行的与流程驱动无关的线下任务，即此类任务不参与实际工作流流转。常用于诸如物流系统中的装货、运输等任务的描述。

Service Task:服务任务，通常工作流流转过程中会涉及到与自身系统服务API调用或与外部服务相互调用的情况，此类任务往往由一个具有特定业务服务功能的Java类承担，与User Task不同，流程引擎流经此节点会自动调用Java 类中定义的方法，方法执行完毕自动向下一流程节点流转。另外，此类任务还可充当“条件路由”的功能对流程流转可选分支进行自动判断。常用于业务逻辑API的调用。

Script Task:脚本任务，在流程流转期间以“脚本”的声明或语法参与流程变量的计算，目前支持的脚本类型有三种：juel（即JSP EL）、groovy和javascript。在Activiti5.9中新增了Shell Task，可以处理系统外部定义的Shell脚本文件，也与Script Task有类似的功能。常用于流程变量的处理。

JPDL与BPEL比较

1. 流程结构定义：JPDL中定义了一些基于有向图的节点和变换，通过这些节

点和变换来实现流程的定义。而在BPEL中有一些基于XML元素的结构化活动，通过这些活动来实现流程的结构定义。

2. 数据处理：JPDL中的变量是基于POJO(Plain Old Java Object)定义的，流

程中需要进行处理的数据可以通过ContextInstance在外部类中调用。BPEL 中变量是基于xml结构，可以通过assign活动来进行操作。

3. 和流程的交互方式：JBPM提供了一组API，通过调用这些API的方法允许

客户端代码和流程实例的直接交互。BPEL提供了Web服务的接口，客户端通过这些接口来实现和流程实例之间的交互。

4. 服务的调用：JPDL通过action handler来实现和外部服务的交互。在BPEL

中，通过invoke等活动来实现。

A ctiviti5与jBPM5都属于业界优秀的开源工作流引擎，都支持BPMN2.0最新规范，均基于Apache License，符合J2EE规范，提供工作流建模、执行以及对流程生命周期过程监控。但两者设计理念和技术组成却有很大不同，见下表

三、典型工作流引擎的功能、结构比较

1．jBPM3

jBPM3的最新版本是3.2.7，其包括了以下组件：基于Eclipse的流程设计器、用于监控案例（流程实例）和处理任务的Web控制台以及jPDL核心库。如下图2所示：

图2：JBPM3组件

1.基于Eclipse的流程设计器

提供给开发人员绘制jPDL流程图，因为该设计器基于Eclipse，所以生成的流程文件可以与开发代码一起组织管理，非常容易进行单元测试。

Web管理控制台

主要有两个功能：一是作为工作流客户端应用接口，给用户提供一种手段，以处理案例运行过程中需要人工处理的任务；二是对案例的状态进行监控与管理。

2.jPDL核心库

jPDL核心库是一个单独的JAR包，可以嵌入到目标应用中执行，它包括

了：

o流程仓库：解析jPDL流程定义文件并存储读取；

o流程引擎：对流程定义进行初始化和调度执行，节点的运行期行为与jPDL里定义的节点类型一一绑定；

o任务管理：生成任务节点所对应的工作项，管理工作项的生命周期（初始化、分配执行者、执行、挂起、结束、终止）；

o事件管理：发布案例和任务的开始、结束事件，通过监听者模式调用相应的事件处理器；

o异步执行机制：通过线程实现了Job Executor，进行异步工作的处理，这些工作包括了时间处理、异步动作。

o身份组件模型：实现了一套简单的身份组件模型，包括了组、用户和权限。

通过调用自定义Java代码实现了对外部应用的调用。

jBPM3是一个轻量级的嵌入式工作流系统。它在Java社区的成功得益于

两个方面：一是嵌入式，这降低了使用工作流的门槛；二是对开发人员友好，这表现在易读的jPDL、流程的可测试性(Eclipse插件)以及节点行为

的可扩展性，我们可以非常容易的在流程运行中加入自己定制的行为（通过事件处理器和Action）。jBPM3面向开发人员，它解决的问题是流程的自动化，它的影响力集中在Java开发社区，是一个完整的工作流系统实

现。

2．向BPMS努力的j BPM4

与jBPM3相比，jBPM4最大的变化是引入了流程虚拟机（PVM），同时增加了BPMS的特性。jBPM4不再满足于工作流系统的定位，开始向BPMS努力。

1.为什么引入流程虚拟机

尽管jBPM3在Java社区取得了很大的成功，但是有一件事始终被人们诟病，那就是它不支持流程语言规范，从最开始的XPDL、BPEL到后来的BPMN，它采用了自定义的jPDL。在jBPM3中，节点的运行期行为与jPDL里定义的节点类型是一一绑定的，这造成了流程引擎与特定流程语言的绑定，要支持其他的流程语言变得困难。于是在jBPM4中，jBPM提出了流程虚拟机的概念，即流程引擎与流程语言解耦，通过一套通用的流程模型并配以可定制的节点运行期行为实现了对多流程语言的支持。

流程虚拟机带来的好处是多方面的：第一也是最重要的是jBPM4支持BPMN。第二是实现了基于流程组件的流程引擎，流程图(语言)与实现解耦，我们使用通用编程语言实现节点运行期行为，称之为流程组件，通过将流程图与流程组件挂接，避免了图的损耗。在这一点上，Tom Baeyens对BPMN到BPEL的

转换提出了一针见血的批评：BPMN和jPDL以及XPDL都是基于图的，而BPEL 是基于块的，这造成了当将业务人员使用BPMN所建立的流程模型向BPEL执行模型进行转换时，出现许多的不匹配，最初的流程模型会扭曲变形。而扭曲的后果就是业务人员与开发人员之间的协作困难，这影响了流程从业务到技术的实现。

第三个好处是我们可以定义领域特定语言（DSL），在特定的应用里，采用DSL约定并隐藏了大部分的技术细节可能做到业务人员对执行流程的直接修改，例如企业文档管理里的审批流程。

2.BPMS特性的加入

这表现在以下三个方面：第一是支持了BPMN，BPMN已经成为业务人员的流程建模标准；第二是引入了Signavio作为面向业务人员的Web建模器；第三是在已有的Web管理控制台加入了对案例和任务的统计功能。jBPM4的组件如下图3所示：

图3：jbpm4组件

和jBPM3一样，jBPM4依然是轻量级的、可嵌入的工作流系统。相比jBPM3，它将业务人员作为最终用户之一，增加了部分BPMS特性，同时PVM的引入使得它的可扩展性得到了极大的增强，我们甚至可以定义自己的DSL。

在BPMS特性里我们提到了应该避免业务人员的流程建模转换到IT系统时受到损耗，最理想的情况是业务人员与开发人员共用一个流程模型，业务人员能够直接对流程进行调整（在特定应用中，通过DSL是可以做到的）；其次是通过BPMS将业务人员的模型与实际执行的技术模型关联起来（很多商业产品已经做到了这一点，在Activiti5中我们也会看到这一点），业务人员、开发人员以及

运营团队之间能够做到很好的协调；最差是业务人员与开发人员各自为政，独立维护各自的流程模型，并且模型之间存在极大的不匹配，此时流程的迅速变化基本上是奢望。

3．jBPM5

jBPM5依旧定位为轻量级的可嵌入的工作流系统。在jBPM5的特性里，有这么两条引人关注：一是引入了Guvnor作为流程仓库，这解决了流程的可视化问题，流程定义作为资源被管理，我们可以对流程定义进行可视化管理以及全文检索（Guvnor使用了Jackrabbit作为了其存储实现，但我们的经验表明Jackrabbit 在大数据量情况下性能存在严重问题）；第二是规则引擎(Drools Expert)、事件处理引擎(Drools Fusion)与流程引擎的合三为一，这是jBPM5最让人期待的地方。jBPM5的组件如下图4所示：

图4：jbpm5组件

规则引擎在流程中的应用已经非常广泛了，我们这里说说事件处理引擎。事件处理引擎是业务活动监控（BAM）的基础，BAM的功能及执行过程，如下：

?捕获：BAM捕获各种事件（通过消息监听器、适配器、代理等）。这些事件来自应用、系统软件、外部交易伙伴。消息是BAM的核心——它们反应底层业务流程的状况。

?过滤：BAM过滤掉没有直接后果的事件，在很多情况下由支持事件流处理（Event Stream Processing，简称ESP）或复杂事件处理（Complex Event Processing，简称CEP）引擎来进行过滤。

?分析：BAM根据分析模型和规则将相关事件联系起来。

?警告：BAM向用户提出警告，以便用户在必要时进行控制。

如上所示，BAM的执行过程包含四个步骤，而前三个步骤都是对事件进行相关的处理（捕获事件、过滤事件、分析事件、关联事件），因此在大多数BAM 的技术实现方案中，都基于CEP和ESP的引擎来实现BAM的功能。

与jBPM4相比，jBPM5对PVM的放弃也带来了几个不小的问题：第一是对开发人员来说只支持BPMN，不再支持jPDL（当然提供了迁移工具）；第二是流程执行的可扩展性回到了jBPM3的年代，仅仅支持自定义动作（相当于jBPM3里的Action）。此外，Web建模器由Signavio替换为了Oryx Designer。

总而言之，jBPM5通过引入流程仓库和BAM继续向BPMS迈进（目前的进展是与流程仓库的集成还未完成，BAM基于日志进行分析），同时，由于不再支持PVM和jPDL，带来了流程扩展性的降低和社区开发人员的未来流失。

4. Activiti5

activiti5是Tom Baeyens加入Alfresco后推出的新的基于jBPM4的开源工作流系统，发布的第一个版本。Activiti的开发团队相比与jBPM强大了许多，有23位核心开发者。当然这也是由于activiti规划的功能所致：包括核心引擎、Web 的流程建模器、协作工具Activiti Cycle、Activiti Probe、Activiti Explorer、与Spring 的集成、与Mule的集成等。

图5：Activiti5的组件

如上图所示，Activiti5由三种类型的组件组成，分别是：专用工具（Dedicated Tools）、内容存储工具（Stored Content）和协作工具（Collaboration Tool）。

专用工具包括以下：

?Alfresco—Alfresco公司的企业级内容管理产品

Alfresco 是一个开源的、企业级的内容管理系统，功能包括：文档管理、协作、记录管理、知识库管理、Web内容管理等功能。Alfresco与Activiti

的深入集成实现了流程及相关文档的可视化。更重要的是Alfresco支持

组织模型，能够提供在组织结构内进行不同层次之间的流程导航。

?Activiti Modeler—建模器

基于开源Signavio Web流程编辑器的一个定制版本，提供了对BPMN2.0

图形化规范的支持，建模后的流程以文件格式进行存储。

?Activiti Designer—Eclipse插件形式的建模器

?Activiti probe—管理及监控组件

对流程引擎运行期实例提供管理及监控的Web控制台。包含部署的管理、流程定义的管理、数据库表的检视、日志查看、事务的平均执行时间、失

败多次的工作等功能。

?Activiti Explorer—任务管理组件

提供任务管理功能和对案例、任务基于历史数据的统计分析（报表）功能。

Web应用程序。

内容存储工具：包括了文档仓库、模型仓库、SVN仓库、MVN仓库和Activiti

引擎。其中文档仓库、SVN仓库和MVN仓库三个组件为协作工具（Activiti Cycle）提供底层的支撑。Activiti引擎则是以前的PVM。

协作工具：与jBPM4相比，Activiti5最令人瞩目的特性就在于它的协作工具组件。Activiti Cycle完全是一种新类型的BPM组件。它是一个用来促进业务人员、开发人员和IT运营人员协作的Web应用程序。在现实的场景中，业务文档有业务人员所持有，而软件程序由开发团队所管理，被部署的软件应用则被IT 管理人员所管理。三者之间不能很好的协作。我们可以想象这样一个场景，业务经理用文档来维护需求和visio格式的流程图，开发人员管理可执行的流程和大量的Java源文件而IT维护人员则管理部署在Tomcat中的.war文件和存储在Activiti数据库中的流程。

图6：Activiti Cycle协作组件逻辑示意图

Activiti Cycle通过BusinessLink将与流程相关的业务人员、开发团队与IT 维护人员关联起来，实现他们之间的协作。

总而言之，与jBPM4相比，Activiti5目前最重要的增强就是实现了流程的可视化以及创新的Activiti Cycle协作组件，此外，通过与Mule的集成加强了其集成能力。其对PVM的保留使其继承了jBPM4强大的可扩展能力，对jBPM的老用户来说，这是向其迁移的重要理由。

5．微软工作流

微软工作量架构图微软工作流——状态机工作流

状态机工作流概述

?工作流本身由一组状态组成。

?存在一个初始状态。

?每个状态都可以接收一组特定事件。

?视时间而定，可以转换到另一个状态。

?状态机工作流可以有最终状态。

?当对最终状态进行转换时，工作流将完成。

微软工作流----状态机的相关活动

状态机执行相关活动

EventDriven Activity SetState Activity

用于依赖于外部事件开始执行时的状态EventDrivenActivity必须具有实现接口做为第一个子活动的活动

指定到新状态的转换

StateActivity 表示状态机的一个状态，可能包含其他State活动

StateInitialization

Activity 在进入某个状态时执行；可能包含其

他活动

StateFinalization

Activity 在离开StateActivity活动时执

行包含的活动

微软工作流----WF的通信

WF通讯概述

? Windows Workflow Foundation 通信服务使工作流能够使用方法和事件通过消息与外部系统交互。

?事件用于将数据发送到工作流，而工作流使用方法将数据发送到主机应用程序。

?通过事件与工作流进行通信的功能提供了一种将数据发送到工作流的异步方式。

WF页面及表单设计(以某一个业务为例)

1 新建业务流程