面向服務(wù)體系架構(gòu)和業(yè)務(wù)組件的思考

1、 面向服務(wù)體系架構(gòu)和業(yè)務(wù)組件的思考 摘要： 在基于面向服務(wù)體系架構(gòu)（SOA）中，“組件化”是一個很重要的概念，如何進(jìn)行“組件化”開發(fā)是搭建企業(yè)級業(yè)務(wù)基礎(chǔ)平臺時需要考慮的一個重要課題，本文通過建立業(yè)務(wù)組件（BC）接口模型及內(nèi)部結(jié)構(gòu)模型，提供了一個在新開發(fā)系統(tǒng)環(huán)境下基于Web服務(wù)和OSGi標(biāo)準(zhǔn)的組件化開發(fā)模型。什么是業(yè)務(wù)組件（BC） 組件化、模塊化是軟件開發(fā)中一個很重要的概念，基于面向服務(wù)體系架構(gòu)（Service Oriented Architecture，SOA）下，如何實現(xiàn)組件化，有各種實現(xiàn)方式，下面通過對各種組件概念的對比，從技術(shù)角度提出業(yè)務(wù)組件（Business Component，BC）

2、定義，并結(jié)合對總線模式的分析，給出企業(yè)服務(wù)總線和類總線的實現(xiàn)方案。企業(yè)架構(gòu)（EA） 關(guān)于企業(yè)架構(gòu)（Enterprise Architecture，EA）和面向服務(wù)體系架構(gòu)（SOA）在面向服務(wù)體系架構(gòu)（SOA）和數(shù)據(jù)倉庫（DW）的思考（以下簡稱SOA和DW）一文中做了介紹，企業(yè)架構(gòu)包含企業(yè)戰(zhàn)略、業(yè)務(wù)架構(gòu)、IT戰(zhàn)略、IT架構(gòu)四個部分，IT架構(gòu)如下圖IT架構(gòu)模型所示，包含數(shù)據(jù)架構(gòu)、應(yīng)用架構(gòu)、技術(shù)架構(gòu)和治理架構(gòu)等四個方面，其中技術(shù)架構(gòu)包含集成平臺、公共服務(wù)平臺、基礎(chǔ)平臺（軟件和硬件、網(wǎng)絡(luò)）和安全平臺等，SOA和DW著重對如何構(gòu)建數(shù)據(jù)架構(gòu)特別是數(shù)據(jù)存儲做了詳細(xì)的闡述，本文基于SOA和DW進(jìn)一步對如何搭建

3、SOA體系進(jìn)行研究，將著重。描述如何基于可擴展的、靈活的企業(yè)級的集成平臺、公共服務(wù)平臺進(jìn)行組件化開發(fā)。圖 1. IT架構(gòu)模型業(yè)務(wù)組件（BC） 當(dāng)前，提到組件（Component）的有很多概念，比如分布式組件DCOM、J2EE、CORBA等，IBM的業(yè)務(wù)組件模型（Component Business Model，CBM），SOA中的服務(wù)組件架構(gòu)（Service Component Architecture，SCA）等。本文提到的業(yè)務(wù)組件（Business Component，BC）定義為一個可以獨立運行的系統(tǒng)或者模塊，業(yè)務(wù)組件的目的是以方便業(yè)務(wù)組件獨立升級和減少不必要的組件之間的交互為基本原則，

4、通過一定程度的分離，實現(xiàn)SOA和DW中提到的重用（SoftWARe Reuse）。如果業(yè)務(wù)組件是共用的，是其它業(yè)務(wù)組件需要重用的，稱之為公共業(yè)務(wù)組件（簡稱公共組件），所有的公共組件組成企業(yè)架構(gòu)中技術(shù)架構(gòu)的公共服務(wù)平臺，比如主數(shù)據(jù)管理、系統(tǒng)管理、統(tǒng)一認(rèn)證管理、通用報表等，這些都是公共組件。組件業(yè)務(wù)模型（CBM） 組件業(yè)務(wù)建模（Component Business Modeling，CBM）是IBM SOA構(gòu)建的一個方法論，通過將組織活動重新分組到數(shù)量可管理的離散、模塊化和可重用的業(yè)務(wù)組件中，從而確定改進(jìn)和創(chuàng)新機會，把業(yè)務(wù)從領(lǐng)導(dǎo)，控制和執(zhí)行三個方面進(jìn)行模塊化分析，從而有效的實現(xiàn)業(yè)務(wù)的有組織的提供服

