工作流引擎之我看

工作流引擎的英文全称是：WorkFlow Engine，

是指workflow作为应用系统的一部分，并为之提供对各应用系统有决定作用的根据角色、分工和条件的不同决定信息传递路由、内容等级等核心解决方案。

最初接触工作流引擎是个国内的产品--大名鼎鼎的东兰工作流。东兰科技的营销人员来我所在的公司宣传、演示他们的产品，友好的图形化界面、所见即所得的流程定义过程给了我深刻的印象，也使我对工作流引擎系统产生了浓厚的兴趣，但无缘去进一步学习与研究，甚为遗憾。随着JAVA世界的开源化狂潮袭来，工作流引擎系统一夜间也进入了开源时代，各种优秀的开源工作流引擎曾出不穷：Shark、Osworkflow、JBPM、ofbiz等等。我在工作中接触过其中一两个，简单谈谈对他们之间的印象与比较。

  在工作中接触的第一个开源工作流是OSWorkflow。当时因为别的项目组人手不够，我就半路杀入该项目，他们项目中使用的工作流引擎正是OSWorkflow。使我有机会第一次和工作流引擎有了直接接触。因为第一次使用工作流引擎，算是半路出家，在使用中都是在模仿前面人的工作成果。项目完成之后，才算是对工作流引擎算是入了点门，:-)。

  我对这个工作流引擎的印象是比较奇特 与怪异。首先，OSWorkflow居然在可视化流程定义工具大行其道的今天，逆流而行，反对可视化定义工具的使用，它希望用户靠XML去手动写流程，这点我百思不得其解。其次，持久化配置方式不唯一，差别比较大。有内存方式、JDBC方式、SpringHibernate联合方式、JDBCTemplate方式、Hibernate方式。这些方式差别比较大。我想也许是为了灵活吧，用户可以根据项目的使用别的框架的需要选用合适的。网上总说这个工作流的最大特点就是灵活，可以根据用户的需要定制出这种各样的业务系统，省去了复杂的编码。我感觉网上的这个评价是废话、空话，其他的开源工作流也一样具有这样的特点，也差多不的灵活。由于使用较少，项目完成以后也再也没有接触过，对它所知不多，印象很薄。

   我与JBPM的缘分比OSWorkflow要大的多了，使用的时间最长。jbmp将工作流应用开发的便利性和杰出的企业应用集成（EAI）能力结合了起来。（插句题外话：现在很多开源的EAI系统都使用JBPM作为它们的工作流引擎，例如：mule。）jBmp包括一个Web应用程序和一个日程安排程序。jBmp是一组J2SE组件，可以作为J2EE应用集群部署。

  它最初是tom baeyens编写的一个灵活可扩展的工作流管理系统，后来被JBOSS公司总裁看中并收购，成为JBOSS公司负责维护的工作流引擎。同志们呀，请相信JBOSS公司总裁的眼光。我最初就是看到这个消息，才决定认真学习JBPM。中国没有介绍JBPM的专门书籍（有本粗糙不堪的中文翻译JBPM自带的使用手册，CHM文档），只好看它的源代码，可惜因为工作的繁忙的关系到现在都没有看完。我感觉JBPM代码最优秀的地方是它的解耦合做的太好了，各个模块都做成了组件模式，可独立组装、拆装，很有点COM的味道了，呵呵。你可以把它的各个组件拆卸下来、独立使用。我有次拆下它的日程管理模块加载在别的项目中，几乎不需要修改任何代码就能正常跑起来。JBPM实现了一个类似于Spring的Bean装配、管理机制，但是比Spring那个大家伙要简单了许多，这个简单的Bean管理机制正是JBPM模块能轻易拆解的来源。我建议：如果想要学习Spring的源码的话，不妨先看看JBPM的Bean管理模块，这样能非常容易理解Spring的核心代码，但却比之接看Spring源码要简单了许多。

  JBPM和OSWorkflow不同的是，JBPM完全支持图形化可视化流程定义，使用图像化定义流程很方便，只要拖动各个流程块，到工作区中，然后串联起来就OK了。非程序员也可以轻松的完成流程定义工作，更改流程也非常方便。不过这个图形设计工作流程工具总有点BUG，JBPM的各个版本都有点问题，我没有看到最新的版本，不知道改进了没有。当然JBPM也可以和OSWorkflow一样使用XML去定义流程。
  
  JBPM完全使用Hibernate作为持久化工具，没有像OSWorkflow一样多种多样，五花八门。单一的持久化工具，使初学者很容易轻松入门。

  JBOSS公司在给予了JBPM很大的发展空间，并不强制大家一定只能在JBOSS上使用jbpm，TOMCAT上也能跑，呵呵。