1. 什麼是業務元件（BC）

元件化、模組化是軟體開發中一個很重要的概念，基於面向服務體系架構（Service Oriented Architecture，SOA）下，如何實現元件化，有各種實現方式，下面通過對各種元件概念的對比，從技術角度提出業務元件（Business Component，BC）定義，並結合對匯流排模式的分析，給出企業服務匯流排和類匯流排的實現方案。

2. 企業架構（EA）

關於企業架構（Enterprise Architecture，EA）和麵向服務體系架構（SOA）在《面向服務體系架構（SOA）和資料倉庫（DW）的思考》（以下簡稱《 SOA 和 DW 》）一文中做了介紹，企業架構包含企業戰略、業務架構、IT 戰略、IT 架構四個部分，IT 架構如下圖 IT 架構模型所示，包含資料架構、應用架構、技術架構和治理架構等四個方面，其中技術架構包含整合平臺、公共服務平臺、基礎平臺（軟體和硬體、網路）和安全平臺等，《 SOA 和 DW 》著重對如何構建資料架構特別是資料儲存做了詳細的闡述，本文基於《 SOA 和 DW 》進一步對如何搭建 SOA 體系進行研究，將著重描述如何基於可擴充套件的、靈活的企業級的整合平臺、公共服務平臺進行元件化開發。
圖 1. IT 架構模型

業務元件（BC）

當前，提到元件（Component）的有很多概念，比如分散式元件 DCOM、J2EE、CORBA 等，IBM 的業務元件模型（Component Business Model，CBM），SOA 中的服務元件架構（Service Component Architecture，SCA）等。本文提到的業務元件（Business Component，BC）定義為一個可以獨立執行的系統或者模組，業務元件的目的是以方便業務元件獨立升級和減少不必要的元件之間的互動為基本原則，通過一定程度的分離，實現《 SOA 和 DW 》中提到的重用（SoftWARe Reuse）。
如果業務元件是共用的，是其它業務元件需要重用的，稱之為公共業務元件（簡稱公共元件），所有的公共元件組成企業架構中技術架構的公共服務平臺，比如主資料管理、系統管理、統一認證管理、通用報表等，這些都是公共元件。

元件業務模型（CBM）

元件業務建模（Component Business Modeling，CBM）是 IBM SOA 構建的一個方法論，通過將組織活動重新分組到數量可管理的離散、模組化和可重用的業務元件中，從而確定改進和創新機會，把業務從領導，控制和執行三個方面進行模組化分析，從而有效的實現業務的有組織的提供服務的能力。CBM 的價值是提供一個可以推廣的框架，用來創造順應組織戰略的可以運營的指導方向，同時 CBM 也用來按照業務和資源的優先級別和相互關聯的程度來構建和順應戰略的發展方向，其中包括建立一個溝通的機制來理解整個業務發展的方向。通過 CBM 建立了 SOA 的規劃的方向，為實施 SOA 奠定基礎。本文所提到的業務元件在粒度上基本對應著元件業務模型（CBM）的粒度，但是本文中的業務元件（BC）更多從技術實現角度考慮，或大於，或小於業務元件模型（CBM）提到的業務元件概念。

服務元件框架（SCA）

服務元件框架（Service Component Architecture，SCA）由 BEA、IBM、Oracle 等中介軟體廠商聯合制定的一套符合 SOA 思想的規範。服務元件框架（SCA）提供了一套可構建基於面向服務的應用系統的程式設計模型，它的核心概念是服務及其相關實現。SCA 元件組成程式集，程式集是服務級的應用程式，它是服務的集合，這些服務被連線在一起，並進行了正確的配置。在 SCA 標準下，SCA 由域（Domain）、組合構（Composite）、構件（Component）三個級別組成，構件對應著細粒度的 Web 服務，域對應著粗粒度的 Web 服務。SCA 程式集執行在兩個級別：第一種情況，程式集是“大規模程式設計”（Programming in the Large 或 Megaprogramming）的一組鬆散連線的服務元件；另一種情況，程式集是“小規模程式設計”（Programming in the Small）內的一組鬆散連線的元件。二者的區別在於， “大規模程式設計”對應著應用，“小規模程式設計”對應著模組，一般來說，服務元件對應著“小規模程式設計”，即模組的概念。
本文所提到的業務元件（BC），是比 SCA 元件更大範圍的概念，這幾個概念的顆粒度從大到小的排列順序如下：系統（每個企業只有一個系統）、應用、業務元件（BC）、模組、SCA 元件（粗粒度服務）。
匯流排模式（Bus）和 SOA、OSGi

匯流排（Bus）