5、務(wù)的能力。CBM 的價值是提供一個可以推廣的框架，用來創(chuàng)造順應(yīng)組織戰(zhàn)略的可以運營的指導(dǎo)方向，同時 CBM 也用來按照業(yè)務(wù)和資源的優(yōu)先級別和相互關(guān)聯(lián)的程度來構(gòu)建和順應(yīng)戰(zhàn)略的發(fā)展方向，其中包括建立一個溝通的機制來理解整個業(yè)務(wù)發(fā)展的方向。通過CBM建立了SOA 的規(guī)劃的方向，為實施 SOA 奠定基礎(chǔ)。本文所提到的業(yè)務(wù)組件在粒度上基本對應(yīng)著組件業(yè)務(wù)模型（CBM）的粒度，但是本文中的業(yè)務(wù)組件（BC）更多從技術(shù)實現(xiàn)角度考慮，或大于，或小于業(yè)務(wù)組件模型（CBM）提到的業(yè)務(wù)組件概念。服務(wù)組件框架（SCA） 服務(wù)組件框架（Service Component Architecture，SCA）由BEA、IBM、O

6、racle等中間件廠商聯(lián)合制定的一套符合SOA思想的規(guī)范。服務(wù)組件框架（SCA）提供了一套可構(gòu)建基于面向服務(wù)的應(yīng)用系統(tǒng)的編程模型，它的核心概念是服務(wù)及其相關(guān)實現(xiàn)。SCA組件組成程序集，程序集是服務(wù)級的應(yīng)用程序，它是服務(wù)的集合，這些服務(wù)被連接在一起，并進(jìn)行了正確的配置。在SCA標(biāo)準(zhǔn)下，SCA由域（Domain）、組合構(gòu)件（Composite）、構(gòu)件（Component）三個級別組成，構(gòu)件對應(yīng)著細(xì)粒度的Web服務(wù)，域?qū)?yīng)著粗粒度的Web服務(wù)。SCA程序集運行在兩個級別：第一種情況，程序集是“大規(guī)模編程”（Programming in the Large或Megaprogramming）的一組松散連

7、接的服務(wù)組件；另一種情況，程序集是“小規(guī)模編程”（Programming in the Small）內(nèi)的一組松散連接的組件。二者的區(qū)別在于， “大規(guī)模編程”對應(yīng)著應(yīng)用，“小規(guī)模編程”對應(yīng)著模塊，一般來說，服務(wù)組件對應(yīng)著“小規(guī)模編程”，即模塊的概念。 本文所提到的業(yè)務(wù)組件（BC），是比SCA組件更大范圍的概念，這幾個概念的顆粒度從大到小的排列順序如下：系統(tǒng)（每個企業(yè)只有一個系統(tǒng)）、應(yīng)用、業(yè)務(wù)組件（BC）、模塊、SCA組件（粗粒度服務(wù)）?？偩€模式（Bus）和SOA、OSGi 總線（Bus）：一般指通過分時復(fù)用的方式，將信息以一個或多個源部件傳送到一個或多個目的部件的一組傳輸線?；诳偩€模式的有很多

8、應(yīng)用，在微機的技術(shù)中，有三種總線，地址總線Address Bus，數(shù)據(jù)總線Data Bus，控制總線Control Bus。在通信架構(gòu)下，交換機也是一種總線，在SOA中，總線一般指企業(yè)服務(wù)總線（Enterprise Service Bus，ESB），企業(yè)服務(wù)總線可以連接所有協(xié)議的各種接口，但是最理想的是基于XML的Web服務(wù)標(biāo)準(zhǔn)。OSGiOpen Service Gateway Initiative，1999年OSGi 聯(lián)盟成立，旨在建立一個開放的服務(wù)規(guī)范，為通過網(wǎng)絡(luò)向設(shè)備提供服務(wù)建立開放的標(biāo)準(zhǔn)，是開放業(yè)務(wù)網(wǎng)關(guān)的發(fā)起者。OSGi是一個Java框架，該框架能裝載以Bundle為單位的資源。Bun

