工作流的微核心架構

　　近年來，基於流程引擎技術構建的應用系統越來越受到客戶的追捧和認可，能否支援 “流程可定製、可更改、可執行”也逐漸成為客戶衡量一個應用系統主要標準之一。

　　又比如目前被大家廣泛提及的SOA（面向服務架構），為客戶解決“業務敏捷性問題”提供了新的指導思想和方法。但是SOA的整體構架必須依賴於三方面技術的支撐：解決互通互聯的技術與標準，比如我們所熟知的訊息匯流排技術、JBI、SCA等等；解決流程管理的技術與標準，比如BPM，Workflow等；以及解決業務模型構建的技術與標準，正如我們所熟知的MDA（模型驅動架構）等。可見與流程應用相關技術的重要性。

　　最近也有很多企業的朋友向我抱怨他們給客戶實施工作流專案的時候，不論是採用第三方的工作流產品，還是擴充套件開發開源的工作流引擎，總是非常棘手，碰到很多難以應對的問題，而且這些問題一般出現在專案後期。因為在需求調研的過程中客戶也無法欲知，因為客戶也不清楚流程系統應該具有什麼功能。

　　可以說，從工作流專案實施角度可以闡述很多可以注意的事項，但是本篇確從另一個角度來輔助大家看待流程問題。這個角度完全是從一個“源”角度來探索—— 如果你清楚了一個過程引擎的實現思路和構架，我想你就不會在為那“怪異的客戶需求”而驚奇了，相反，你可以很輕鬆的應對。

　　是的，本篇主旨就是講解“微核心過程引擎的設計思路和構架”。

　　在進入文章正文之前，我還有必要稍稍補充兩點：

　　在前一篇楊洪波先生已經為大家詮釋了工作流（Workflow）與業務流程管理（BPM）的異同。為了減少名詞概念方面的誤導性，本篇採用了流程（Process）這個概念，來規避Workflow與Business Process所可能帶來的概念差異性。當然，不論是工作流還是BPM，解決的根本問題都是流程（Process）問題。

　　過程引擎的實現技術已經超越了單純的技術語言、技術模式、構架。在閱讀本篇之後（或之前），如果您對工作流引擎的實現感興趣，那麼儘可能的把工作流基本概念、模型、建模方法、系統參考模型等方面的內容瀏覽一下，可能更有助於您閱讀本篇。

　　當我們試圖去實施一個工作流專案，或者研發一個過程引擎的時候，我們將面臨很多的問題需要解決：流程有分支，有聚合；客戶又要會籤，還要回退；組織模型需要適配，許可權要控制到資料；等等諸如此類的問題。
 
　　正如上面這張圖所示，可能單個問題比較容易解決，但是這麼多需要考慮的地方融匯在一起，就演變成一個非常複雜的問題了。

　　但是，再複雜的問題也都可以通過逐步分解、剝離，分步、分層的進行構建，從而逐步解決。本文的主旨就是通過提供一套設計流程的思路和引擎構架來輔助大家解決這個問題。限於文章篇幅，很多地方本文只能“點到即止”，如果對過程引擎構建幹興趣的化，那麼在閱讀本篇之後，還需要花費較多的時間鞏固相關知識才可。

　　在工作流大師Aalst的《工作流管理：模型、方法和系統》一書中，為理解工作流劃定了一個參考框架（Reference Framwork）。這個參考框架包含三部分：基本概念；過程建模和分析；描述工作流管理系統的功能和體系結構。

　　當我們試圖設計過程引擎的時候，需要牢牢圍繞這三個層面展開：掌握了基本概念才能真正理解什麼流程；懂得了過程建模才能知道如何去描述流程；理解了工作流系統結構才能著手設計過程引擎。

　　流程設計原則（思路）一：過程建模

　　可能有人說，“描述一個流程”根本不是問題啊，那個工作流管理聯盟（WfMC）組織所定義的XPDL不正是“基於XML的過程描述語言”嗎。的確是這樣的，WfMC通過一個XPDL語言告訴人們改如何去描述一個流程，或者用官方的語言說，XPDL是工作流參考模型中介面1的實現。

　　但當你在摳XPDL那複雜的Schema的時候，你是否已經注意到了WfMC所闡述的Workflow Definition Meta. Model呢？可能很多人並沒有注意到這一點。WfMC早在1995年釋出《工作流參考模型（Workflow Reference Model）》這份文件的時候，就已經闡述了這個過程定義元模型。