一般指通過分時複用的方式，將資訊以一個或多個源部件傳送到一個或多個目的部件的一組傳輸線。基於匯流排模式的有很多應用，在微機的技術中，有三種匯流排，地址匯流排 Address Bus，資料匯流排 Data Bus，控制匯流排 Control Bus。在通訊架構下，交換機也是一種匯流排，在 SOA 中，匯流排一般指企業服務匯流排（Enterprise Service Bus，ESB），企業服務匯流排可以連線所有協議的各種介面，但是最理想的是基於 XML 的 Web 服務標準。

OSGi —— Open Service Gateway Initiative

1999 年 OSGi 聯盟成立，旨在建立一個開放的服務規範，為通過網路向裝置提供服務建立開放的標準，是開放業務閘道器的發起者。OSGi 是一個 Java 框架，該框架能裝載以 Bundle 為單位的資源。Bundle 能提供服務或響應處理請求，而他們之間的依賴都是被管理起來的，正如一個 Bundle 能從容器中獲得它所需要的管理。每個 Bundle 都可以有它自己的內部類路徑，所以它可以作為獨立的服務單元。所有的這些符合 OSGi 規範的 Bundle 理論上都可以安裝在任何符合 OSGi 規範的容器中。OSGi 具有可動態改變系統行為，熱插拔的外掛體系結構，高可複用性，高效性等等。在 J2EE 環境下，基於匯流排（Bus）模式的思考，可以進一步推廣到 Java Class，基於 OSGi 的微核心，建立一個類匯流排（Java Class Bus，JCB）。
通過以上概念的分析，我們可以看到，本文提到的業務元件（BC），是指具體的一個軟體實現，業務元件（BC）跟 IBM 的業務元件模型（CBM）中提到的業務元件有一定的對應關係，但是一般來說，業務元件（BC）可能包含 CBM 中的多個業務元件或者一個 CBM 的業務元件封裝成多個業務元件（BC）。另外 CBM 更多的是從業務角度來考慮，是業務上的概念，業務元件（BC）則是從技術實現角度考慮。服務元件框架（SCA）定義的粒度和業務元件（BC）相比來說，SCA 劃分的還是很細，業務元件（BC）是更粗粒度的一個軟體實現概念。

業務元件（BC）模型

根據業務元件的作用不同，可以將業務元件分成公共業務元件和普通業務元件，公共業務元件包含統一使用者元件、統一認證元件、門戶元件、流程元件、報表元件、BI 元件、GIS 元件等，這些元件的共同特點是多個業務元件或者系統會用到這個業務元件。
元件的粒度和對外介面設計決定了元件的可複用和鬆耦合（Loose Coupling）特性。粒度過大，靈活性小，難以實現複用，粒度過小，管理成本提升，使得複用性也很難改善；介面和實現的分離 , 保證各項業務元件在提供標準化的服務介面的前提下可以替換各種可選的實現 , 而不會影響系統其它部分的實現，介面設計不當，對於元件的耦合會有很大的影響。

業務元件的粒度