9、dle能提供服務(wù)或響應(yīng)處理請求，而他們之間的依賴都是被管理起來的，正如一個Bundle能從容器中獲得它所需要的管理。每個Bundle都可以有它自己的內(nèi)部類路徑，所以它可以作為獨立的服務(wù)單元。所有的這些符合OSGi規(guī)范的Bundle理論上都可以安裝在任何符合OSGi規(guī)范的容器中。OSGi具有可動態(tài)改變系統(tǒng)行為，熱插拔的插件體系結(jié)構(gòu)，高可復(fù)用性，高效性等等。在J2EE環(huán)境下，基于總線（Bus）模式的思考，可以進(jìn)一步推廣到Java Class，基于OSGi的微內(nèi)核，建立一個類總線（Java Class Bus，JCB）。 通過以上概念的分析，我們可以看到，本文提到的業(yè)務(wù)組件（BC），是指具體的一個軟

10、件實現(xiàn)，業(yè)務(wù)組件（BC）跟IBM的業(yè)務(wù)組件模型（CBM）中提到的業(yè)務(wù)組件有一定的對應(yīng)關(guān)系，但是一般來說，業(yè)務(wù)組件（BC）可能包含CBM中的多個業(yè)務(wù)組件或者一個CBM的業(yè)務(wù)組件封裝成多個業(yè)務(wù)組件（BC）。另外CBM更多的是從業(yè)務(wù)角度來考慮，是業(yè)務(wù)上的概念，業(yè)務(wù)組件（BC）則是從技術(shù)實現(xiàn)角度考慮。服務(wù)組件框架（SCA）定義的粒度和業(yè)務(wù)組件（BC）相比來說，SCA劃分的還是很細(xì)，業(yè)務(wù)組件（BC）是更粗粒度的一個軟件實現(xiàn)概念。業(yè)務(wù)組件（BC）模型 根據(jù)業(yè)務(wù)組件的作用不同，可以將業(yè)務(wù)組件分成公共業(yè)務(wù)組件和普通業(yè)務(wù)組件，公共業(yè)務(wù)組件包含統(tǒng)一用戶組件、統(tǒng)一認(rèn)證組件、門戶組件、流程組件、報表組件、BI組件、G

11、IS組件等，這些組件的共同特點是多個業(yè)務(wù)組件或者系統(tǒng)會用到這個業(yè)務(wù)組件。 組件的粒度和對外接口設(shè)計決定了組件的可復(fù)用和松耦合（Loose Coupling）特性。粒度過大，靈活性小，難以實現(xiàn)復(fù)用，粒度過小，管理成本提升，使得復(fù)用性也很難改善；接口和實現(xiàn)的分離,保證各項業(yè)務(wù)組件在提供標(biāo)準(zhǔn)化的服務(wù)接口的前提下可以替換各種可選的實現(xiàn),而不會影響系統(tǒng)其它部分的實現(xiàn)，接口設(shè)計不當(dāng)，對于組件的耦合會有很大的影響。業(yè)務(wù)組件的粒度 業(yè)務(wù)組件的粒度根據(jù)需要可以不同，既可能是獨立運行的子系統(tǒng),也可能是程序模塊。業(yè)務(wù)組件是提高應(yīng)用系統(tǒng)靈活性和復(fù)用的重要基礎(chǔ)。業(yè)務(wù)組件粒度太小，造成組件數(shù)量多，組件之間交互多，管理困難

12、，性能低下；業(yè)務(wù)組件粒度粗，功能復(fù)雜，功能之間關(guān)系緊密，升級困難（可以獨立升級往往會作為確定一個業(yè)務(wù)組件范圍的重要因素），很難實現(xiàn)重用。因此找到一個合適的業(yè)務(wù)組件粒度是很重要的事情。 根據(jù)前文所定義的業(yè)務(wù)組件定義，我們把整個企業(yè)的所有軟件稱之為系統(tǒng)，即一個企業(yè)只有一個系統(tǒng)；系統(tǒng)下面劃分成若干應(yīng)用，每個應(yīng)用完成一個相對獨立的業(yè)務(wù)功能，比如財務(wù)管理、人力資源管理等，一般來說是一個廠商獨立完成（后文還會提到，如果是基于一個業(yè)務(wù)基礎(chǔ)平臺，多個廠商可以在一個應(yīng)用中）；應(yīng)用下面劃分成若干業(yè)務(wù)組件，業(yè)務(wù)組件是相對獨立的功能，其可以進(jìn)一步劃分成若干模塊，從而形成了系統(tǒng)應(yīng)用業(yè)務(wù)組件模塊這樣四個層次的模型。根據(jù)S

