activiti工作流引擎(一)why activiti

原创
2014/03/01 21:15
阅读数 6.3K

公司早前花了一年,由5人左右规模的团队,弄了一个工作流为基础的平台系统,基于jbpm4实现。

最近我接手了这个项目组,开始在想升级优化的事情,刚开始想着从业务通用化的角度去改造。但看着看着,发现不对劲,现有这个系统有很多东西没做好,尤其在工作流引擎这块,有着各种各样的问题。考量再三,找到了activiti,决定升级工作流引擎。

*首先,现在的系统到底有什么问题?*简单梳理了一下:

  1. 流程维护成本高,简单修改一个节点名称却要修改代码,重新编译部署
  2. 流程定制开发成本高,所有节点逻辑混合在几个方法中,产生大量if,而且定制修改后产生bug的风险非常高
  3. 流程版本共存/过渡机制几乎没有,只能等待线上的旧版本运行结束,或暴力删除旧版本流程
  4. 流程只能由开发人员在开发平台上完成设计,不能直接交给业务人员定制

那activiti可以解决吗?

  1. activiti-5 使用bpmn2代替jbpl,终于分离ID和name属性。
  2. activiti-5 分离ID和name属性后,可以通过IoC根据ID注入处理类,即隔离了节点之间的逻辑,便于实施开发和维护。
  3. activiti-5 原生支持流程版本,能更好处理多版本流程共存过渡的问题。
  4. activiti-5 提供了基于Web的流程设计器,可以由业务人员在web界面上直接设计流程,然后由开发人员整理部署,并实现业务逻辑。

另外,说个小故事:话说当年jbpm是由供职于JBOSS公司的一名叫Mike的程序员主创的,经历了4代后,Mike和JBOSS在关于jbpm5的思路上有了重大分歧,于是他离职去了alfresco,并在jbpm4基础上上弄了一个activit5的轻量级工作流引擎,而JBOSS则从一家收购的工作流引擎公司带来的产品修改成jbpm5。因此,某种意义上讲,activit5才是真正的jbpm5。

选activit5的一个原因,就是因为它更贴近jbpm4,有延续性,更换成本更低,同时它又确实能解决上述几个问题。

为什么不考虑jbpm5或者6呢,最主要的问题不是替换成本,而是,他们绑定了JBOSS自家的App Server。这个实在太讨厌,我们只是想做一个轻量级的跑在tomcat上的系统,所以……

展开阅读全文
打赏
0
2 收藏
分享
加载中
写的不错。
2016/05/10 14:43
回复
举报
更多评论
打赏
1 评论
2 收藏
0
分享
返回顶部
顶部