　　但是，WfMC所闡述的過程定義元模型並不是唯一的，也就是說，存在很多流程產品採用的並不是這套描述語言。這樣的差異性是由於“過程建模方法”的不同所引起的。目前在流程領域主要存在如下的建模方法：Petri網模型，有限狀態機（FSM）模型，活動圖模型，以及事件過程驅動鏈（EPC）模型，當然，我們所知道的WfMC的過程定義元模型估計也可以算上吧。比如我們所熟支援的開源引擎JBoss jBPM就是採用的活動圖模型。

　　限於主題與篇幅問題，不在這裡闡述過程建模方法的相關知識。

　　任何流程都是由兩個最基本的元素組成：“節點”及“有向連線”。對於“有向連線”幾乎沒有任何歧義，所有的流程建模描述中“有向連線”都是存在“From”和“To”這兩個特性。但是對於“節點”，則因為所處的視角、功能不同，則存在很多不同的理解了。

　　比如WfMC的過程定義元模型，它所闡述的“節點”就是“活動（Activity）”，但是這活動有很多實現型別：有人工的、有自動的，有子流程的，等等。

　　比如jBpm這個引擎所依賴的活動圖，它所闡述的“節點”是兩種：一種是表示真正業務意義上的節點，叫做State；而另一種是表示邏輯連線（Logic Connector）的節點。

　　再比如EPC這個建模方法，它所闡述的“節點”則是三種：一種是表示某種狀態發生的節點，叫做Event；另一種是表示真正業務功能的，叫做Fuction；第三種則是表示邏輯連線（Logic Connector）的節點。但是，EPC的邏輯連線節點和jBpm的邏輯連線節點的含義、種類又有所不同。

　　上面的例子，則說明了我們可以用很多種方式來“描述流程”。當你試圖去研發流程系統的時候，尋找一套最適合自己的“描述流程”的方式，則是首當其衝。

　　越過這道坎的難度是很大的，因為很多技術人員對工作流的基本概念和建模方法理解不多。好在WfMC的XPDL還是很完備的，為我們提供了一個很詳細的參考實現。而且國際、國內上很多著名的工作流產品，其過程定義就是遵循XPDL規範的。

　　流程設計原則（思路）二：過程定義與例項的關係

　　如果這時候確定了過程定義的模型，那麼接下來最重要的就是考慮過程定義與過程例項的關係了。這可不是“類”與“物件例項”那樣簡單的關係了。

　　在WfMC的規範中，闡述了過程定義與過程例項之間一種簡易的關係，如下圖所示：
 
　　這種關係是非常簡單的表述，但現實中的應用遠比這更為複雜。在同一個流程例項（Process Instance）中，一個活動節點（Activity）就只存在一個活動例項（Activity Instance）嗎？在現實應用中，存在非常複雜的多例項情形出現，比如因為某種原因造成“回退”之後再返回，可能同一個活動節點就會被執行兩次甚至多次；再比如，因為某一個節點多個處理人的非同步執行，則也有可能引發後續節點被重複執行的情況。

　　這種定於與例項的支援關係需要在設計流程引擎之前就考慮情況，否則在後續面對客戶應用的時候，就可能存在措手不及的情況。

　　以上僅僅講了兩個基本的設計思路，面對設計任何流程引擎或者擴充套件開發現有的引擎的時候，都需要縷清楚這兩方面的思路和設計特點。當然對於整個引擎的設計，還有其他很多方面需要考慮，比如流程排程、所依賴的狀態、所引起的事件等等。限於文章篇幅，不在這裡闡述。

　　設計思路之三：微核心

　　微核心（micro kernel）這個概念最早是由Richard Rashid提出的，雖然這個最初是為了構建基於訊息傳送機制的微核心作業系統，並不是為了軟體構架服務的。但是，最近幾年，隨著“構件化”“分層”軟體體制的發展，微核心技術和構建思想逐漸被引入到軟體設計構架中，用於“儘可能的解耦元件之間的關係”。

　　與微核心設計理念相對應的則是單核心（monolithic kernel），這也是一個源自作業系統級別的概念。對於單核心來說，整個作業系統就是一個整體，包括了程式管理、記憶體管理、檔案系統等等，而對微核心來說，作業系統的大部分在核心之外，彼此間通過訊息進行通訊。

　　之所以談到單核心與微核心之間的關係，這是由於“過程排程”“流程引擎”“應用處理”之間的關係決定了對於過程引擎的設計，必然牽扯到“微核心”與“單核心”的考慮。

　　很多設計人員在設計流程引擎的時候，一般是以“微核心”設計為指導思想的，正如上面左圖所示的那樣。但是往往在後期，隨著應用的複雜度增加，客戶業務需求的特異化，造成最終的流程引擎可能是右圖所示，從而最終偏離微核心的宗旨了。