13、CA的定義，模塊下面可以進(jìn)一步劃分成程序集為更小的粒度。從軟件復(fù)用角度來看，業(yè)務(wù)組件是獨立部署的最小顆粒，模塊是復(fù)用的最小顆粒。 除了業(yè)務(wù)組件需要粒度控制外，Web服務(wù)的粒度控制也是一項十分重要的設(shè)計任務(wù)。通常來說,對于將暴露在整個系統(tǒng)外部的服務(wù)推薦使用粗粒度的接口,而相對較細(xì)粒度的服務(wù)接口通常用于企業(yè)和機構(gòu)系統(tǒng)架構(gòu)的內(nèi)部。從技術(shù)上講,粗粒度的服務(wù)接口可能是一個特定服務(wù)的完整執(zhí)行,而細(xì)粒度的服務(wù)接口可能是實現(xiàn)這個粗粒度服務(wù)接口的具體的內(nèi)部操作。雖然細(xì)粒度的接口能為服務(wù)請求者提供了更加細(xì)化和更多的靈活性,但同時也意味著引入較難控制的交互模式易變性,也就是說服務(wù)的交互模式可能隨著不同的服務(wù)請求者而

14、不同。如果暴露這些易于變化的服務(wù)接口給系統(tǒng)的外部用戶,就可能造成外部服務(wù)請求者難于支持不斷變化的服務(wù)提供者所暴露的細(xì)粒度服務(wù)接口。而粗粒度服務(wù)接口保證了服務(wù)請求者將以一致的方式使用系統(tǒng)中所暴露出的服務(wù)。業(yè)務(wù)組件的松耦合設(shè)計 耦合性（Coupling）是程序結(jié)構(gòu)中各個模塊之間相互關(guān)聯(lián)的度量，它取決于各個模塊之間接口的復(fù)雜程度、調(diào)用模塊的方式以及哪些信息通過接口。耦合性由松到緊可以分成七種：非直接耦合（Nondirect Coupling）、數(shù)據(jù)耦合（Date Coupling）、標(biāo)記耦合（Stamp Coupling）、控制耦合（Control Coupling）、外部耦合（External C

15、oupling）、公共耦合（Common Coupling）、內(nèi)容耦合（CONTENT COUPLING）。非直接耦合是指兩個模塊之間沒有直接關(guān)系，這種耦合的模塊獨立性最強。數(shù)據(jù)耦合，彼此之間是通過數(shù)據(jù)參數(shù)(不是控制參數(shù)、公共數(shù)據(jù)結(jié)構(gòu)或外部變量)來交換輸入、輸出信息的，模塊之間的獨立性比較強。標(biāo)記耦合是指一組模塊通過參數(shù)表傳遞記錄信息，就是標(biāo)記耦合，這要求這些模塊都必須 清楚該記錄的結(jié)構(gòu)，并按結(jié)構(gòu)要求對此記錄進(jìn)行操作，應(yīng)盡量避免這種耦合，它使在數(shù)據(jù)結(jié)構(gòu)上的操作復(fù)雜化了。在業(yè)務(wù)組件設(shè)計模型中業(yè)務(wù)組件之間盡量實現(xiàn)非直接耦合（總線模式，推薦使用）和數(shù)據(jù)耦合（共享庫模式，控制使用），通過定義清晰的We

16、b服務(wù)進(jìn)行交互，業(yè)務(wù)組件內(nèi)部的模塊之間可以通過標(biāo)準(zhǔn)化的Web服務(wù)或者數(shù)據(jù)表來進(jìn)行共享。業(yè)務(wù)組件接口模型 業(yè)務(wù)組件作為一個可以獨立的運行的模塊，通過一系列的接口，可以獨立完成本業(yè)務(wù)組件的功能。業(yè)務(wù)組件通過接口，可以組裝到和基于標(biāo)準(zhǔn)的集成平臺上，并和其他的組件或者系統(tǒng)共同完成企業(yè)的業(yè)務(wù)?；跇?biāo)準(zhǔn)的企業(yè)集成平臺包含企業(yè)信息門戶（門戶標(biāo)準(zhǔn)）企業(yè)服務(wù)總線（Web服務(wù)標(biāo)準(zhǔn)）和數(shù)據(jù)服務(wù)總線（含數(shù)據(jù)模型），如下圖所示： 圖 2. 企業(yè)集成平臺模型 當(dāng)企業(yè)集成平臺建立之后，基于標(biāo)準(zhǔn)，業(yè)務(wù)組件就可以簡單的以“插拔”的方式組合到整體應(yīng)用中。業(yè)務(wù)組件接口通信方式松耦合實現(xiàn)方式 Web服務(wù)根據(jù)Web服務(wù)內(nèi)部數(shù)據(jù)的流向可

