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