業務元件的粒度根據需要可以不同，既可能是獨立執行的子系統 , 也可能是程式模組。業務元件是提高應用系統靈活性和複用的重要基礎。業務元件粒度太小，造成元件數量多，元件之間互動多，管理困難，效能低下；業務元件粒度粗，功能複雜，功能之間關係緊密，升級困難（可以獨立升級往往會作為確定一個業務元件範圍的重要因素），很難實現重用。因此找到一個合適的業務元件粒度是很重要的事情。
根據前文所定義的業務元件定義，我們把整個企業的所有軟體稱之為系統，即一個企業只有一個系統；系統下面劃分成若干應用，每個應用完成一個相對獨立的業務功能，比如財務管理、人力資源管理等，一般來說是一個廠商獨立完成（後文還會提到，如果是基於一個業務基礎平臺，多個廠商可以在一個應用中）；應用下面劃分成若干業務元件，業務元件是相對獨立的功能，其可以進一步劃分成若干模組，從而形成了系統－應用－業務元件－模組這樣四個層次的模型。根據 SCA 的定義，模組下面可以進一步劃分成程式集為更小的粒度。從軟體複用角度來看，業務元件是獨立部署的最小顆粒，模組是複用的最小顆粒。
除了業務元件需要粒度控制外，Web 服務的粒度控制也是一項十分重要的設計任務。通常來說 , 對於將暴露在整個系統外部的服務推薦使用粗粒度的介面 , 而相對較細粒度的服務介面通常用於企業和機構系統架構的內部。從技術上講 , 粗粒度的服務介面可能是一個特定服務的完整執行 , 而細粒度的服務介面可能是實現這個粗粒度服務介面的具體的內部操作。雖然細粒度的介面能為服務請求者提供了更加細化和更多的靈活性 , 但同時也意味著引入較難控制的互動模式易變性 , 也就是說服務的互動模式可能隨著不同的服務請求者而不同。如果暴露這些易於變化的服務介面給系統的外部使用者 , 就可能造成外部服務請求者難於支援不斷變化的服務提供者所暴露的細粒度服務介面。而粗粒度服務介面保證了服務請求者將以一致的方式使用系統中所暴露出的服務。
業務元件的鬆耦合設計
耦合性（Coupling）是程式結構中各個模組之間相互關聯的度量，它取決於各個模組之間介面的複雜程度、呼叫模組的方式以及哪些資訊通過介面。耦合性由鬆到緊可以分成七種：非直接耦合（Nondirect Coupling）、資料耦合（Date Coupling）、標記耦合（Stamp Coupling）、控制耦合（Control Coupling）、外部耦合（External Coupling）、公共耦合（Common Coupling）、內容耦合（CONTENT COUPLING）。非直接耦合是指兩個模組之間沒有直接關係，這種耦合的模組獨立性最強。資料耦合，彼此之間是通過資料引數 ( 不是控制引數、公共資料結構或外部變數 ) 來交換輸入、輸出資訊的，模組之間的獨立性比較強。標記耦合是指一組模組通過引數表傳遞記錄資訊，就是標記耦合，這要求這些模組都必須 清楚該記錄的結構，並按結構要求對此記錄進行操作，應儘量避免這種耦合，它使在資料結構上的操作複雜化了。在業務元件設計模型中業務元件之間儘量實現非直接耦合（匯流排模式，推薦使用）和資料耦合（共享庫模式，控制使用），通過定義清晰的 Web 服務進行互動，業務元件內部的模組之間可以通過標準化的 Web 服務或者資料表來進行共享。
J2EE 架構下業務元件（BC）實現

業務元件鬆耦合設計－OSGI

業務元件以 Web 服務的方式提供介面，通過企業服務匯流排連線，業務元件內部為了實現高可複用性和高效性，採用基於 OSGi 標準進行構建模組，實現內部模組之間的鬆耦合，即在業務元件內部基於 OSGi 標準進行模組化設計，將業務元件進一步分解為鬆耦合的模組（Bundle），使得業務元件本身更加靈活。
基於 OSGi 標準，業務元件內部的模組通過一個具有動態載入類功能的微核心連線，統一管理各個模組，為了便於管理，將不同模組之間的類介面採用服務註冊的方式進行管理，具有類動態載入功能的微核心和類介面管理組成類匯流排（JCB）的基本功能，為了更好的實現重用，有些模組是共用的，比如資料訪問模組、日誌管理模組等。
在一個應用中，不同業務元件公用的功能，作為應用內部的公共元件，一個應用中部署一個公共元件即可，各個業務元件共用。在一個業務元件中，不同模組公用的功能，作為公共模組，相當於工具類，公共模組需要在每個業務元件中部署。公共服務平臺作為企業級的公共服務對外提供企業級的 Web 服務，比如主資料管理等。業務元件構成如下圖所示：
圖 2. 業務元件模型（公共類－公共元件－公共服務平臺）