17、以分成兩類，一是獲取服務(wù)，即別的業(yè)務(wù)組件或系統(tǒng)調(diào)用Web服務(wù)，對外提供數(shù)據(jù)；二是寫入服務(wù)，即其他業(yè)務(wù)組件或系統(tǒng)調(diào)用本業(yè)務(wù)組件或系統(tǒng)Web服務(wù)寫入數(shù)據(jù)。前者比較簡單，只要提供服務(wù)即可，但是對于后者，在實現(xiàn)過程中將會有兩種實現(xiàn)方式：一是主動到ESB調(diào)用Web服務(wù)，讀取數(shù)據(jù)，然后直接寫入系統(tǒng)，二是提供Web服務(wù)到ESB，等待業(yè)務(wù)組件或系統(tǒng)調(diào)用寫入。采用第一種方式，不需要對外提供Web服務(wù)，直接調(diào)用ESB的Web服務(wù)即可，但是服務(wù)的調(diào)用以及寫入是通過代碼固化到系統(tǒng)中的；后者對外提供服務(wù)，不管調(diào)用系統(tǒng)是誰，只要調(diào)用既可寫入數(shù)據(jù)，不會受到外部系統(tǒng)的變化的影響。如果是采用直接到ESB調(diào)用服務(wù)，然后用代碼寫入

18、的方式，一旦業(yè)務(wù)流程發(fā)生變化，比如改為別的系統(tǒng)或者模塊直接寫入，這種方式就無法適應(yīng)，需要重新增加一個寫入的Web服務(wù)，因此比較好的解決方式是提供對外的一個寫入Web服務(wù)，寫入Web服務(wù)是獨立的，滿足別的系統(tǒng)主動寫入的要求，如果是自己主動寫入，則采用先到ESB上請求獲取數(shù)據(jù)（本服務(wù)僅僅是通知ESB，要獲取數(shù)據(jù)）然后由ESB實現(xiàn)對本次統(tǒng)的寫入Web服務(wù)，這樣，不管外部的系統(tǒng)如何變幻，接口是不變的，如下圖所示： 圖 3. 服務(wù)調(diào)用順序 除非是寫入服務(wù)提供者業(yè)務(wù)需求非常明確，只有本系統(tǒng)調(diào)用才會寫入，一般建議按照以上獨立的寫入服務(wù)方式來實現(xiàn)。采用獨立的寫入服務(wù)能更好的適應(yīng)未來被動寫入、或者寫入操作需要經(jīng)

19、過評審或者確認(rèn)之后的操作。 比如客戶信息數(shù)據(jù)，如果是在CRM系統(tǒng)中創(chuàng)建，財務(wù)系統(tǒng)需要客戶數(shù)據(jù)，有三種調(diào)用方式，一是財務(wù)系統(tǒng)直接到ESB調(diào)用CRM的客戶信息查詢Web服務(wù)，然后寫入系統(tǒng)。二是事件機制，CRM系統(tǒng)中的數(shù)據(jù)變化時，對外提供的客戶信息變更服務(wù)，服務(wù)調(diào)用中傳遞的消息就是變更的信息，調(diào)用財務(wù)系統(tǒng)的寫入服務(wù)。如果還有其它的系統(tǒng)需要客戶信息，可以在ESB中定義出發(fā)布/訂閱關(guān)系。三是財務(wù)系統(tǒng)先請求ESB調(diào)用CRM的查詢服務(wù)，然后由ESB調(diào)用財務(wù)系統(tǒng)的客戶信息寫入服務(wù)，寫入數(shù)據(jù)。如果未來業(yè)務(wù)流程發(fā)生變化，改由CRM直接將客戶信息寫入財務(wù)系統(tǒng)，則直接調(diào)用財務(wù)的寫入服務(wù)即可，需要做的僅僅是配置一下ES

