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上的系统，因此……