前言
業務基礎平臺是業務邏輯應用和基礎架構平臺之間的一箇中間層，解決 「應用軟件的業務描述和操做系統平臺、軟件基礎架構平臺之間的交互與管理問題」。不少國內軟件廠商，很難在操做系統平臺和軟件基礎架構平臺上有所做爲，所以國內衆多的軟件廠商紛紛推出本身的業務基礎平臺，把業務基礎平臺看做本身的核心技術。當前比較流行的業務基礎平臺大多都是基於早期的技術架構，雖然通過了多年的發展，可是因爲技術架構不是徹底基於 SOA 的組件化概念搭建，組件化支持並非很完全，如何在 SOA 下搭建組件化業務基礎平臺成爲當前軟件開發商所面臨的新課題，本文將會基於組件化的概念，介紹一種搭建組件化業務基礎平臺的思路，首先咱們看一下什麼是「業務基礎平臺」，以及組件化概念。數據庫
業務基礎平臺
如前言所述，業務基礎平臺是業務邏輯應用和基礎架構平臺之間的一箇中間層，解決 「應用軟件的業務描述和操做系統平臺、軟件基礎架構平臺之間的交互與管理問題」。操做系統平臺解決了「應用軟件系統與硬件之間的交互與管理問題」，軟件基礎架構平臺解決了「應用軟件系統與操做系統平臺之間的交互與管理問題」，而業務基礎平臺則是解決了「應用軟件的業務描述與操做系統平臺、軟件基礎架構平臺之間的交互與管理問題」。以下圖所示：設計模式
圖 1. 業務基礎平臺在技術架構中的位置
通常業務基礎平臺都包含兩個部分，運行環境和開發環境，開發環境主要用於解決如何更加快速的開發，也是業務基礎平臺的核心內容，本文主要介紹業務基礎平臺的運行環境架構，關於開發環境將不在進一步論述。服務器
業務組件和公共組件
業務組件（Business Component，BC）是一個能夠獨立運行的系統或者模塊，業務組件的目的是以方便業務組件獨立升級和減小沒必要要的組件之間的交互爲基本原則，經過必定程度的分離，實現軟件重用（Software Reuse）。若是業務組件是共用的，是其它業務組件須要重用的，稱之爲公共業務組件（簡稱公共組件），全部的公共組件組成企業架構中技術架構的公共服務平臺，好比主數據管理、系統管理、統一認證管理、通用報表等，這些都是公共組件。詳見以前的文章《面向服務體系架構（SOA）和業務組件（BC）的思考》（如下簡稱 SOA 和 BC）關於業務組件和公共組件的說明。數據結構
組件化業務基礎平臺
基於組件化業務基礎平臺和傳統的業務基礎平臺主要的差別在於組件化業務基礎平臺具備更多的靈活性、可擴展性，可以更加方便的進行組件升級和組件維護。特別是對於大型的行業軟件來講，易於升級、易於維護，可以靈活的擴展成爲評測一個業務基礎平臺的一個重要標準，隨着業務的不斷髮展，不少一體化行業軟件代碼數量已經超過 1G，如何對如此龐大規模的代碼進行維護、升級成爲軟件開發者和運維管理者日益關注的一個課題，代碼關係複雜、系統啓動慢成爲一個大型系統所面臨的一個主要矛盾。組件化業務基礎平臺主要用於解決簡化開發，快速系統維護的問題，如下經過對兩種業務基礎平臺的對比，對組件化業務基礎平臺的組件實現、調用方式、所包含的公共組件及組件進行說明。架構
傳統的業務基礎平臺
當前在 J2EE 框架下業務基礎平臺基本上是採用了「Spring Framework」、「Expresso Framework」、等開源軟件爲基礎的框架，業務系統基於業務基礎平臺進行開發，在一個企業內部，很容易造成基於一個業務基礎平臺橫向開發出多個業務模塊，甚至是跨行業的業務組件，基於一個業務基礎平臺開發的系統，全部的業務組件能夠基於一個數據庫運行，搭建一體化的業務應用系統。當前常見的業務基礎平臺包括浪潮 Loushang 平臺、SAP 的 Net Weaver、金蝶 Apusic、普元 EOS 等。其架構以下圖所示：框架
圖 2. 業務基礎平臺模型
可是這種模式存在幾個重大的缺陷：運維
- 業務模塊和業務基礎平臺緊耦合，業務模塊過於依賴於業務基礎平臺，一旦業務基礎平臺升級，業務模塊也不得不升級，不少業務系統須要重寫；
- 隨着業務的發展，業務模塊不斷增長，系統愈來愈龐大，系統難於管理，特別是隨着系統代碼的不斷增長，性能愈來愈差；
- 業務模塊升級困難，因爲各個業務模塊和業務基礎平臺緊密，各個業務組件很難獨自升級，並且全部相關的升級不得不考慮業務基礎平臺的影響。
如何既能實現一體化，又能夠解決以上問題是當前業務基礎平臺須要解決的問題。數據庫設計
組件化業務基礎平臺
在《面向服務體系架構（SOA）和數據倉庫（DW）的思考》（如下簡稱《 SOA 和 DW 》）一文中曾經提出一個原則：「軟件的核心是重用，方法是分離，關鍵是標準」，組件化基礎業務平臺依然是遵循這個原則。隨着 SOA 技術的逐步發展，SOA 已經成爲像面向對象同樣雖然不像「雲計算」那樣時髦，卻成爲一個重要的軟件體系設計模式。因爲不少軟件都是基於業務基礎平臺進行開發的，業務基礎平臺的組件化成爲組件化開發的一個基礎的要求，若是業務基礎平臺沒有實現組件化，組件化開發仍是停留在以前的遺留系統改造的概念中。如何實現業務基礎平臺的組件化，如何利用組件化對業務基礎平臺進行改形成爲業務基礎平臺關注的一個焦點。
組件化開發，首先是業務基礎平臺自己的組件化，把業務基礎平臺當作是一個獨立的組件，即《 SOA 和 BC 》所描述的基於企業集成平臺（企業門戶、應用集成、數據集成）的公共組件所描述的內容。
業務基礎平臺的組件化，並非全部的內容所有組件化，有些內容是沒法分離出去的，所以首先要把業務基礎平臺的內核分離出來，創建一個業務基礎平臺的微內核，微內核是跟每個業務組件緊密相關的。而後把業務基礎平臺中能夠分離出來的內容單獨做爲一個組件，即公共組件，從而實現業務組件和公共組件的分離。
業務組件和公共組件使用一個數據庫，經過公共組件及相關的標準實現整合，若是還有已有的系統，則經過企業集成平臺進行整合。以下圖所示：
圖 3. 組件化業務基礎平臺模型
業務基礎平臺主要業務組件
公共服務組件包含系統管理、流程管理、主數據管理、元數據管理等，在數據層面分別對應着系統數據、流程數據、主數據和元數據等數據。考慮到公共服務組件的獨立性，特別是保證每個組件獨立升級以後不會影響到其餘的公共服務組件以及業務組件，所以須要對公共服務組件進行隔離。
圖 4. 業務基礎平臺主要業務組件
系統管理主要包含：用戶管理、功能管理、權限管理、認證管理等功能，其中須要特別注意的是實現不一樣的業務組件的統一認證的問題，即實現不一樣的業務組件部署在不一樣的應用下（在 J2EE 環境下爲 EAR 文件）的單點登陸。
主數據管理主要包含：主數據模型管理、主數據質量控制、主數據監控等功能，主要實現各個組件之間公用的基礎數據的管理，須要考慮主數據在那個業務組件中進行維護的問題，不一樣的主數據須要在不一樣的業務組件中完成，而不是全部的主數據都在主數據管理組件完成。
流程管理主要包含：代辦任務管理、流程自定義、流程引擎等功能，主要實現對代辦任務的統一管理、流程的管理。流程管理主要實現流程和業務的分離，並實現辦公用的靈活流程、業務用的固定流程，詳見《基於 SOA 的工做流（WF）整合》的描述。
元數據的管理主要包含：元數據管理、數據質量監控等功能，主要實現技術元數據和業務元數據的管理。
業務基礎平臺組件接口調用方式
在實際開發應用中，性能是很重要的一個非功能性需求，特別是針對大型的應用系統，性能是決定項目成敗的一個關鍵因素，業務基礎平臺的架構決對性能問題有着重大的影響。如何在實現鬆耦合的基礎上，進一步提高性能問題（包括保證數據庫事務處理），是大型應用軟件的業務基礎平臺必需要解決的一個問題，不能僅僅是爲了組件化而組件化，若是不能解決性能問題，組件化就不能在大型的應用系統中獲得普遍應用，所以須要根據在實際開發過程當中碰到的不一樣的場景，採用不一樣的調用方式，除了組件化中提到的服務，還有要有其餘的方式做爲補充，即能實現鬆耦合，又能夠保證性能，實現不一樣層次的不一樣調用。
實現組件化，首先要定義清晰、簡單的業務組件界面，特別是業務組件和公共組件之間的界面，而後創建一個兼顧鬆耦合、性能的調用方式及不一樣的調用方式的標準。在《 SOA 和 ROA 》描述了業務組件接口模型，除了人機交互界面（沒有組件之間的調用關係），組件之間的調用關係主要有服務接口和數據接口兩種。以下圖所示：
圖 5. 業務組件接口模型
在上述接口模型中，組件的接口是面向集成平臺的，在組件化業務基礎平臺組件模型中，因爲是基於一個統一業務基礎平臺，所以能夠增長一個經過 API 調用的接口方式，提升調用效率和保證事務處理，同時爲了進一步優化性能，服務接口能夠分紅重量級的 SOAP 和輕量級的 REST 兩種，所以能夠把組件之間的調用關係進一步分紅四種（以下圖所示）。在不一樣的層級，從性能和耦合性兩個角度，組件間能夠選擇不一樣的調用方式， 具體採用那種調用關係主要是考慮性能、接口複雜度、耦合性等問題，不一樣的業務組件，特別是不一樣的廠商之間開發的組件採用基於 SOAP 的服務，同一個廠商開發的不一樣組件之間經過 REST 服務進行調用或者直接採用數據接口進行調用。一個業務組件內部，業務組件和公共模塊之間的調用，以及爲了保證事務處理，直接經過在不一樣的業務組件中內嵌模塊的方式，實現 API 調用，以下圖所示：
圖 6. 組件化業務基礎平臺接口調用方式
- 基於 SOAP 的服務接口：經過 SOAP 的 Web 服務調用，適用於不一樣的業務組件之間，特別是不一樣廠商開發的業務組件、不一樣平臺的業務組件以及新建的業務組件和遺留系統之間的調用。SOAP 的服務接口有相關的標準支持，能夠支持更多的平臺和廠商。
- 基於 REST 的服務接口：同平臺、同廠商開發的業務組件之間的調用，特別是同一個組件中界面和業務邏輯之間的調用，從而實現界面和業務邏輯分離。REST 服務是輕量級的服務調用，主要用於提升性能，簡化開發。
業務組件之間於 SOAP 的 Web 服務調用或者 REST Web 服務調用，由於基於 SOAP 的 Web 服務擁有衆多的標準，能夠方便的實現跨平臺調用，適用於不一樣廠商之間的業務組件調用，同一個廠商之間的不一樣組件調用能夠直接經過可以提供很好性能的 REST Web 服務調用。
- 基於 API 的調用 ，業務組件內部不一樣模塊之間的；業務組件和基礎平臺的內核之間；不一樣的業務組件之間須要緊密結合事務處理的調用，經過 API 調用實現，保證系統的事務處理和系統性能。
不一樣的業務組件之間須要事物處理的調用，經過內嵌一個內核業務處理模塊的方式進行，如庫存處理相關業務，在訂單模塊和採購模塊都須要調用，經過服務方式很難處理事物，能夠將一個簡化的庫存模塊（如 Jar 包，建議採用 OSGi 架構，WAS8 已經提供了很好的支持）直接內嵌到訂單模塊和採購模塊，以下圖「庫存模塊內嵌到訂單和採購業務組件」所示；工做流引擎也能夠採用這樣的方式，詳見《基於 SOA 的工做流（WF）整合》的說明。
- 基於數據接口調用：同平臺、同廠商開發的業務組件，能夠直接經過數據視圖調用，簡化接口關係，特別開發比較緊密的小組開發的組件之間調用、大數據量的數據調用。不一樣的業務組件之間，純粹的數據調用，能夠直接經過數據接口方式進行調用。
圖 7. 庫存模塊內嵌到訂單和採購業務組件
界面組件和業務邏輯組件應該是能夠徹底獨立的，在徹底實現組件化業務基礎平臺中，界面組件應該是能夠獨立部署的，界面組件和業務邏輯組件之間經過 REST 的服務交互，詳見《 SOA 和 ROA 》所描述的架構說明。業務邏輯組件能夠沒有任何界面，徹底獨立於界面顯示，實現界面和業務的分離。在 J2EE 環境中，徹底能夠實現業務組件所有由 Jar 包組成，不含任何界面內容，界面組件則徹底採用 JSP 實現。
基於數據接口調詳見《 SOA 和 DW 》關於共享庫的描述，在實現全部的組件公用一個數據庫的基礎上，不一樣業務組件須要肯定數據接口做爲共享標準（以下圖所示深藍色部分流程、系統、主數據、業務1、業務2、···），其中有些數據是不須要在不一樣的業務組件進行共享的，則屬於組件內部的數據，（以下圖所示淡藍色部分流程、系統、主數據、業務1、業務2、···），對於業務基礎平臺所包含的業務組件流程、系統、主數據也採用這樣的方式，能夠保證業務基礎平臺向下兼容的進行獨立升級，而不會影響到其餘的業務組件。
圖 8. 數據接口實現思路
內部服務總線能夠不一樣於當前商業 ESB，採用比較複雜的服務總線產品，內部服務總線爲了提升性能，能夠採用簡化處理，僅僅實現服務路由的功能，甚至僅僅實現一個服務註冊管理便可。簡化處理主要是解決當前 ESB 所遇到的性能問題，若是沒有服務動態變化的需求，能夠不考慮服務編排的問題。
業務基礎平臺組件版本
爲了保證業務組件的靈活的擴展，還有一個很重要的因素，就是版本的兼容，要實現以上不一樣層次的接口調用的向下兼容，包含服務接口、API 接口、數據接口，即升級以後的應該和老版本能夠兼容。特別是數據庫接口，必須實現向下兼容，否則沒法實現一體化數據庫，形成升級困難。數據接口並不是是全部的數據模型，主要是針對核心對象模型創建的對象基本關係模型，關於基礎對象模型的創建，能夠參見《基於面向對象（OO）的數據庫設計模式探討 一、2 》所描述「對象關係模型」建模的思路，創建更加穩定的數據模型，保證數據接口的穩定。後續文章會進一步的描述關於創建通用數據模型的思路。
實現了四個層面的接口向下兼容的，組件就能夠獨立升而不會相互影響，保證不一樣業務組件的版本兼容，對於一個業務組件內部，不一樣的模塊之間，須要保證版本一致，如業務基礎平臺的內核，須要跟業務組件的版本保持一致。保證一個和業務組件自己的版本兼容，不一樣的業務組件之間能夠版本不一樣，可是數據結構要兼容。
圖 9. 不一樣版本的業務基礎平臺整合
業務基礎平臺和集成平臺
經過以上分析能夠看到，組件化業務基礎平臺和集成平臺有所不一樣，基於一個業務基礎平臺構建一體化系統有着諸多的限制，和集成平臺相比組件化業務基礎平臺須要更多的標準（如 API、數據接口等），限制也更加嚴格，尤爲是針對不一樣的廠商，同時適應這些標準比較困難，所以更適合用於同一個廠商內部的不一樣業務組件之間的一體化。不一樣廠商的系統或者業務組件，遺留系統，則須要經過集成平臺進行集成，來搭建一體化系統。經過集成平臺，採用通用的標準，對系統進行簡單的改造就能夠實現集成。
爲了使組件化業務基礎平臺具備更加普遍的應用，能夠進一步完善，實現對跨數據庫的管理，用於解決超大型的應用對性能的要求，業務數據能夠分別部署在多臺機器中，數據庫有多個實例，分散數據庫的壓力。同時能夠支持在遵循全部相關標準的基礎上其餘廠商的業務組件，若是實現多個廠商基於一個基礎業務平臺開發，須要其餘的廠商的緊密配合。以下圖所示：
圖 10. 不一樣廠商的組件經過集成平臺進行整合
注：若是部署兩個數據庫，考慮到性能問題，須要考慮將公共組件的數據複製一份到獨立部署的數據庫中，特別是主數據、權限數據等，跟業務緊密相關，具體實現方式不在本文探討的課題。
總結
相比傳統的業務基礎平臺，組件化業務基礎平臺可以實現業務基礎平臺組件之間以及業務組件之間的鬆耦合，能夠實現：
- 由於業務基礎平臺內核分離出來，業務基礎平臺能夠獨立升級，不會影響到業務組件運行和開發，這樣保證了資產的複用，不至於業務基礎平臺升級後，業務組件也必須跟着升級，減小沒必要要的重複開發。
- 每一個業務組件能夠獨立升級，不會影響其餘的業務組件，基於鬆耦合的組件化開發，不一樣的業務組件之間經過標準的接口調用，接口是標準的，不須要對全部的業務組件進行升級。
- 業務基礎平臺能夠獨立部署，獨立部署以後，能夠整合其餘廠商基於開放標準開發的業務組件，從而實現企業級的集成平臺（須要數據集成和應用集成平臺支持）。
參考資料
學習
- 面向服務體系架構（SOA）和數據倉庫（DW）的思考： 本文將圍繞 SOA 和 DW 相結合的思路，基於 IBM 的產品，規劃統一的數據庫，搭建企業級的技術架構。
- 面向服務體系架構（SOA）和業務組件（BC）的思考： 在基於面向服務體系架構（SOA）中，「組件化」是一個很重要的概念，如何進行「組件化」開發是搭建企業級業務基礎平臺時須要考慮的一個重要課題，本文通 過創建業務組件（BC）接口模型及內部結構模型，提供了一個在新開發系統環境下基於 Web 服務和 OSGi 標準的組件化開發模型。
- 基於 SOA 的工做流（WF）整合：當前基於 BPLE 的業務流程管理（BPM）以及基於 XPDL 的工做流（WF）都有成熟的理論和相應的產品支持，特別是在國內，工做流（WF）的應用十分普遍。本文從流程入手，經過創建鬆偶合的工做流組件，將業務流程管理和工做流結合起來，搭建企業級的跨系統的工做流整合平臺。
- 基於面向服務體系架構（SOA）和麪向資源體系架構（ROA）的業務組件模型： 當前 IT 技術迅猛發展，SOA、Web2.0、3G、三網融合等正逐步成爲主流，如何整合 PC、手機、電視、特有設備等各類終端，綜合利用 Flex、JSP、HTML、ASP.NET 等多種客戶端技術成爲你們關注的問題。本文以 J2EE 做爲服務器端，綜合當前各類流行的客戶端技術，以 Web 服務和 REST 架構構建可複用分層組件模型。
- 基於面向對象（OO）的數據庫設計模式探討（1）：面向對象（OO）和三範式（3NF）都是成熟的設計方法，本文基於面向對象設計思想和三範式數據庫設計方法，提出一種實體對象分層建模的思路，其目的是設計簡單明瞭、標準化的數據庫結構，同時可以更好的支持模型驅動模型（MDA）的代碼自動生成和代碼複用，減小代碼編寫工做量。
- 基於面向對象（OO）的數據庫設計模式探討（2）：如今大型的管理系統有幾千甚至上萬張表，但幾乎沒有誰能搞清楚全部的數據結構，如何創建清晰明瞭的數據結構？如何讓其餘人對數據結構更加容易理解，本文以 「基於面向對象（OO）的數據庫設計模式探討（1）」爲基礎進一步對彙總表進行分析，經過創建指標矩陣模型，「模式」化數據庫建模，創建清晰可讀的彙總數據模型。
- WebSphere Application Server 專題：瞭解更多關於 WebSphere Application Server 的知識
- IBM developerWorks 中國 WebSphere 專區：爲使用 WebSphere 產品的開發人員準備的技術信息和資料。這裏提供產品下載、how-to 信息、支持資源以及免費技術庫，包含 2000 多份技術文章、教程、最佳實踐、IBM Redbook 和在線產品手冊。