20、B即可，現(xiàn)有的程序不需要改變。第一種方式下，如果改成CRM寫入，財務(wù)系統(tǒng)需要重新編碼，第二種方式如果別的系統(tǒng)來主動查詢客戶數(shù)據(jù)，需要另外增加一個客戶信息的查詢服務(wù)，第三種情況，無論是如何改變化，需要的僅僅是增加一個請求調(diào)用即可，對所有的系統(tǒng)影響最小，因此是受外界需求發(fā)生變化后影響最小的方式，更好的解決了松耦合的問題。業(yè)務(wù)組件接口事務(wù)處理無狀態(tài)的會話設(shè)計 為了保證業(yè)務(wù)組件的獨立和松耦合，SOA中的具體服務(wù)應(yīng)該都是獨立的、自包含的請求,在實現(xiàn)這些服務(wù)的時候不需要前一個請求的狀態(tài),也就是說服務(wù)不應(yīng)該依賴于其他服務(wù)的上下文和狀態(tài),即 SOA中的服務(wù)應(yīng)該是無狀態(tài)的服務(wù)。不同的業(yè)務(wù)組件之間是采用Web服務(wù)

21、的方式進(jìn)行交互，對于事務(wù)的控制很困難，應(yīng)盡量將事務(wù)控制在一個業(yè)務(wù)組件中（關(guān)于事務(wù)的控制，詳見下文關(guān)于組件內(nèi)部松耦合設(shè)計的方案），如果是在不同的業(yè)務(wù)組件，需要事務(wù)控制，則考慮采用流程編排的方式實現(xiàn)，基于BPEL實現(xiàn)事務(wù)控制。J2EE架構(gòu)下業(yè)務(wù)組件（BC）實現(xiàn)業(yè)務(wù)組件松耦合設(shè)計OSGI 業(yè)務(wù)組件以Web服務(wù)的方式提供接口，通過企業(yè)服務(wù)總線連接，業(yè)務(wù)組件內(nèi)部為了實現(xiàn)高可復(fù)用性和高效性，采用基于OSGi標(biāo)準(zhǔn)進(jìn)行構(gòu)建模塊，實現(xiàn)內(nèi)部模塊之間的松耦合，即在業(yè)務(wù)組件內(nèi)部基于OSGi標(biāo)準(zhǔn)進(jìn)行模塊化設(shè)計，將業(yè)務(wù)組件進(jìn)一步分解為松耦合的模塊（Bundle），使得業(yè)務(wù)組件本身更加靈活。 基于OSGi標(biāo)準(zhǔn)，業(yè)務(wù)組件內(nèi)部

22、的模塊通過一個具有動態(tài)加載類功能的微內(nèi)核連接，統(tǒng)一管理各個模塊，為了便于管理，將不同模塊之間的類接口采用服務(wù)注冊的方式進(jìn)行管理，具有類動態(tài)加載功能的微內(nèi)核和類接口管理組成類總線（JCB）的基本功能，為了更好的實現(xiàn)重用，有些模塊是共用的，比如數(shù)據(jù)訪問模塊、日志管理模塊等。 在一個應(yīng)用中，不同業(yè)務(wù)組件公用的功能，作為應(yīng)用內(nèi)部的公共組件，一個應(yīng)用中部署一個公共組件即可，各個業(yè)務(wù)組件共用。在一個業(yè)務(wù)組件中，不同模塊公用的功能，作為公共模塊，相當(dāng)于工具類，公共模塊需要在每個業(yè)務(wù)組件中部署。公共服務(wù)平臺作為企業(yè)級的公共服務(wù)對外提供企業(yè)級的Web服務(wù)，比如主數(shù)據(jù)管理等。業(yè)務(wù)組件構(gòu)成如下圖所示： 圖 4. 業(yè)

23、務(wù)組件模型（公共類公共組件公共服務(wù)平臺) 注： 業(yè)務(wù)組件中的公共組件和公共服務(wù)平臺的差異是公共組件是應(yīng)用內(nèi)部的，提供應(yīng)用級別的服務(wù)；公共服務(wù)平臺則是面向企業(yè)整個系統(tǒng)的，是提供系統(tǒng)級的服務(wù)，兩者有時候可以互相替換，主要是看其處于那個級別?；贗BM產(chǎn)品體系的實現(xiàn) 本文提到的集成平臺，基于IBM的產(chǎn)品共體系在實際搭建的時候需要包含應(yīng)用服務(wù)器（產(chǎn)品：WAS）、流程整合服務(wù)器（產(chǎn)品：WPS，實現(xiàn)服務(wù)總線和流程編排）等，關(guān)于集成平臺的詳細(xì)描述，詳見SOA和DW一文中“基于IBM產(chǎn)品體系的實現(xiàn)”的描述。業(yè)務(wù)組件（BC）在WAS中的部署 首先來看一下在J2EE架構(gòu)模式下文件格式（以WAS為例）。在J2EE架