　　造成這種現象的主要原因是由於目前對於流程引擎的元件設計、介面描述等多方面都沒有形成“一致的標準”，也就是：一個引擎不是孤立的，其必然也是有很多元件、服務介面、規則等多方面組成的。這些元件之間需要通訊，但是並沒有一個統一的規範能夠約束這個通訊機制和資料，所以最終都依賴於各個廠商自己的實現能力和抽象能力。

　　這並不像我們所熟知的Jboss App Server那樣，其依賴於JMX這個規範標準，從而構建了一個完美的“微核心”伺服器。所有的服務和元件都通過實現JMX的介面掛接在這個微核心構架之上，元件之間的呼叫和資料互動頭依賴於統一的標準。

　　雖然，現階段我們很難構架一個過程引擎能夠百分百實現純粹的“微核心”，但是，通過“微核心”這套設計思想的指引，並不斷對引擎內部的元件進行抽象、提煉，對服務剝離和重構，來逐漸減少業務應用與過程排程之間的耦合度。

　　微核心過程引擎的構架

　　兩年前寫過一篇名為《微核心工作流引擎體系架構》的文件，文件基本闡述了微核心工作流（流程）引擎的幾個層次和相應的一些解決方案。這份文件可以在我的主頁www.javafox.org上免費下載。

　　微核心引擎的原則，就是儘量將“引擎所需的服務”與“引擎核心排程計算”剝離。將Engine Kernel部分儘量“疏剪”，儘可能將“一些處理操作”放置於外圍擴充套件。

　　上面這張圖，可能會在很多產品介紹或者工作流文章介紹中看到類似的，但是很少會有提及“過程引擎”結構這一部分的。

　　微核心的過程引擎結構，一般主要圍繞三個層面構建：

　　引擎核心處理：這就是引擎真正的Kernel了，在一層最主要解決的問題就是：流程的排程和執行。
　　引擎執行服務層：為引擎提供一些公共服務和資源處理。
　　擴充套件實現層：這一層是微核心最為繁瑣地方，有各種擴充套件點供外圍擴充套件。總結下來主要有三類：
　　支撐流程執行的：這些擴充套件點必須被實現，否則引擎無法執行。比如為引擎提供儲存適配。
　　輔助流程執行的：利用這些擴充套件點，可以讓引擎進行更多的處理，比如一些Function介面、條件處理介面。
　　增強流程執行的：利用這些擴充套件點，可以讓引擎的內能變得更強大和完善，比如一些事件監聽處理介面，客戶自定義的策略實現等。

　　“微”核心

　　總的來說，微核心有兩層含義：

　　支援功能非常簡單：僅處理最核心的過程排程相關的功能。也就是說，當有一個節點完成的時候，這個過程引擎的核心，能夠準確的依據已經過程定義，並按照事先構造的排程演算法和機制，來計算下一個需要執行的節點。
　　實現的結構非常簡單：沒有太複雜的實現，但都會有幾個最基本的物件體。

　　從實現結構上來說，沒有太標準的規定，基本上每一個引擎都會有所不同。大家可以拿jBpm、OSWorkflow及OBE這三個引擎比較一下，基本上結構都是不一樣的。限於文章篇幅，就不在這裡詳細分析這三個開源引擎的結構了，大家可以參考我曾經寫過的那篇《工作流引擎核心排程演算法》，裡面有部分內容涉及到結構上的比較。

　　雖然結構上可能會差別很大，但是基本的實現思路和基本的關鍵物件體是或多或少有些相似的。

　　每個引擎核心都是提供一個executeContext（執行上下文）物件來負責每一個例項的環境資訊。

　　每個引擎核心都會提供一個機制，這個機制用於計算流程的流向。這個機制會因為採用不同的演算法和思路差別會很大。

　　每個引擎核心都回提供一個執行機制，這個機制用於執行那些“允許被執行的節點”

　　每個引擎核心都回提供一組最核心的例項物件來表示流程例項的可持久化資訊

　　結尾

　　短短的五千字很難把微核心過程引擎的設計思路和構架講解清楚，很多內容只能“蜻蜓點水”的掠過。過程引擎的設計需要融合“理論”和“技術”。不僅需要對軟體開發有著深邃的理解，還需要有工作流的基本理念、概念、過程建模方法、系統結構等多方面的理論基礎。

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/14780828/viewspace-374557/，如需轉載，請註明出處，否則將追究法律責任。