SOA架構和業務組件(BC)的思考

標籤：

面向服務的體系架構（SOA）和業務組件（BC）的思考

在基於面向服務體系架構（SOA）中，“組件化”是一個很重要的概念，如何進行“組件化”開發是搭建企業級業務基礎平台時需要考慮的一個重要課題，本文通過建立業務組件（BC）介面模型及內部結構模型，提供了一個在新開發系統內容下基於 Web 服務和 OSGi 標準的組件化開發模型。

1 評論：

肖 建國, IT 諮詢顧問, 浪潮軟體

2010 年 3 月 08 日

• 內容

在 IBM Bluemix 雲平台上開發並部署您的下一個應用。

開始您的試用

什麼是業務組件（BC）

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

企業架構（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 的組件化編程在技術上的具體實現，並對業務組件在對外介面、內部結構構成等技術要求做了說明，從而搭建一個靈活、易於擴充、易於維護的組件化開發模式，為企業搭建 整合平台之後如何進行全新的組件化開發提供了一個參考。

SOA架構和業務組件(BC)的思考