24、構(gòu)下，文件格式有三種，分別是EAR、WAR、JAR，另外還有一個特殊的JAR即基于OSGi標(biāo)準(zhǔn)的Bundle，共四類文件： EAR文件（file Enterprise Achieve）除了包含JAR、WAR以外，還包括EJB組件、部署文件application-client.xml、web.xml、application.xml等全部企業(yè)應(yīng)用程序。 WAR文件（file web Achieve）包含Servlet、JSP頁面、JSP標(biāo)記庫、JAR庫文件、HTML/XML文檔和其他公用資源文件，如圖片、音頻文件等全部Web應(yīng)用程序。在一個EAR文件中可以有多個WAR。在WAS環(huán)境下，如果設(shè)置在E

25、AR中用一個類加載器，這樣不同的WAR之間可以直接調(diào)用Java Class，WAR之間是緊耦合的，不建議采用。 JAR文件（Java Achieve）按Java格式壓縮的類包，包含內(nèi)容 class、properties文件，是文件封裝的最小單元。但是普通的JAR文件，只是一個文件的集合，沒有具體的意義。?Bundle，基于OSGi標(biāo)準(zhǔn)的一種特殊的JAR文件，每個Bundle也包含一個 META-INF/MANIFEST.MF文件，這個文件會宣布導(dǎo)出哪些包(Package)以及導(dǎo)入哪些包。只有那些導(dǎo)出包中的類才能被其他Bundle 所使用，而其他包都只面向包的內(nèi)部成員，包里的類也只能在自身Bun

26、dle 中使用。一個簡化的處理思路是直接采用包(Package)，但是無法實現(xiàn)類的動態(tài)加載和對接口進(jìn)行管理，不具有松耦合特性。WAS從版本 6.1 開始支持 OSGi從以上文件結(jié)構(gòu)可以看到，JAR之間可以進(jìn)行類的調(diào)用，很容易實現(xiàn)不同JAR之間的事務(wù)處理，且具有更高的性能，結(jié)合OSGi，通過“類總線”進(jìn)行管理所有JAR（Bundle）對外開放的接口，從而以“總線”（Bus）的方式管理不同JAR之間的類調(diào)用。不同的WAR之間各種資源不共享，為了實現(xiàn)重用，需要設(shè)置一些公共模塊，即公共Bundle；不同的WAR之間交互，需要以Web服務(wù)的方式進(jìn)行連接，需要建立企業(yè)服務(wù)總線（ESB）管理所有的Web服務(wù)

27、，實現(xiàn)WAR之間調(diào)用。在一個EAR中，可以設(shè)置不同WAR之間共享Session，從而方便的實現(xiàn)單點登錄以及其它的公共信息，這些信息將在這個EAR環(huán)境中共享。 根據(jù)前文所述業(yè)務(wù)組件（BC）的定義，業(yè)務(wù)組件適合于在WAR文件層面進(jìn)行劃分，即一個WAR作為一個業(yè)務(wù)組件，一個或者幾個WAR組成一個應(yīng)用（EAR），多個應(yīng)用構(gòu)成企業(yè)的系統(tǒng)；業(yè)務(wù)組件內(nèi)部進(jìn)一步劃分為多個模塊（Bundle），每個模塊相對獨立，可以獨立維護(hù)，獨立升級和安裝，以插件的方式通過類總線進(jìn)行關(guān)聯(lián)。為了實現(xiàn)重用，在EAR層面，將企業(yè)級的業(yè)務(wù)組件單獨部署，比如主數(shù)據(jù)、統(tǒng)一認(rèn)證、工作流等，建立公共服務(wù)平臺；在WAR層面，各廠商的公共的業(yè)務(wù)組

28、件單獨封裝在公共組件（WAR）中，如系統(tǒng)管理、系統(tǒng)參數(shù)管理等。在模塊級別采用公共模塊的方式，在各個WAR中以工具模塊（Bundle）方式提供，如數(shù)據(jù)庫訪問、日志（Log4j）等。公共組件（WAR）、內(nèi)部服務(wù)總線（ESB）和類總線（JCB）、工具模塊（Bundle）組成應(yīng)用系統(tǒng)的業(yè)務(wù)基礎(chǔ)平臺（Business Platform）（如浪潮的Loushang平臺）。 在系統(tǒng)部署的時候，一臺服務(wù)器上安裝一個Websphere實例，一個實例根據(jù)主機的性能可以安裝多個節(jié)點（Node），每個節(jié)點（Node）可以安裝多個虛擬機（JVM），每個虛擬機可以安裝多個EAR應(yīng)用，每個EAR有多個WAR，不同WAR之間

