几大工做流引擎对比

 

几种工做流引擎对比：

 

一、jBPM3是一个完整的工做流系统实现，面向开发人员，目的在于简化对组织核心流程进行支撑的软件建立，不支持标准。

二、jBPM4引入PVM，使其拥有更强大的扩展性，同时增长BPMS特性，这些特性包括了对BPMN的支持、面向业务人员的Web建模器和简单统计分析功能的加入。

三、jBPM5基于原先的Drools Flow，支持BPMN，经过与Drools的合并支持BAM，经过内容仓库增长对流程可视化的支持。因为放弃了jBPM4的PVM，引擎的可扩展性受到损害，而且再也不支持jPDL。

四、Activiti5基于jBPM4的开源工做流系统，与Alfresco的集成增长了其流程可视化与管理能力，同时经过创新的Activiti Cycle协做组件支持流程相关人员之间的协调，最后，它增强了集成能力。

五、SWF与其说是工做流引擎，不如说是分布式计算调度框架，SWF中只包括Task和History两部分，甚至是每一个Task之间若是要传递一些数据的话，都只能经过第三方存储（好比Message Queue或者Redis），不过这也给了编程更大的灵活性，问题是这种灵活性是否是很是须要。

一个SWF由Worker和Decider组成，Worker执行实际的任务，而Decider进行流程控制，二者严格上来说没有区别，只是所执行的任务不一样罢了。每一个Worker和Decider会按期的去SWF的一个Task List取下一个任务。能够看出来这更像是一个“多线程”的结构，而SWF官方网站的Use Case是NASA的火星探索计划中须要处理图片的系统，这其实也是一个更多侧重于计算的系统，流程反而很是简单。

另外，SWF（Simple Workflow）的一个Workflow不能太复杂，由于全部的流程控制都集中于Decider，若是太复杂的话Decider将无比庞大，给维护和扩展带来必定的困扰。

Activiti的优点：

一、与jBPM4相比，Activiti5最使人瞩目的特性就在于它的协做工具组件。

 

• Activiti Modeler—建模器

  基于开源Signavio Web流程编辑器的一个定制版本，提供了对BPMN2.0图形化规范的支持，建模后的流程以文件格式进行存储。

   

  • Activiti probe—管理及监控组件

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

二、Activiti拥有更简洁健壮的接口

Activiti中提供TaskQuery接口，能够设置各类查询过滤，排序方式，最终经过list方法执行查询，相比jbpm，它还提供了分页查询功能，双方高下立判。

三、Activiti拥有更友好的用户体验

JBPM核心引擎彻底没有关于表单的任何抽象，它的工做机制是经过全局常量，流程变量，任务变量，这些概念十分技术化。

相比之下Activiti则更贴近实际的应用场景，它将为开始节点，以及人工任务提供了表单设置，用户能够设置字段名称，字段类型。经过Activiti的平台能够根据这些设置去生成表单，但若是不使用其平台只使用引擎的话，也支持经过它来表达与第三方表单的关系。这些表单设置的元数据信息也能够经过接口去获取。

四、Activiti支持启动引擎后随时热部署

JBPM存在一个软肋，一个RuntimeService只能在启动的时候指定bpmn资源，一旦启动后便再也不可以去更新或者增长bpmn了，这会致使咱们系统集成的困难，由于咱们天然但愿整个系统只有一个工做流引擎实例运行。Activiti则提供了Deploy机制，将bpmn资源的热部署，热更新都作了很好的支持

五、Activiti拥有更友好易用的Eclipse编辑插件和在线插件

六、Activiti依赖更少的jar包

Activiti依赖的第三方jar包较少，主要就是mybatics，而JBPM则依赖了一大堆的jar，从drools到繁杂的hibernate，再到自身拆分的零零散散的jar包，让人不禁以为它是一个庞大的怪物。

 

 

工做流有版本的概念，jBPM和Activiti上传一个新的版本后，版本号会增长1，旧版本还没执行完的流程实例还会继续执行。SWF的版本是个字符串，随意指定好了，这样也很好，字符串名称更明确。

 

嵌入式部署即将流程引擎嵌入部署于Web应用中

 

最后，总结一下：

shark：系统和功能都比较复杂

Osworkflow：比较灵活的轻量级的框架，可是在流程建模方面不太友好，须要手动编写xml文件去定义流程文件。

SWF：还有不能支持太复杂的流程