注：
業務元件中的公共元件和公共服務平臺的差異是公共元件是應用內部的，提供應用級別的服務；公共服務平臺則是面向企業整個系統的，是提供系統級的服務，兩者有時候可以互相替換，主要是看其處於那個級別。
基於 IBM 產品體系的實現
本文提到的整合平臺，基於 IBM 的產品共體系在實際搭建的時候需要包含應用伺服器（產品：WAS）、流程整合伺服器（產品：WPS，實現服務匯流排和流程編排）等，關於整合平臺的詳細描述，詳見《 SOA 和 DW 》一文中“基於 IBM 產品體系的實現”的描述。
業務元件（BC）在 WAS 中的部署
首先來看一下在 J2EE 架構模式下檔案格式（以 WAS 為例）。在 J2EE 架構下，檔案格式有三種，分別是 EAR、WAR、JAR，另外還有一個特殊的 JAR 即基於 OSGi 標準的 Bundle，共四類檔案：
● EAR 檔案（file Enterprise Achieve）除了包含 JAR、WAR 以外，還包括 EJB 元件、部署檔案 application-client.xml、web.xml、application.xml 等全部企業應用程式。
● WAR 檔案（file web Achieve）包含 Servlet、JSP 頁面、JSP 標記庫、JAR 庫檔案、HTML/XML 文件和其他公用資原始檔，如圖片、音訊檔案等全部 Web 應用程式。在一個 EAR 檔案中可以有多個 WAR。〔在 WAS 環境下，如果設定在 EAR 中用一個類載入器，這樣不同的 WAR 之間可以直接呼叫 Java Class，WAR 之間是緊耦合的，不建議採用。〕
● JAR 檔案（Java Achieve）按 Java 格式壓縮的類包，包含內容 class、properties 檔案，是檔案封裝的最小單元。但是普通的 JAR 檔案，只是一個檔案的集合，沒有具體的意義。
● Bundle，基於 OSGi 標準的一種特殊的 JAR 檔案，每個 Bundle 也包含一個 META-INF/MANIFEST.MF 檔案，這個檔案會宣佈匯出哪些包 (Package) 以及匯入哪些包。只有那些匯出包中的類才能被其他 Bundle 所使用，而其他包都只面向包的內部成員，包裡的類也只能在自身 Bundle 中使用。一個簡化的處理思路是直接採用包 (Package)，但是無法實現類的動態載入和對介面進行管理，不具有鬆耦合特性。〔 WAS 從版本 6.1 開始支援 OSGi 〕
從以上檔案結構可以看到，JAR 之間可以進行類的呼叫，很容易實現不同 JAR 之間的事務處理，且具有更高的效能，結合 OSGi，通過“類匯流排”進行管理所有 JAR（Bundle）對外開放的介面，從而以“匯流排”（Bus）的方式管理不同 JAR 之間的類呼叫。不同的 WAR 之間各種資源不共享，為了實現重用，需要設定一些公共模組，即公共 Bundle；不同的 WAR 之間互動，需要以 Web 服務的方式進行連線，需要建立企業服務匯流排（ESB）管理所有的 Web 服務，實現 WAR 之間呼叫。在一個 EAR 中，可以設定不同 WAR 之間共享 Session，從而方便的實現單點登入以及其它的公共資訊，這些資訊將在這個 EAR 環境中共享。
根據前文所述業務元件（BC）的定義，業務元件適合於在 WAR 檔案層面進行劃分，即一個 WAR 作為一個業務元件，一個或者幾個 WAR 組成一個應用（EAR），多個應用構成企業的系統；業務元件內部進一步劃分為多個模組（Bundle），每個模組相對獨立，可以獨立維護，獨立升級和安裝，以外掛的方式通過類匯流排進行關聯。為了實現重用，在 EAR 層面，將企業級的業務元件單獨部署，比如主資料、統一認證、工作流等，建立公共服務平臺；在 WAR 層面，各廠商的公共的業務元件單獨封裝在公共元件（WAR）中，如系統管理、系統引數管理等。在模組級別採用公共模組的方式，在各個 WAR 中以工具模組（Bundle）方式提供，如資料庫訪問、日誌（Log4j）等。公共元件（WAR）、內部服務匯流排（ESB）和類匯流排（JCB）、工具模組（Bundle）組成應用系統的業務基礎平臺（Business Platform）（如浪潮的 Loushang 平臺）。
在系統部署的時候，一臺伺服器上安裝一個 Websphere 例項，一個例項根據主機的效能可以安裝多個節點（Node），每個節點（Node）可以安裝多個虛擬機器（JVM），每個虛擬機器可以安裝多個 EAR 應用，每個 EAR 有多個 WAR，不同 WAR 之間檔案不會衝突，WAR 內部採用 OSGI 標準分成多個模組（Bundle）。不同公司的系統是不同的 EAR，同一個公司可以有多個 EAR。如下圖所示：
圖 3. WAS 部署模型（系統－應用－業務元件－模組）

EAR 之間資料交換採用通過企業級服務匯流排（ESB）的 Web 服務，大資料量資料共享在資料匯流排上通過企業級的共享資料庫進行共享，通過資料匯流排共享的資料不是實時的，是有一定的延誤或者準實時的。共享庫是企業的資產，不隸屬於任何一個廠商。
WAR 之間資料交換採用通過企業或者內部的服務匯流排（ESB）的 Web 服務，不同的 WAR 共用一個數據庫，但是資料表根據 WAR 的職責進行劃分，每個 WAR 可以只讀所有的共享的資料表，但是隻能寫自己控制的表，對其它 WAR 控制的表、表結構很複雜或者易變的表的讀作操，都應通過 Web 服務進行，以實現 WAR 之間的鬆耦合。一個 EAR 中的共享資料庫（對企業來說是私有資料層）在各個 WAR 之間結合更加緊密，一般採用直接訪問的方式，不在私有資料層存放共享庫資料，私有資料僅僅是一些控制類或者跟業務無關，不需要共享的資料。企業級共享庫一般從效能、不同廠家便於控制等角度考慮，資料同步是準實時的，資料在各個 EAR 的私有資料層一般會有一個拷貝，讓各個 EAR 之間相對更加獨立。以上僅僅是一般原則，如果是一個廠商，兩個 EAR 之間也可以像一個 EAR 共享一個數據庫。EAR 和共享庫之間的關係如下圖 EAR 和共享庫的關係所示：
圖 4. EAR 和共享庫的關係