29、文件不會沖突，WAR內(nèi)部采用OSGI標(biāo)準(zhǔn)分成多個模塊（Bundle）。不同公司的系統(tǒng)是不同的EAR，同一個公司可以有多個EAR。如下圖所示： 圖 5. WAS部署模型（系統(tǒng)應(yīng)用業(yè)務(wù)組件模塊） EAR之間數(shù)據(jù)交換采用通過企業(yè)級服務(wù)總線（ESB）的Web服務(wù)，大數(shù)據(jù)量數(shù)據(jù)共享在數(shù)據(jù)總線上通過企業(yè)級的共享數(shù)據(jù)庫進(jìn)行共享，通過數(shù)據(jù)總線共享的數(shù)據(jù)不是實時的，是有一定的延誤或者準(zhǔn)實時的。共享庫是企業(yè)的資產(chǎn)，不隸屬于任何一個廠商。 WAR之間數(shù)據(jù)交換采用通過企業(yè)或者內(nèi)部的服務(wù)總線（ESB）的Web服務(wù)，不同的WAR共用一個數(shù)據(jù)庫，但是數(shù)據(jù)表根據(jù)WAR的職責(zé)進(jìn)行劃分，每個WAR可以只讀所有的共享的數(shù)據(jù)表，但是

30、只能寫自己控制的表，對其它WAR控制的表、表結(jié)構(gòu)很復(fù)雜或者易變的表的讀作操，都應(yīng)通過Web服務(wù)進(jìn)行，以實現(xiàn)WAR之間的松耦合。一個EAR中的共享數(shù)據(jù)庫（對企業(yè)來說是私有數(shù)據(jù)層）在各個WAR之間結(jié)合更加緊密，一般采用直接訪問的方式，不在私有數(shù)據(jù)層存放共享庫數(shù)據(jù)，私有數(shù)據(jù)僅僅是一些控制類或者跟業(yè)務(wù)無關(guān)，不需要共享的數(shù)據(jù)。企業(yè)級共享庫一般從性能、不同廠家便于控制等角度考慮，數(shù)據(jù)同步是準(zhǔn)實時的，數(shù)據(jù)在各個EAR的私有數(shù)據(jù)層一般會有一個拷貝，讓各個EAR之間相對更加獨立。以上僅僅是一般原則，如果是一個廠商，兩個EAR之間也可以像一個EAR共享一個數(shù)據(jù)庫。EAR和共享庫之間的關(guān)系如下圖EAR和共享庫的關(guān)系

31、所示： 圖 6. EAR和共享庫的關(guān)系 Bundule之間數(shù)據(jù)交換可以類似WAR的Web服務(wù)調(diào)用，也可以直接通過類總線，調(diào)用Bundule對外發(fā)布的接口，特別是需要具有事務(wù)處理能力和更高的性能要求的情況。一個WAR內(nèi)原則上不再劃分?jǐn)?shù)據(jù)表的控制，由WAR自己內(nèi)部進(jìn)行管理。 一般來說，WAR是相對比較穩(wěn)定的，不需要完全進(jìn)行替換升級，日常的變更是通過Bundle來實現(xiàn)的，由于Bundle在應(yīng)用方面是基于插件的方式進(jìn)行開發(fā)的，數(shù)據(jù)方面由于業(yè)務(wù)組件本身是基于標(biāo)準(zhǔn)信息服務(wù)或者作為企業(yè)資源的開放的數(shù)據(jù)表、視圖（Web服務(wù)和數(shù)據(jù)模型，作為企業(yè)的兩個資產(chǎn)），因此可以實現(xiàn)熱插拔，保證了系統(tǒng)可以連續(xù)運行，而不至于因為系統(tǒng)升級而影響到業(yè)務(wù)的運行或者最小程度的營銷業(yè)務(wù)的運行。 在實際部署的情況下，有可能會出現(xiàn)整個企業(yè)只有一個EAR（功能簡單，最極端情況），或者一個廠商把應(yīng)用分別部署在不同的EAR，需要根據(jù)企業(yè)規(guī)模，主機部署等，從性能、易于管理等角度考慮。由于WAR之間是松耦合的，基于企業(yè)服務(wù)總線（ESB）和信息服務(wù)總線（ISB），可以實現(xiàn)靈活的組裝，因此一個或者多個