JBPM与Activity分析.doc

概述 这里对现阶段市面上的几个主流工作流引擎进行对比，同时将其与FixFlow进行功能和各方面的对比。这里选定的目标是JBPM和Activit，现在两者必威体育精装版稳定版本分别是JBPM5以及Activiti5。 同时这里会讲讲FixFlow这个国产工作流引擎，对于国内用户来说，使我们在几个国外工作流之外又有了更多的选择。我们可以看到国内的开源流程引擎也可以做到国际级的水平，同时还可以支持加签、会签、回退等这样的“中国式工作流”。 JBPM和Activiti对比 首先先看看JBPM5和Activiti5，这两者现在可以说是国内外最常见到的开源工作流引擎。如果总管两者的发展史会发现两者的奠基人都是来自于一个叫Tom Baeyens的人。所以就会发现JBPM系列和Activiti系列的风格方面有很多相似，而Activiti看起来更像是JBPM的后续发展。 从JBPM3到Activiti5 从架构层面上来看JBPM3的架构为： 从这张图可以很清晰的看出JBPM的技术架构，可以说作为一个工作流引擎应该有的成分：设计器、控制台、流程引擎、引擎数据库这几者已经明显的标注之上，在后续的各个工作流引擎中这种架构都没有颠覆性的变化。 这里我们来看一下JBPM5的架构 他引入了规则引擎Drools，规则引擎负责了整个流程引擎的运转，而知识仓库的存在。让面向流程的知识管理有了更直观的认识，事实上JBPM的代码操作几乎都是从知识库类开始的。 这张图很好的表现出了一个以BPMS为方向的流程产品应该是什么样的架构模式。 如果说JBPM是产品经理的造物的话，那么Activiti就是技术人员的杰作，Activiti更多的精力是放在了技术架构的精妙。其易用性方面是JBPM难以比拟的。集成一个Activiti的难度要远低于JBPM，同时JBPM业务化的api体系也着实让技术人员有些头疼。 这张图就是Activiti的架构图，可以看出这张图与其说产品架构图，更有点像技术架构图。在产品层面上，其知识库的概念还没有完全突出出来。 所以说对两者来说，JBPM的产品架构很不错，而Activiti的技术架构比之要强。两者可以说各有所长，不过他们之间有一些已经确定的共识。两者其实都在往BPMS的方向前进。 优势与共同点 如何设计流程，在组织中高效地对设计出的流程进行沟通，取得共识？ 提供跨越组织的流程标准标记符号与术语（BPMN已经成为标准） 流程及相关文档的可视化（流程/内容存储仓库） 提供在组织结构内进行不同层次之间的流程导航（流程存储仓库支持组织模型） 流程定义在各个层次/部门间的一致性，避免业务人员的流程建模转换到IT系统时受到损耗（流程引擎支持基于图的建模，支持扩展） 如何更好地执行流程？ 业务活动的实时监控，预警与控制（BAM） 流程执行的仿真 流程执行的统计分析与反馈（报表） 如何更好地管理流程？ 打破各个应用系统之间的界线，统一管理所有流程（EAI，与ESB的集成） 对业务人员友好的建模工具 如何在执行流程过程中遵循业内最佳实践和规则？ 面向流程的知识管理 规则引擎 JBPM和Activiti如此强大，那么国内也有很多厂商已经在使用了，但是在实际项目里得到的统一结果可能就是“不咋地”。这很简单，因为相比起SSH这样的框架，工作流与业务更贴近，因此对其灵活度的要求就更高。更高的灵活度就意味着更多可定制化成分。因此比如我们想造一辆汽车，SSH可以给我们的可能是生产线、发动机这样成品式的组件，而JBPM和Activiti给我们的则是油漆铁板这样的原材料。其主要问题主要在： JBPM和Activiti的中国化 JBPM和Activiti已经被国内大量程序员所了解并加入到所使用的项目中。这两者也是国内架构人员的座上宾。 但是在使用中真的如此顺利么？笔者也曾用过这两者，也和用过两者的同行做过一些交流。我们认为这两者对于国产使用实际效果不佳。尤其在面对中国工作流需求时，两者不但没有提高更多帮助，反而使用户感觉掣肘。 API复杂，学习曲线高 正是由于业务的高可变性，开源的工作流引擎必须提供更多的api以供使用。这种复杂的API使程序员上手非常困难，使用者与其是被自己的业务捆住不如说是被困在寻找各种API的路上。 沟通成本高，反馈困难 大型的开源工作流产品无一例外是由国外团队维护，与其沟通并非容易的问题。 从引擎到应用必须经过二次开发 国外的工作流引擎在使用前一定会有架构师进行本地封装，有些是根据特定应用进行的封装，有些事通用的封装。这里JBPM的封装难度就比较大，而Activiti则稍小，不过依然是一件比较痛苦的事情。 国内只拿到引擎，而没有学会BPMS架构 之前也说过BPM最大的客户价值在于BPMS，这些正是各大工作流引擎所追寻的目标所在。客户为何