開發背景

我們公司是主要從事企業語音方面產品的開發，主要產品比如：調度系統，指揮系統，電話會議系統，呼叫中心系統等。這些系統都有一個共同特點，就是涉及到呼叫，放音，收發按鍵，會場操作。我們的業務產品都是基于我們的軟交換系統之上構建的，軟交換系統的應用服務器向外提供這些服務。

產生的問題

我們在開發的過程中就發現一個問題，每個產品在此接口上都會做很多重復的開發，特別是在IVR處理上面。

IVR （Interactive Voice Response）即交互式語音應答，可以提高呼叫服務的質量并節省費用。IVR是一種功能強大的電話自動服務系統。

由于我們的系統重新架構，正在開發軟交換API接口，所以我們試圖解決這個問題。

為了方便上層對底層接口的調用，減少重復開發，產品能夠針對用戶需求迅速更改，我們提出了事務流的概念。即上層程序設定一個事務流，比如：相對用戶9092發起呼叫，用戶應答后對用戶放音，讓用戶輸入密碼，密碼驗證成功加入制定會場。上層程序設定好這樣的事務流后，發送給下層進行處理。下層處理完畢后，回復處理結果。

事務流的概念最終并沒有實現，一是我們對事務流的異常處理分析不足；二是采用事務流的概念擴展性，可維護性不是很好。

后來我們在事務流的基礎上引進了SOA的概念，即將底層的接口封裝為一系列松散耦合的服務，在上層通過對服務的編排實現流程編輯的功能。但是實施SOA困難非常大，一是SOA沒有大規模的應用，文檔，經驗都比較少，實施風險較大；二是實施 SOA要工具的支持，需要投資。這樣的話我們寧可重復開發。

最終這個流程編輯的功能并沒有完成，但是我們還是在API中實現了一個簡單的流程編輯，這個流程編輯是通過硬編碼來實現的，和我們的愿望相差較大。

新的思路

后來看了一家平臺軟件公司的介紹，他們是做企業應用平臺的。企業應用中很多的一點就是工作流。他們的平臺就是集成了一款開源的工作流引擎：JBPM。第一次接觸JBPM，感覺很多思路可以借鑒。后來在網上搜資料的時候搜到幾篇研究微內核流程引擎的文章：

揭秘jbpm流程引擎內核設計思想及構架

微內核過程引擎的設計思路和構架

微內核工作流引擎體系架構與部分解決方案參考

這幾篇文章是我設計流程引擎的核心基礎。看完之后最終決定自己設計一個微內核流程引擎。

使用開源還是自己開發

決定動手開發前，有兩種方式，一是使用開源產品，比如JBPM；二是自己動手開發。當時的考慮是：

1、JBPM是用java開發，我們公司的業務產品目前基本上都是c，和java交互不便。

2、JBPM是針對企業工作流設計的，工作流和IVR導航一個重要的區別是，IVR導航對時效性要求很高。要求系統能夠及時響應。

3、我不是JAVA出身，當時對java還有些畏難心理。

所以，最終決定自己用C++開發流程引擎。

如果是現在的話，即便是決定自己開發，一會好好研究一下JBPM的源碼的。

借鑒的其他思路

1、數據驅動（DD）。在腳本中XML定義流程，程序啟動后將流程讀入程序，然后供上層程序調用。如果流程更改，這直接修改腳本即可。

2、BPEL。Business Process Execution Language 的縮寫，意為業務過程執行語言 ，是一種基于XML 的，用來描寫業務過程的編程語言。我的腳步語言參考BPEL的描述。