Jflow；JBoss JBPM ；Activiti以及FixFlow ；SWF五大流程引擎的对比

 

几种工作流引擎的简介：

jBPM是公开源代码项目，jBPM在2004年10月18日，发布了2.0版本，并在同一天加入了JBoss，成为了JBoss企业中间件平台的一个组成部分，它的名称也改成JBoss jBPM。。

Activiti是由jBPM 的创建Tom Baeyen离JBoss之后建立的项目，构建在开发 jBPM 版本1到4时积累的多年经验的基础之上，旨在创建下一代的 BPM 解决方案。

FixFlow 5.0是一款方正国际自主研发的开源BPM流程引擎，吸纳了 jBPM3和 Activiti5等国际开源流程引擎的精髓，参考了SAP Netwaver、IBM BPM 等重量级BPM产品功能。

JFlow是驰骋公司的开源项目，向社会100%开源，研发于2003年，到一直持续到现在，功能强大丰富，图形化的配置，功能性配置较高，在中国国情下成长起来的优秀的工作流引擎。在国内具有一定的市场地位，是国内著名的老牌工作流引擎。

SWF是一种嵌入式的工作流引擎，它不需要任何应用服务器的支持。SWF使用十分简单，但却可以满足多数流程驱动应用的需求。

 

几种工作流引擎对比：

 

1、activiti文档丰富，csdn有相应专栏，并且国人贡献了一本《activiti实战》详细的讲解了基于activiti的开发内容，网上教程资源丰富。

activiti官方提供webapp war包，部署在Tomcat下可快速操作和了解activiti，esclipse提供支持activiti项目的ide插件，总的来说环境支持良好。

activitiActiviti上手比较快，界面也比较简洁、直观，学习周期相对较短。

activiti代码量大，核心代码改动难度较大，但提供了完整的技术文档，架构良好，网上开发文档较多，一定上降低了二次开发的难度。

activiti支持多种表单：动态表单，外置表单，普通表单，但表单设计未集成，需要自己集成表单设计。

2、JBoss JBPM 6.5中文文档相对匮乏，网上教程资源参考价值不大。

JBoss JBPM 6.5支持绝大部分工作流程，符合中国国情的审批需继续二次开发。

JBoss JBPM 6.5支持表单设计器，但是用户体验不好，设计器属于英文版本，需要汉化

JBoss JBPM 6.5代码量大，核心代码改动难度较大，技术文档少，二次开发难度大。

JBoss JBPM 6.5功能丰富复杂，众多的api接口，全英文的文档，因此学习周期比较长

3、Jflow提供完整详细的接口文档和操作手册，属于国内公司开源项目，有专门的BBS论坛。

Jflow官方提供快速运行体验http://demo.ccflow.org/，也可按照教程部署到本地Tomcat下访问本地地址测试。

Jflow资源相对丰富，文档接口完善，需要学习内容较多，但有良好的文档支持，学习周期一般。

Jflow整个核心源码大小在10M左右，官方提供几个demo开发教程，并且有相关的BBS论坛，一定上降低了二次开发的难度。

Jflow支持可视化流程表单设计器，用户体验好，设计器属于中文版本，支持绑定表单格式。

Jflow支持大部分流程的基础功能：前进、后退、转向、转发、撤销、抄送、挂起、草稿、委托代办，也支持高级功能取回审批、项目组、外部用户等

4、FixFlow 5.0官网已关闭，并且很多内容一两年没进行维护，导致文档资源相对缺乏。官方提供一份完整用户向导手册，涵盖了所有FixFlow基本功能和简单操作。

FixFlow 5.0官方提供快速体验webapp war包，只要部署在本地Tomcat下就能测试。

FixFlow 5.0属于国内开源项目，但由于很久没人维护，导致很多资源丢失，网上分享的资源相对单一，学习周期相对较长。

FixFlow 5.0整个核心源码大小在10M左右，官方提供几个demo开发教程，但是其他教学资源相对较少，二次开发难度一般。

FixFlow 5.0不支持表单设计器，表单需要外部设计，导入绑定

FixFlow 5.0支持绝大部分工作流程，基础功能：前进，后退，转发，转办，加签，跳转，退回，催办，追回，委托代办，自由跳转等。

5、SWF（Simple Workflow）与其说是工作流引擎，不如说是分布式计算调度框架，

SWF中只包括Task和History两部分，甚至是每个Task之间如果要传递一些数据的话，都只能通过第三方存储（比如Message Queue或者Redis），不过这也给了编程更大的灵活性，问题是这种灵活性是不是非常需要。

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

SWF的一个Workflow不能太复杂，因为所有的流程控制都集中于Decider，如果太复杂的话Decider将无比庞大，给维护和扩展带来一定的困扰。

SWF不能支持太复杂的流程

个人研究工作流引擎后的总结，希望对正在研究的网友提供到帮助