张瀚文的空间

我们一直在努力....

平台工作流引擎调研

标签: 工作流 JPBM osWorkFlow

平台工作流引擎调研

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的学习成本,可能使用起来反而比较方便。

    评分: 请先登录再投票,同一篇博客一月只能投票一次!
    无人投票

评论


发表评论

最近访客
关注此文的人们还关注