Bundule 之間資料交換可以類似 WAR 的 Web 服務呼叫，也可以直接通過類匯流排，呼叫 Bundule 對外發布的介面，特別是需要具有事務處理能力和更高的效能要求的情況。一個 WAR 內原則上不再劃分資料表的控制，由 WAR 自己內部進行管理。
一般來說，WAR 是相對比較穩定的，不需要完全進行替換升級，日常的變更是通過 Bundle 來實現的，由於 Bundle 在應用方面是基於外掛的方式進行開發的，資料方面由於業務元件本身是基於標準資訊服務或者作為企業資源的開放的資料表、檢視（Web 服務和資料模型，作為企業的兩個資產），因此可以實現熱插拔，保證了系統可以連續執行，而不至於因為系統升級而影響到業務的執行或者最小程度的營銷業務的執行。
在實際部署的情況下，有可能會出現整個企業只有一個 EAR（功能簡單，最極端情況），或者一個廠商把應用分別部署在不同的 EAR，需要根據企業規模，主機部署等，從效能、易於管理等角度考慮。由於 WAR 之間是鬆耦合的，基於企業服務匯流排（ESB）和資訊服務匯流排（ISB），可以實現靈活的組裝，因此一個或者多個 WAR 可以進行靈活組裝部署。
以上基於 J2EE 的應用伺服器 WAS（IBM WebSphere Application Server，WAS），對 J2EE 架構模式下的檔案體系進行分析，針對前文提到的業務元件模型實現提供一個實現建議。
業務元件（BC）實現舉例
一般企業常用到的應用包含人力資源、協同辦公、財務管理、營銷管理、生產管理等幾個主要的應用，根據前文所述架構，基於 J2EE 環境按照以下方式進行構建：首先，人力資源、協同辦公、財務管理、營銷管理、生產管理可以認五個應用，一般來說可能由五個廠商分別提供，因此可以作為五個獨立的 EAR，分別進行部署，考慮到為減少不同廠商之間的影響，一般會分別安裝在五臺伺服器上，或者安裝在不同的虛擬機器上，（有時候可能是一個廠商提供，會在一個 EAR 中，如財務管理和人力資源在一塊，因此 WAR 是可以靈活選擇進行部署的）。五個系統之間如果需要實時互動，則完全通過企業的整合平臺中的 ESB 進行互動。五個應用之間可以建立企業級的共享資料庫。
對於營銷管理應用（EAR）來說，其內部可以進一步劃分成客戶關係、供應商管理、購銷存管理等多個個業務元件，作為三個獨立的 WAR，三個業務元件之間如果需互動通過營銷管理應用 EAR 自己的 ESB（從企業角度來說，需要建立聯邦 ESB）進行互動，或者通過企業的整合平臺中的 ESB 進行互動。三者共用一個數據庫，邏輯上把表劃分成三個部分，分別由三個業務元件進行管理，每個業務元件有自己的控制表，對於其它業務元件控制的表只讀，如果需要訪問，如前文所述，通過其它業務元件提供的服務進行訪問。
客戶關係管理還可以進一步劃分成市場管理、銷售管理、服務管理等多個模組，為了便於管理，可以在此基礎上再劃分的更細一層，比如市場管理可以進一步劃分成客戶分類管理、客戶群管理、客戶拜訪管理等模組（Bundle），模組（Bundle）之間可以通過類直接呼叫，不同的模組之間的呼叫通過類匯流排實現。從管理和系統升級排程考慮，模組不宜太少，也不易太多。
以上就一般企業常用到的功能按照前文所描述的模型基於 J2EE 架構上具體實現做了說明，可以作為元件化開發的一個參考。
回頁首
總結
本文通過對業務元件（BC）的定義，特別是描述和和當前相關的 CBM、SCA 等元件概念的關係，描述了基於 SOA 的元件化程式設計在技術上的具體實現，並對業務元件在對外介面、內部結構構成等技術要求做了說明，從而搭建一個靈活、易於擴充套件、易於維護的元件化開發模式，為企業搭建 整合平臺之後如何進行全新的元件化開發提供了一個參考。