平台工作流引擎调研

 

平台工作流引擎调研

1.工作流简述及需求分析

1.1简述工作流

工作流(Workflow)，就是“业务过程的部分或整体在计算机应用环境下的自动化”，它主要解决的是“使在多个参与者之间按照某种预定义的规则传递文档、信息或任务的过程自动进行，从而实现某个预期的业务目标，或者促使此目标的实现”。
工作流管理系统（WFMS），通过执行经过计算的流程定义去支持一批专门设定的业务流程，支持定义、管理和执行工作流程。
工作流管理联盟(WfMC)提出的工作流管理系统参考模型：
核心： 工作流引擎
5个接口：流程定义工具、工作流客户端应用、执行外部应用、其他工作流应用服务接口、管理和监控工具。
模型各模块功能：
工作流引擎：1为流程实例解释流程定义，从流程定义工具获得。2 组织调度流程实例。3 处理工作任务的分配接受提交等。4 管理其他接口
流程定义工具：一段XML，遵循XPDL标准或者其他厂商自定义标准，如 JPDL目的是产生XML格式的流程定义。
工作流客户端应用：提供工作任务列表等客户端应用程序，实现人与工作流引擎的沟通。
执行外部应用：第三方系统集成。支持外部应用参与工作流程。
其他工作流服务：连接不同的工作流引擎和系统。
管理和监控工具：提供监控工具，搜集管理信息，

1.2工作流管理系统需求

       从技术开发的角度上看：
       降低开发风险，通过使用工作流术语，使业务分析师和开发人员使用同一种语言交谈。
流程实现的集中统一，业务流程的实现代码，不在散落在格式各样的业务系统中。加速开发，开发者不再关心流程的参与者、活动节点的衔接、流转控制，工作流框架接管。提升对迭代开发的支持，使业务流程容易部署和重新编排，以一种迭代的方式推进应用开发。
一个好的工作流框架应该有的功能（个人感觉）：
流程控制，消除代码中的if-else switch，驱动业务流，使业务流和工作流分离，重用业务模块。 状态控制，消除状态表中的status，伴随流程流转，在某点的状态都是设定好的，无需关心。 角色控制，消除if(user != null or roles == ‘XX’)这种权限控制。角色或者用户所能获得的任务，能执行的操作，都是在工作流引擎中做过滤判断。

2.开源工作流选型

Enhydra Shark(不考虑)：
       拥有基于java技术，可扩展的工作流引擎，实现了 WfMC规范，使用 XPDL语言定义流程，持久层采用DODS来实现，XPDL语言中的activity基于UML活动图，活动图天生的适于工作流程建模，它相对于状态图的一个最大的优点是容易做并发线程的分叉控制，这些并发线程可以同时执行也可以顺序执行；它还有一个优点是有泳道的概念，可以控制工作流引擎中的任务的产生。不再开源，转为 商业用途。
osWorkFlow：
       由研发 WebWork2的组织 opensymphony下的团队开发，它的重要概念是State，基于FSM，类似理解为状态图就可以了。Osworkflow中的State是由step和status联合表达的，一个State就是一个step中的某个status；而state的转换由action来驱动，类似状态图中的event,因为一个event对应一个action。流程设计器较简陋，基于swing，更新较慢，现阶段已 停止更新，资料较少。
JBPM：
       自定义语言 JPDL描述，或者 BPEL，图形化流程设计器为 Eclipse插件。
它结合应用了 状态图 + 活动图 +PetriNet的知识。持久化层 只能用 Hibernate，换句话说就是和JPA整合非常有难度。它是JBoss SOA。中一个重要组件，与JBoss Drools规则引擎，JBoss ESB企业服务总线配合，提供SOA方案。
JBPM版本：
JBPM3.X：

1. 基于Eclipse的流程设计器。
2. Web 控制台
3. jPDL核心库

JBPM 4.x：

引入PVM流程虚拟机的概念，使流程引擎与流程语言解耦，支持BPMN，增加部分BPMS特性：
第一是支持了 BPMN，BPMN已经成为业务人员的流程建模标准；第二是引入了Signavio作为面向业务人员的Web建模器；第三是在已有的Web管理控制台加入了对案例和任务的统计功能。
JBMP5.x:
JBMP5基于Drools Flow，就是JBoss的规则引擎。

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

如上图所示，Activiti5由三种类型的组件组成，分别是：专用工具（Dedicated Tools）、内容存储工具（Stored Content）和协作工具（Collaboration Tool）。JBPM4相比，Activiti5目前最重要的增强就是实现了流程的可视化以及创新的Activiti Cycle协作组件，此外，通过与Mule的集成加强了其集成能力。其对PVM的保留使其继承了jBPM4强大的可扩展能力，对jBPM的老用户来说，这是向其迁移的重要理由
JBPM 版本总结：
JBPM3是一个完整的工作流系统实现，面向开发人员，目的在于简化对组织核心流程进行支撑的软件创建，不支持标准。
JBPM4引入PVM，使其拥有更强大的扩展性，同时增加BPMS特性，这些特性包括了对BPMN的支持、面向业务人员的Web建模器和简单统计分析功能的加入。
JBPM5基于原先的Drools Flow，支持BPMN，通过与Drools的合并支持BAM，通过内容仓库增加对流程可视化的支持。由于放弃了JBPM4的PVM，引擎的可扩展性受到损害，并且不再支持JPDL。
Activiti5基于JBPM4，与Alfresco的集成增加了其流程可视化与管理能力，同时通过创新的Activiti Cycle协作组件支持流程相关人员之间的协调，最后，它加强了集成能力。
对于工作流应用或者jBPM3、jBPM4的老用户，建议转向Activiti5。
 

3.建议选用及原因

如果持久化直接采用Hibernate的话，建议采用JBPM4.x，因为Activiti5和JBPM5都是新技术，文档和知识不全，稳定性有待考验。但是使用JBPM的风险在于版本升级时，很有可能相互无法兼容，迁移困难。再就是开发时需要大量扩展，同时要保留二次开发的能力。
       如果自己开发工作流引擎，考虑时间风险，但是可以用现成的工作流引擎，自主开发工作流管理平台。现在的工作流平台已经不少了，可以借鉴开发。比起JBPM的学习成本，可能使用起来反而比较方便。