activiti工作流引擎（一）why activiti

公司早前花了一年，由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上的系统，所以……