業務基礎平臺是業務邏輯應用和基礎架構平臺之間的一個中間層，解決 “應用軟件的業務描述和操作系統平臺、軟件基礎架構平臺之間的交互與管理問題”。很多國內軟件廠商，很難在操作系統平臺和軟件基礎架構平臺上有所作為，因此國內眾多的軟件廠商紛紛推出自己的業務基礎平臺，把業務基礎平臺看作自己的核心技術。當前比較流行的業務基礎平臺大多都是基于早期的技術架構，雖然經過了多年的發展，但是由于技術架構不是完全基于 SOA 的組件化概念搭建，組件化支持并不是很徹底，如何在 SOA 下搭建組件化業務基礎平臺成為當前軟件開發商所面臨的新課題，本文將會基于組件化的概念，介紹一種搭建組件化業務基礎平臺的思路，首先我們看一下什么是“業務基礎平臺”，以及組件化概念。
如前言所述，業務基礎平臺是業務邏輯應用和基礎架構平臺之間的一個中間層，解決 “應用軟件的業務描述和操作系統平臺、軟件基礎架構平臺之間的交互與管理問題”。操作系統平臺解決了“應用軟件系統與硬件之間的交互與管理問題”，軟件基礎架構平臺解決了“應用軟件系統與操作系統平臺之間的交互與管理問題”，而業務基礎平臺則是解決了“應用軟件的業務描述與操作系統平臺、軟件基礎架構平臺之間的交互與管理問題”。如下圖所示：
一般業務基礎平臺都包含兩個部分，運行環境和開發環境，開發環境主要用于解決如何更加快速的開發，也是業務基礎平臺的核心內容，本文主要介紹業務基礎平臺的運行環境架構，關于開發環境將不在進一步論述。
業務組件（Business Component，BC）是一個可以獨立運行的系統或者模塊，業務組件的目的是以方便業務組件獨立升級和減少不必要的組件之間的交互為基本原則，通過一定程度的分離，實現軟件重用（Software Reuse）。如果業務組件是共用的，是其它業務組件需要重用的，稱之為公共業務組件（簡稱公共組件），所有的公共組件組成企業架構中技術架構的公共服務平臺，比如主數據管理、系統管理、統一認證管理、通用報表等，這些都是公共組件。詳見之前的文章《面向服務體系架構（SOA）和業務組件（BC）的思考》（以下簡稱 SOA 和 BC）關于業務組件和公共組件的說明。
基于組件化業務基礎平臺和傳統的業務基礎平臺主要的差異在于組件化業務基礎平臺具有更多的靈活性、可擴展性，能夠更加方便的進行組件升級和組件維護。特別是對于大型的行業軟件來說，易于升級、易于維護，能夠靈活的擴展成為評測一個業務基礎平臺的一個重要標準，隨著業務的不斷發展，很多一體化行業軟件代碼數量已經超過 1G，如何對如此龐大規模的代碼進行維護、升級成為軟件開發者和運維管理者日益關注的一個課題，代碼關系復雜、系統啟動慢成為一個大型系統所面臨的一個主要矛盾。組件化業務基礎平臺主要用于解決簡化開發，快速系統維護的問題，以下通過對兩種業務基礎平臺的對比，對組件化業務基礎平臺的組件實現、調用方式、所包含的公共組件及組件進行說明。
當前在 J2EE 框架下業務基礎平臺基本上是采用了“Spring Framework”、“Expresso Framework”、等開源軟件為基礎的框架，業務系統基于業務基礎平臺進行開發，在一個企業內部，很容易形成基于一個業務基礎平臺橫向開發出多個業務模塊，甚至是跨行業的業務組件，基于一個業務基礎平臺開發的系統，所有的業務組件可以基于一個數據庫運行，搭建一體化的業務應用系統。當前常見的業務基礎平臺包括浪潮 Loushang 平臺、SAP 的 Net Weaver、金蝶 Apusic、普元 EOS 等。其架構如下圖所示：
但是這種模式存在幾個重大的缺陷：
如何既能實現一體化，又可以解決以上問題是當前業務基礎平臺需要解決的問題。
在《面向服務體系架構（SOA）和數據倉庫（DW）的思考》（以下簡稱《 SOA 和 DW 》）一文中曾經提出一個原則：“軟件的核心是重用，方法是分離，關鍵是標準”，組件化基礎業務平臺依然是遵循這個原則。隨著 SOA 技術的逐步發展，SOA 已經成為像面向對象一樣雖然不像“云計算”那樣時髦，卻成為一個重要的軟件體系設計模式。由于很多軟件都是基于業務基礎平臺進行開發的，業務基礎平臺的組件化成為組件化開發的一個基礎的要求，如果業務基礎平臺沒有實現組件化，組件化開發還是停留在之前的遺留系統改造的概念中。如何實現業務基礎平臺的組件化，如何利用組件化對業務基礎平臺進行改造成為業務基礎平臺關注的一個焦點。
組件化開發，首先是業務基礎平臺本身的組件化，把業務基礎平臺看成是一個獨立的組件，即《 SOA 和 BC 》所描述的基于企業集成平臺（企業門戶、應用集成、數據集成）的公共組件所描述的內容。
業務基礎平臺的組件化，并不是所有的內容全部組件化，有些內容是無法分離出去的，因此首先要把業務基礎平臺的內核分離出來，建立一個業務基礎平臺的微內核，微內核是跟每一個業務組件緊密相關的。然后把業務基礎平臺中可以分離出來的內容單獨作為一個組件，即公共組件，從而實現業務組件和公共組件的分離。
業務組件和公共組件使用一個數據庫，通過公共組件及相關的標準實現整合，如果還有已有的系統，則通過企業集成平臺進行整合。如下圖所示：
公共服務組件包含系統管理、流程管理、主數據管理、元數據管理等，在數據層面分別對應著系統數據、流程數據、主數據和元數據等數據。考慮到公共服務組件的獨立性，特別是保證每一個組件獨立升級之后不會影響到其他的公共服務組件以及業務組件，因此需要對公共服務組件進行隔離。
系統管理主要包含：用戶管理、功能管理、權限管理、認證管理等功能，其中需要特別注意的是實現不同的業務組件的統一認證的問題，即實現不同的業務組件部署在不同的應用下（在 J2EE 環境下為 EAR 文件）的單點登錄。
主數據管理主要包含：主數據模型管理、主數據質量控制、主數據監控等功能，主要實現各個組件之間公用的基礎數據的管理，需要考慮主數據在那個業務組件中進行維護的問題，不同的主數據需要在不同的業務組件中完成，而不是所有的主數據都在主數據管理組件完成。
流程管理主要包含：代辦任務管理、流程自定義、流程引擎等功能，主要實現對代辦任務的統一管理、流程的管理。流程管理主要實現流程和業務的分離，并實現辦公用的靈活流程、業務用的固定流程，詳見《基于 SOA 的工作流（WF）整合》的描述。
元數據的管理主要包含：元數據管理、數據質量監控等功能，主要實現技術元數據和業務元數據的管理。
在實際開發應用中，性能是很重要的一個非功能性需求，特別是針對大型的應用系統，性能是決定項目成敗的一個關鍵因素，業務基礎平臺的架構決對性能問題有著重大的影響。如何在實現松耦合的基礎上，進一步提升性能問題（包括保證數據庫事務處理），是大型應用軟件的業務基礎平臺必須要解決的一個問題，不能僅僅是為了組件化而組件化，如果不能解決性能問題，組件化就不能在大型的應用系統中得到廣泛應用，因此需要根據在實際開發過程中碰到的不同的場景，采用不同的調用方式，除了組件化中提到的服務，還有要有其他的方式作為補充，即能實現松耦合，又可以保證性能，實現不同層次的不同調用。
實現組件化，首先要定義清晰、簡單的業務組件界面，特別是業務組件和公共組件之間的界面，然后建立一個兼顧松耦合、性能的調用方式及不同的調用方式的標準。在《 SOA 和 ROA 》描述了業務組件接口模型，除了人機交互界面（沒有組件之間的調用關系），組件之間的調用關系主要有服務接口和數據接口兩種。如下圖所示：
在上述接口模型中，組件的接口是面向集成平臺的，在組件化業務基礎平臺組件模型中，由于是基于一個統一業務基礎平臺，因此可以增加一個通過 API 調用的接口方式，提高調用效率和保證事務處理，同時為了進一步優化性能，服務接口可以分成重量級的 SOAP 和輕量級的 REST 兩種，因此可以把組件之間的調用關系進一步分成四種（如下圖所示）。在不同的層級，從性能和耦合性兩個角度，組件間可以選擇不同的調用方式， 具體采用那種調用關系主要是考慮性能、接口復雜度、耦合性等問題，不同的業務組件，特別是不同的廠商之間開發的組件采用基于 SOAP 的服務，同一個廠商開發的不同組件之間通過 REST 服務進行調用或者直接采用數據接口進行調用。一個業務組件內部，業務組件和公共模塊之間的調用，以及為了保證事務處理，直接通過在不同的業務組件中內嵌模塊的方式，實現 API 調用，如下圖所示：
業務組件之間于 SOAP 的 Web 服務調用或者 REST Web 服務調用，因為基于 SOAP 的 Web 服務擁有眾多的標準，可以方便的實現跨平臺調用，適用于不同廠商之間的業務組件調用，同一個廠商之間的不同組件調用可以直接通過能夠提供很好性能的 REST Web 服務調用。
不同的業務組件之間需要事物處理的調用，通過內嵌一個內核業務處理模塊的方式進行，如庫存處理相關業務，在訂單模塊和采購模塊都需要調用，通過服務方式很難處理事物，可以將一個簡化的庫存模塊（如 Jar 包，建議采用 OSGi 架構，WAS8 已經提供了很好的支持）直接內嵌到訂單模塊和采購模塊，如下圖“庫存模塊內嵌到訂單和采購業務組件”所示；工作流引擎也可以采用這樣的方式，詳見《基于 SOA 的工作流（WF）整合》的說明。
界面組件和業務邏輯組件應該是可以完全獨立的，在完全實現組件化業務基礎平臺中，界面組件應該是可以獨立部署的，界面組件和業務邏輯組件之間通過 REST 的服務交互，詳見《 SOA 和 ROA 》所描述的架構說明。業務邏輯組件可以沒有任何界面，完全獨立于界面顯示，實現界面和業務的分離。在 J2EE 環境中，完全可以實現業務組件全部由 Jar 包組成，不含任何界面內容，界面組件則完全采用 JSP 實現。
基于數據接口調詳見《 SOA 和 DW 》關于共享庫的描述，在實現所有的組件公用一個數據庫的基礎上，不同業務組件需要確定數據接口作為共享標準（如下圖所示深藍色部分流程、系統、主數據、業務一、業務二、···），其中有些數據是不需要在不同的業務組件進行共享的，則屬于組件內部的數據，（如下圖所示淡藍色部分流程、系統、主數據、業務一、業務二、···），對于業務基礎平臺所包含的業務組件流程、系統、主數據也采用這樣的方式，可以保證業務基礎平臺向下兼容的進行獨立升級，而不會影響到其他的業務組件。
內部服務總線可以不同于當前商業 ESB，采用比較復雜的服務總線產品，內部服務總線為了提高性能，可以采用簡化處理，僅僅實現服務路由的功能，甚至僅僅實現一個服務注冊管理即可。簡化處理主要是解決當前 ESB 所遇到的性能問題，如果沒有服務動態變化的需求，可以不考慮服務編排的問題。
為了保證業務組件的靈活的擴展，還有一個很重要的因素，就是版本的兼容，要實現以上不同層次的接口調用的向下兼容，包含服務接口、API 接口、數據接口，即升級之后的應該和老版本可以兼容。特別是數據庫接口，必須實現向下兼容，不然無法實現一體化數據庫，造成升級困難。數據接口并非是所有的數據模型，主要是針對核心對象模型建立的對象基本關系模型，關于基礎對象模型的建立，可以參見《基于面向對象（OO）的數據庫設計模式探討 1、2 》所描述“對象關系模型”建模的思路，建立更加穩定的數據模型，保證數據接口的穩定。后續文章會進一步的描述關于建立通用數據模型的思路。
實現了四個層面的接口向下兼容的，組件就可以獨立升而不會相互影響，保證不同業務組件的版本兼容，對于一個業務組件內部，不同的模塊之間，需要保證版本一致，如業務基礎平臺的內核，需要跟業務組件的版本保持一致。保證一個和業務組件本身的版本兼容，不同的業務組件之間可以版本不同，但是數據結構要兼容。
通過以上分析可以看到，組件化業務基礎平臺和集成平臺有所不同，基于一個業務基礎平臺構建一體化系統有著諸多的限制，和集成平臺相比組件化業務基礎平臺需要更多的標準（如 API、數據接口等），限制也更加嚴格，尤其是針對不同的廠商，同時適應這些標準比較困難，因此更適合用于同一個廠商內部的不同業務組件之間的一體化。不同廠商的系統或者業務組件，遺留系統，則需要通過集成平臺進行集成，來搭建一體化系統。通過集成平臺，采用通用的標準，對系統進行簡單的改造就可以實現集成。
為了使組件化業務基礎平臺具有更加廣泛的應用，可以進一步完善，實現對跨數據庫的管理，用于解決超大型的應用對性能的要求，業務數據可以分別部署在多臺機器中，數據庫有多個實例，分散數據庫的壓力。同時可以支持在遵循所有相關標準的基礎上其他廠商的業務組件，如果實現多個廠商基于一個基礎業務平臺開發，需要其他的廠商的緊密配合。如下圖所示：
注：如果部署兩個數據庫，考慮到性能問題，需要考慮將公共組件的數據復制一份到獨立部署的數據庫中，特別是主數據、權限數據等，跟業務緊密相關，具體實現方式不在本文探討的課題。
相比傳統的業務基礎平臺，組件化業務基礎平臺能夠實現業務基礎平臺組件之間以及業務組件之間的松耦合，可以實現：
