串講Apache OFBiz技術架構

標籤：ofbiz   架構設計   

從決定讀ApacheOFBiz源碼到現在不知不覺一年就過去了。這一年因為各種原因，導致源碼讀得斷斷續續。其實最大的問題還是因為無法深刻得理解裡面的一些東西，導致熱情驟減。直到最近，公司在開發的一個“應用快速開發平台”引發了我的一些思考，所以決定再把源碼拿出來重新閱讀。到最近對其架構設計近乎迷戀。

個人認為對於ApacheOFBiz的剖析可以分成三大塊來進行：技術、業務、資料庫設計。這三塊個個都是非常頂尖的水準，每個方向深入進去都可以學到很多東西。之前只是對OFBiz各個部分的單獨解析，現在是時候寫一篇文章來串講它的各個部分。當然，這篇主要還是涉及到OFBiz的技術這一塊。

架構簡介

這張圖是OFBiz的整體架構圖。可以看到OFBiz的所有app都構建在其framework之上。而其framework的核心就是ServiceEngine（服務引擎）以及EntityEngine（實體引擎）。其實體引擎對於資料庫的種類以及拓撲結構的支援都非常健全。它支援本機資料庫與遠端資料庫並存並且支援多達8種主流資料庫。

OFBiz技術串講

下面以一個用戶端請求的處理過程來看OFBiz各個組件是如何互動以及銜接的。

（1）用戶端瀏覽器向web伺服器發出一個請求(http/https)，請求會被web容器接收並作相應的處理（比如參數的封裝等）。
（2）請求被路由到一個代理servlet中，該servlet會分析請求是發往哪個app的，然後再到該項目的下的controller.xml設定檔中去匹配request-map配置項，該配置項用於只是OFBiz如何處理這個請求。通常的處理過程是先進行安全檢查以及許可權確認，然後觸發某個“事件”或者服務調用，最後會以一個view作為響應。如果是以一個view作為響應的話，OFBiz會去view-map中匹配該視圖，每一個視圖view都有它對應的handler。
（3）OFBiz會用配置的handler來處理該view。handler的作用主要用於渲染頁面元素，並將需要展示的資料跟頁面元素合并。
（4）資料準備。前端的請求歸根到底還是請求對後端資料的操作。而ofbiz中用於擷取資料的方式十分豐富。考慮到這裡對商務邏輯而言，是代碼量佔比很大的地方，因此OFBiz嘗試利用動態語言來編寫這部分代碼。主要是想利用動態語言的簡潔、代碼量少、快速開發的優勢。隨著java語言的發展，OFBiz選擇並且替代了多種不同的JVM指令碼語言，比如：beanshell,Groovy。採用指令碼語言來編寫跟操作實體相關的商務邏輯代碼，可謂有利有弊：

弊端：動態語言（弱類型語言）固有的型別安全的缺失以及純解釋執行效能跟Java這種解釋+編譯型語言還是無法比擬。

優勢：大量傳統行業，不需要那麼高的效能要求；即便需要也可以用提升硬體來改善；指令碼語言在編程效率、邏輯簡潔性都是Java冗長的代碼所望其項背的；指令碼語言更貼近人類語言的表達，更適合實現DSL，來表述商務邏輯（而且OFBiz的下一步目標也將增強對Groovy實現DSL的支援）。

（5）OFBiz的viewhandler通過模板引擎綁定頁面元素與資料後，渲染出最終的輸出資料流，通過http響應給用戶端瀏覽器。

頁面渲染

Apache OFBiz使用XML+Widget的布局，來將頁面切分成一個個Widget以增強各個widget的靈活性以及複用性。

這些widget可以互相嵌套形成一個decorator-widget產生模板，在widget可以直接編寫html標籤，或者引用各種服務端模板引擎支援的模板檔案（比如freemaker）。

前端的內容通常是HTML+資料。widget並沒有忽略資料這部分。只是一種布局技術，它最終會由webcontainer轉化為html，只不過資料的處理（CRUD）通常位於伺服器端。而這些動作都被抽象成為了widget中的“action”。一個screen通常包含各種其他組件widget的引用，這些組件widget可以是：form，screen，menu等。

許可權檢查

OFBiz中採用的是角色+安全性群組的授權模型。

可以看出常用的幾個許可權有：_ADMIN（管理員權限）,_VIEW（瀏覽許可權，為最小許可權）,_CREATE（建立許可權），_UPDATE（編輯許可權）,_DELETE（刪除許可權）。因此如果controller.xml中配置了授權檢查時，將會進行的許可權檢查流程。一個請求在處理之前，會檢查其是否需要先進行登入。如果登入驗證通過，會擷取該會員的security group。而security group又是security permission的集合。進而可以判斷使用者是否有某個操作的許可權。

請求事件

因為OFBiz使用了公用代理的servlet，因此對每個請求而言，其處理邏輯就沒有獨享的servlet了。這裡OFBiz引入了Event的機制來處理每個請求需要執行的特定的操作邏輯。

每收到一個請求，如果有特殊的處理，就觸發一個event。是event的觸發機制。它的配置在controller.xml檔案下的request-map配置項內。

服務引擎

OFBiz執行服務基於其自身實現的服務引擎架構。該服務引擎借鑒了《CoreJ2EE Pattern》裡的“BusinessDelegate”模式。

調用程式通過服務引擎架構調用服務後，服務引擎首先將調用服務的參數提取並構建服務調用的上下文。然後選擇合適的dispatcher，它其實就是businessdelegate。由他選擇合適的引擎來執行服務。OFBiz會先判斷服務有沒有“特殊性”，比如它是否是非同步？是否是遞迴執行的。如果是，那麼會選擇它內建的JobScheduler來執行。還有它是否是帶SECA（ServiceEvent Control Action）的？如果是SECA，那麼會先執行SECA然後選擇已配置的特定引擎來執行真正的目標服務，而在這個過程中會有一個Map來充當執行的上下文，用於儲存中間結果、錯誤資訊以及最終結果。執行完成之後，內容物件會在調用棧中層層回退，並將最終的執行結果返回給調用端。

服務事件控制響應器所謂SECA是Service Event Control Action的單詞首字母的縮寫形式。可以簡單得理解成“服務編排”（可能會執行多個服務，但是某些服務需要滿足特定的執行條件）。

比如上面一個帶SECA的服務X，在服務引擎執行之前，會先處理其ECA（這裡先調用一個action，它需要執行服務B）。當ECA處理完成之後，會將控制權返回給執行引擎。執行引擎會根據服務B的執行結果來判斷是否會調用真正的服務X。SECA被用於在OFBiz中替代了其原有的規則引擎以及工作流程引擎，可見其靈活性是足以滿足複雜業務支撐的。
寫在最後更多的技術分析，請看之前的系列文章以及後續的持續更新。

串講Apache OFBiz技術架構