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