SCA（Service Component Architecture）即服務(wù)組件架構(gòu)（其他稱法有服務(wù)構(gòu)件架構(gòu)、面向服務(wù)的體系架構(gòu)等），它提供了一個(gè)編程模型來(lái)構(gòu)建和開(kāi)發(fā)基于 SOA（Service Oriented Architecture）的應(yīng)用系統(tǒng)。SCA 于 2005 年 11 月 30 日，由 IBM、BEA、Oracle、SAP、Iona、Siebel 和 Sybase 等公司正式推出，版本號(hào)為 0.9。2007 年，IBM、BEA 等 SCA 規(guī)范參與廠商共同成立 OSOA（Open Service Oriented Architecture）組織來(lái)制定和推動(dòng) SCA 以及 SDO（Service Data Objects）規(guī)范，同年 3 月，OSOA 組織正式發(fā)布 SCA 系列規(guī)范 1.0 版本。
開(kāi)發(fā)一個(gè) SOA 應(yīng)用系統(tǒng)，編程模型和數(shù)據(jù)模型是其兩個(gè)重要方面，SCA 用于提供編程模型，SDO 則提供了數(shù)據(jù)模型，SDO 致力于為應(yīng)用系統(tǒng)中處理數(shù)據(jù)提供統(tǒng)一的方式，SCA 和 SDO 并不需要一起使用，本文也只討論 SCA。SCA 并不僅僅只有一個(gè)規(guī)范，它目前共包含了 16 個(gè)規(guī)范。這 16 個(gè)規(guī)范可以歸于三類：1. 核心規(guī)范，由裝配模型規(guī)范（Assembly Model）和策略框架規(guī)范（Policy Framework）組成，用于定義 SCA 中的組件裝配模型和策略框架；2. 服務(wù)組件實(shí)現(xiàn)技術(shù)規(guī)范，用于定義 SCA 的組件實(shí)現(xiàn)技術(shù)，SCA 支持多種語(yǔ)言和技術(shù)作為 SCA 的組件實(shí)現(xiàn)，并且 SCA 還提供了可擴(kuò)展框架來(lái)支持開(kāi)發(fā)人員添加新的組件實(shí)現(xiàn)技術(shù)，目前 SCA 規(guī)范已經(jīng)定義了 Java，C++ 等實(shí)現(xiàn)技術(shù)；3. 綁定（Binding）技術(shù)支持規(guī)范，在一個(gè)大型 SOA 應(yīng)用中，一個(gè)常見(jiàn)的問(wèn)題便是不同的服務(wù)間需要通過(guò)不同的訪問(wèn)協(xié)議來(lái)進(jìn)行互操作，綁定技術(shù)規(guī)范便是用于定義 SCA 服務(wù)或引用所支持的訪問(wèn)協(xié)議，SCA 支持多種綁定技術(shù)，其可擴(kuò)展框架同時(shí)支持開(kāi)發(fā)人員添加其他綁定技術(shù)，目前 SCA 定義了 JMS、Web Service 等綁定技術(shù)。
下面給出了 SCA 目前所包含的 16 個(gè)規(guī)范，所有規(guī)范的最新版本號(hào)都是 1.0：
SCA Assembly Model
SCA Policy Framework
SCA Transaction Policy
SCA Assembly Extensions for Event Processing
SCA Java Common Annotations and APIs
SCA Java Component Implementation
SCA Spring Component Implementation
SCA BPEL Client and Implementation
SCA C++ Client and Implementation
SCA COBOL Client and Implementation
SCA C Client and Implementation
SCA Java EE Integration Specification
SCA Web Services Binding
SCA JMS Binding
SCA EJB Session Bean Binding
SCA JCA Binding
SCA 在推出之初，并沒(méi)有這么多規(guī)范，一些規(guī)范是隨著 SCA 的發(fā)展而誕生的，在今后的發(fā)展中，OSOA 組織亦可能推出更多的規(guī)范，下面介紹下 SCA 的演化及演化過(guò)程中各版本的主要區(qū)別。
IBM 等公司雖然于 2005 年 11 月才第一次正式發(fā)布 SCA 規(guī)范，但實(shí)際上，IBM WebSphere Process Server 6.0 版本中便已經(jīng)實(shí)現(xiàn)了一個(gè)最初的 SCA，同時(shí) IBM WebSphere Integration Developer 還提供了開(kāi)發(fā)工具用于開(kāi)發(fā) SCA 應(yīng)用。目前，SCA 系列規(guī)范已經(jīng)發(fā)展到了 1.0 版本，在運(yùn)行容器方面，IBM、Oracle 等主流廠商亦在開(kāi)發(fā)支持 SCA 的運(yùn)行容器，IBM WebSphere Process Server 7.0 通過(guò)利用 Apache Tuscany 項(xiàng)目的核心代碼，已經(jīng)可以支持 SCA 1.0 部分規(guī)范。
SCA 發(fā)展至今，已經(jīng)經(jīng)歷了多個(gè)版本，我們可以根據(jù)時(shí)間順序，把 SCA 的發(fā)展分為三個(gè)階段：1. 起源階段，即 IBM 首次在 WPS 6.0 中所支持的 SCA；2. 發(fā)展階段，即 IBM 聯(lián)合其他廠商在 05 年首次公開(kāi)推出的 SCA 0.9 版本；3. 成熟階段，即 OSOA 于 07 年推出的 SCA 1.0 版本。下面，我們主要介紹這三個(gè)階段中 SCA 核心規(guī)范的發(fā)展和帶來(lái)的區(qū)別。
SCA 由 IBM 于 WebSphere Process Server 6.0 版本中首次提出，WPS 為部署和運(yùn)行 SCA 應(yīng)用的容器，IBM WebSphere Integration Developer 則提供了基于 Eclipse 3.0 的開(kāi)發(fā)工具來(lái)開(kāi)發(fā)和部署 SCA 應(yīng)用。
IBM WPS V6.0 中的 SCA 已經(jīng)給出了完整的 SCA 裝配模型，并提供了一個(gè)實(shí)現(xiàn) QoS（Quality of Service）的機(jī)制。下面，我們就將 WPS 6.0 中的 SCA 的裝配模型和 QoS 機(jī)制和 1.0 版本做個(gè)比較。由于本文主要介紹 SCA 各版本演化過(guò)程中的區(qū)別，而不會(huì)詳細(xì)介紹各版本的具體內(nèi)容，讀者可通過(guò)參考文獻(xiàn)章節(jié)，獲取各版本的詳細(xì)資料。
裝配模型
WPS 6.0 中的 SCA 中的裝配模型和 SCA 裝配模型 1.0 相比，主要有兩點(diǎn)區(qū)別：1. 修改了組件模型中部分概念名稱；2. 缺乏如復(fù)合組件（Composite）及嵌套裝配（Recursive Assemble）等概念。
WPS 6.0 中的 SCA 裝配模型和 SCA 裝配模型相比，基本內(nèi)容相似，但部分概念名稱已經(jīng)發(fā)生了變化，圖 1 給出了 WPS 6.0 中 SCA 組件模型示意圖。
圖中的箭頭 1 所指的導(dǎo)入（Import）就是目前 SCA 中的引用（Reference），箭頭 2 所指的導(dǎo)出（Export）就是目前的服務(wù)（Service），箭頭 3 所指的獨(dú)立引用（Standalone reference）在 0.9 以及后續(xù)版本中已經(jīng)消失，非 SCA 應(yīng)用的客戶端可以通過(guò)當(dāng)前模塊的上下文對(duì)象（context）來(lái)獲取指定名稱的服務(wù)實(shí)例。
上面的這 3 個(gè)變化都發(fā)生在 SCA 模塊（Module）層次，實(shí)際上，在組件（Component）層次上，WPS 6.0 中的 SCA 依然包含服務(wù)和引用兩個(gè)概念。那么為什么在最新版本中要修改這幾個(gè)概念名稱，原因有兩點(diǎn)：1. 可以簡(jiǎn)化 SCA 中的概念，并能夠?qū)?SCA 的組件模型有一個(gè)一致的描述；2. 從本質(zhì)上看，模塊層次上的導(dǎo)出和導(dǎo)入相比組件層次上的服務(wù)和引用，實(shí)際上是同一個(gè)東西，只不過(guò)可見(jiàn)性不同。
自 SCA 0.95 起，SCA 新增了復(fù)合組件這個(gè)概念來(lái)代替模塊這個(gè)概念，并且復(fù)合組件可以作為組件的實(shí)現(xiàn)，從而形成嵌套組件裝配，嵌套組件裝配模型更靈活強(qiáng)大，更容易支持組件裝配開(kāi)發(fā)。
在部署和打包方面，WPS V6.0 中的 SCA 并沒(méi)有對(duì)這方面做詳細(xì)定義，而 SCA 自 0.9 起，增加了對(duì)打包和部署作了相關(guān)定義。
另外，WPS V6.0 中的 SCA 中的 Java 實(shí)現(xiàn)并不支持用 Annotation 來(lái)描述組件信息。
在可擴(kuò)展性支持方面，WPS V6.0 中的 SCA 不支持任何接口、實(shí)現(xiàn)和綁定的擴(kuò)展。
QoS 的機(jī)制
在 WPS V6.0 中，開(kāi)發(fā)人員可以通過(guò)限定符（qualifier）來(lái)對(duì)引用、接口和實(shí)現(xiàn)三個(gè)地方來(lái)進(jìn)行聲明式的 QoS 應(yīng)用，該 QoS 聲明機(jī)制可以支持事務(wù)、安全性和可靠的異步調(diào)用。而 SCA 最新版本中已經(jīng)沒(méi)有了限定符這個(gè)概念，其 QoS 機(jī)制由策略框架規(guī)范定義，主要由 Intent 和 Policy Set 兩部分組成，并同時(shí)支持 Annotation 和 XML 聲明式定義。
通過(guò)以上的分析介紹，可以發(fā)現(xiàn)起源階段的 SCA 和最新的 SCA 1.0 相比，變化較多，下面我再來(lái)了解下 SCA 的發(fā)展階段。
在 SCA 0.9 版本發(fā)布之前，SCA 只是 IBM 內(nèi)部的一個(gè)組件編程規(guī)范，而自 0.9 起，IBM、Oracle 等主流廠商開(kāi)始走到一起共同合作并推動(dòng) SCA 成為 SOA 的編程規(guī)范。0.9 版于 2005 年 11 月正式發(fā)布，它是在 WPS V6.0 的基礎(chǔ)上發(fā)展的，主要有以下 3 個(gè)方面的發(fā)展：1. 修改了部分概念名稱；2. 提出了一個(gè)可擴(kuò)展模型；3. 提出了新的策略框架并給出了關(guān)于 SCA 應(yīng)用打包和部署方面的定義。下面作分別介紹。
概念名稱的修改
SCA 0.9 同 WPS V6.0 中的 SCA 相比，組件模型變化不大。在概念上，主要是取消了獨(dú)立引用這個(gè)概念，非 SCA 客戶端通過(guò)獲取模塊的上下文對(duì)象來(lái)獲取服務(wù)實(shí)例，導(dǎo)入變成了外部服務(wù)（External Service），模塊內(nèi)部的組件一律通過(guò)外部服務(wù)來(lái)調(diào)用外部 SCA 或非 SCA 服務(wù)，另外導(dǎo)出變成了服務(wù)入口（Entry Point），圖 2 為 SCA 0.9 的裝配模型示意圖。
同 SCA 1.0 相比，上面的概念名稱又發(fā)生了變化，服務(wù)入口變成了服務(wù)，外部服務(wù)改為引用。
可擴(kuò)展模型的提出
可擴(kuò)展模型是 SCA 0.9 同之前版本的最大區(qū)別之一，在之前的版本中，開(kāi)發(fā)人員只能使用 WPS 所支持的實(shí)現(xiàn)、接口以及綁定，但在 0.9 版本，開(kāi)發(fā)人員可以通過(guò)遵循可擴(kuò)展模型，開(kāi)發(fā)自己所想要的接口、實(shí)現(xiàn)和綁定技術(shù)?？蓴U(kuò)展模型的出現(xiàn)，使得 SCA 變得更加靈活，畢竟目前有多種實(shí)現(xiàn)、接口以及綁定技術(shù)，并且今后還會(huì)有更多的技術(shù)出現(xiàn)。SCA 作為一個(gè)側(cè)重于將傳統(tǒng)應(yīng)用封裝為服務(wù)的一個(gè)組件模型，有必要通過(guò)可擴(kuò)展的方式，支持開(kāi)發(fā)人員來(lái)增加其所需要的各種實(shí)現(xiàn)、接口以及綁定。
策略框架和打包與部署的提出
WPS V6.0 中的 SCA 通過(guò)限定符來(lái)支持 QoS，但其并沒(méi)有提出一個(gè)完整的可擴(kuò)展的策略框架，而 SCA0.9 首次在附錄中提出了一個(gè)可擴(kuò)展的聲明式的策略框架。
SCA 0.9 還在附錄中給出了 SCA 應(yīng)用的打包和部署，并因此增加了子系統(tǒng)（Subsystem）這個(gè)概念，因?yàn)樵趯?shí)際應(yīng)用，同一個(gè)業(yè)務(wù)子系統(tǒng)中必然會(huì)由多個(gè)模塊共同組成，那么子系統(tǒng)則是用于將這些模塊包含在一起，一個(gè)子系統(tǒng)可以包含多個(gè)模塊，并且也可以提供服務(wù)入口供其他客戶端調(diào)用，同時(shí)也可以通過(guò)外部服務(wù)來(lái)調(diào)用外部 SCA 和非 SCA 服務(wù)。子系統(tǒng)的提出使得 SCA 組件模型可以在粗粒度上支持組件的裝配。在打包和部署方面，SCA 既允許打包和部署 SCA 模塊，亦可以打包和部署 SCA 子系統(tǒng)。
SCA 0.9 雖然是第一個(gè)正式公開(kāi)發(fā)布的版本，但是它實(shí)際上是一個(gè)過(guò)渡版本，相比 WPS V6.0 中的 SCA，雖然有些區(qū)別，但差別并不明顯，策略框架雖然有很大的差別，但是它只是提出了一個(gè)大概的框架。在 0.9 版本發(fā)布后不久，OSOA 組織相繼發(fā)布了 0.95、0.96 等版本，并于 07 年發(fā)布了 SCA 系列規(guī)范的 1.0 版本。下面我們就來(lái)了解下 SCA 在成熟階段中的變化。
作為一個(gè)成熟的版本，SCA 1.0 更為完善，同 SCA 0.9 相比，主要有三點(diǎn)變化：1. 重新整理了部分概念名稱，使得整個(gè)裝配模型中的概念表述更加一致；2. 提出了新的嵌套裝配模型；3. 提出了完善的策略框架。圖 3 為 SCA 1.0 組件裝配模型示意圖。下面將分別介紹這三點(diǎn)。
概念整理
SCA 1.0 重新修改了模塊層次上的服務(wù)和引用的名稱，改為使用組件層次中使用的服務(wù)和引用，使得組件模型概念的表述更為一致。另外它拋棄了模塊這個(gè)概念，而使用復(fù)合組件這個(gè)當(dāng)前更廣為使用的名稱，同時(shí)在打包和部署方面，拋棄了子系統(tǒng)這個(gè)概念，并由域（domain）這個(gè)概念代替，另外還增加了貢獻(xiàn)（contribution）這個(gè)概念，并由 XML 描述文件來(lái)描述這些一起打包的構(gòu)件間的依賴關(guān)系以及所需要的其他構(gòu)件，如 Java 類等。
嵌套組件裝配模型的提出
早期版本的 SCA 只能支持模塊包含組件，而不能支持組件再嵌套包含模塊，如果需要將另一模塊中的服務(wù)作為本模塊的服務(wù)公開(kāi)，需要通過(guò)調(diào)用目標(biāo)模塊的服務(wù)入口，才能使用其他模塊的服務(wù)，由于不能支持嵌套裝配，組件很難使用已有的模塊中提供的功能，導(dǎo)致模塊的可復(fù)用性降低，另外由于組件的粒度太細(xì)，不支持組件嵌套，容易導(dǎo)致一個(gè)模塊包含大量組件的現(xiàn)象，這將會(huì)增加程序維護(hù)的復(fù)雜度。
嵌套組件裝配模型去掉了模塊這個(gè)概念，轉(zhuǎn)而由復(fù)合組件代替。復(fù)合組件由多個(gè)組件裝配而成，各組件的實(shí)現(xiàn)可以是另外的復(fù)合組件，從而實(shí)現(xiàn)了組件的遞歸嵌套，這樣可以很方便的重用已有的復(fù)合組件。清單 1 是 OSOA 網(wǎng)站給出的示例復(fù)合組件的描述文件，可以發(fā)現(xiàn) SCA 通過(guò) implementation.composite 來(lái)將復(fù)合組件作為組件的實(shí)現(xiàn)。
<compositexmlns="http://www.osoa.org/xmlns/sca/1.0" xmlns:bb="http://bigbank.com" targetNamespace="http://bigbank.com" name="bigbank.AccountManagement"> <component name="bigbank.Account"> <implementation.composite name="bb:bigbank.Account" /> <property name="currency">EURO</property> <reference name="stockQuoteService"> http://www.eurosq.com/SQService </reference> </component> </composite> |
策略框架的完善
SCA 1.0 給出了一個(gè)完善的策略框架，該框架通過(guò)聲明式的設(shè)定，可以使得同一個(gè) SCA 組件能夠通過(guò)配置實(shí)現(xiàn)不同的 QoS 的需求。該框架有兩個(gè)重要的概念：1.Intent，intent 是一個(gè)抽象的 QoS 需求，比如消息傳輸中需要關(guān)注的保密性（confidentiality）和可靠性（reliability）等；2. Policy Set，系統(tǒng)在 SCA 應(yīng)用部署時(shí)期，將 intent 通過(guò) policy set 映射到具體的 policy，從而為 SCA 組件應(yīng)用具體的 policy。由于 SCA 的策略框架并不是本文的重點(diǎn)，讀者可以通過(guò)參考文獻(xiàn)中給出的鏈接，獲取更多有關(guān)策略框架的信息。
通過(guò)上面的介紹，可以看出 SCA 1.0 更加成熟和完善，目前各大廠商也正基于 SCA 1.0 來(lái)開(kāi)發(fā)運(yùn)行容器。
前面的三個(gè)小節(jié)介紹了 SCA 在三個(gè)階段中的演化和區(qū)別，下面通過(guò)表格的形式，對(duì)演化中產(chǎn)生的三個(gè)重要版本做一個(gè)對(duì)比總結(jié)：
| SCA WPS V6.0 | SCA 0.9 | SCA 1.0 | |
|---|---|---|---|
| 組件層次 | 不支持模塊作為組件的實(shí)現(xiàn) | 不支持模塊作為組件的實(shí)現(xiàn) | 支持 Composite 作為組件的實(shí)現(xiàn) |
| 模塊層次 | Import | External Service | Reference |
| Export | Entry Point | Service | |
| Standalone Reference | 無(wú)此概念，通過(guò) context 調(diào)用服務(wù) | 無(wú)此概念，通過(guò) context 調(diào)用服務(wù) | |
| Module | Module | Composite | |
| 無(wú)嵌套裝配模型 | 無(wú)嵌套裝配模型 | 支持嵌套裝配 | |
| Module 不支持 property 配置 | Module 不支持 property 配置 | Composite 支持 property 配置 | |
| 打包和部署層次 | N/A | subsystem | Domain |
| N/A | Module Fragment | Composite include | |
| 按照 Module 層次打包部署 | 支持 Module 和 subsystem 的打包和部署 | 支持 Composite 和 Contribution 部署到 Domain 中 | |
| QoS | 通過(guò)限定符支持 QoS | 初略定義了 QoS 框架 | 詳細(xì)的 QoS 框架（由策略框架規(guī)范定義） |
| 其他 | 無(wú)可擴(kuò)展模型，不支持?jǐn)U展接口、實(shí)現(xiàn)和綁定 | 有擴(kuò)展模型，支持?jǐn)U展接口、實(shí)現(xiàn)和綁定 | 有擴(kuò)展模型，支持?jǐn)U展接口、實(shí)現(xiàn)和綁定 |
| 不支持 Java Annotation | 支持 Java Annotation | 支持 Java Annotation |
本節(jié)將 SCA 的演化分為三個(gè)階段，并分別介紹了這三個(gè)階段中 SCA 的發(fā)展和區(qū)別，下面幾個(gè)小節(jié)，我們將 SCA 與另一個(gè)當(dāng)前的熱點(diǎn)技術(shù) OSGi 作相關(guān)比較。
OSGi 聯(lián)盟成立于 1999 年 3 月，致力于制定管理本地網(wǎng)絡(luò)設(shè)備服務(wù)的規(guī)范。OSGi 聯(lián)盟是為家用設(shè)備、汽車(chē)、手機(jī)、桌面、小型辦公環(huán)境以及其他環(huán)境制定下一代網(wǎng)絡(luò)服務(wù)標(biāo)準(zhǔn)的領(lǐng)導(dǎo)者。OSGi 全名原為 Open Services Gateway initiative，但現(xiàn)在這個(gè)全名已經(jīng)廢棄。
OSGi 聯(lián)盟基于它成立之初的使命，推出了 OSGi 服務(wù)平臺(tái)規(guī)范，用于提供開(kāi)放和通用的架構(gòu)，使得服務(wù)提供商、開(kāi)發(fā)人員、軟件提供商、網(wǎng)關(guān)操作者和設(shè)備提供商以統(tǒng)一的方式開(kāi)發(fā)、部署和管理服務(wù)。
目前最廣為認(rèn)可和應(yīng)用的是 OSGi 規(guī)范 4（R4，Release 4），其最新版本是 4.2，共由核心規(guī)范、標(biāo)準(zhǔn)服務(wù)（Standard Services）、框架服務(wù)（Framework Services）、系統(tǒng)服務(wù)（System Services）、協(xié)議服務(wù)（Protocol Services）、混合服務(wù)（Miscellaneous Services）等幾部分共同組成。核心規(guī)范是 OSGi 規(guī)范中的核心部分，它通過(guò)一個(gè)分層的框架，實(shí)現(xiàn)了 OSGi 最為成功的動(dòng)態(tài)插件機(jī)制，它主要提供了：1. OSGi Bundle 的運(yùn)行環(huán)境；2. OSGi Bundle 間的依賴管理；3. OSGi Bundle 的生命周期管理；4. OSGi 服務(wù)的動(dòng)態(tài)交互模型。
雖然 OSGi 在嵌入式應(yīng)用方面有成功的案例，比如寶馬汽車(chē)的嵌入式應(yīng)用，但真正讓 OSGi 得到認(rèn)可和關(guān)注的則是 Eclipse 項(xiàng)目。Eclipse 是目前著名的一個(gè) IDE，其最大的兩個(gè)特點(diǎn)是插件和擴(kuò)展，而其實(shí)插件機(jī)制正是通過(guò)實(shí)現(xiàn) OSGi 規(guī)范實(shí)現(xiàn)的。下面我們了解下 Eclipse 的核心 Equinox 項(xiàng)目。
Equinox – OSGi R4 的實(shí)現(xiàn)
Equinox 作為 Eclipse 項(xiàng)目中的一個(gè)子項(xiàng)目，是 Eclipse 的運(yùn)行核心（runtime），它是 OSGi R4 核心規(guī)范的參考實(shí)現(xiàn)。Eclipse 構(gòu)建在 Equinox 項(xiàng)目之上，提供了 OSGi 所定義的對(duì) Bundle 動(dòng)態(tài)插拔的功能。
Equinox 項(xiàng)目的目的是成為一個(gè)一流的 OSGi 社區(qū)項(xiàng)目，并作為 Eclipse 項(xiàng)目的試驗(yàn)田，來(lái)開(kāi)發(fā)和發(fā)布 Eclipse 項(xiàng)目中所需要用到的 OSGi 框架實(shí)現(xiàn)，具體的講，Equinox 項(xiàng)目有以下幾方面的職責(zé)：
Equinox 目前是隨著 Eclipse 版本而發(fā)布的，同時(shí)，它也提供獨(dú)立的下載，在獨(dú)立的下載頁(yè)面中可以下載到 Equinox 對(duì)于 OSGi R4 的所有實(shí)現(xiàn)以及 Equinox 擴(kuò)展 OSGi R4 而提供的 Bundle。
了解了 OSGi 以及 SCA，我們便可以將 SCA 與 OSGi 做相關(guān)分析比較。
SCA 和 OSGi 有著不同的提出背景和出發(fā)點(diǎn)，SCA 規(guī)范是為了企業(yè)應(yīng)用集成而制定，OSGi 規(guī)范的初衷則是為移動(dòng)設(shè)備計(jì)算而制定的。由于二者的出發(fā)點(diǎn)不一樣，導(dǎo)致了兩個(gè)規(guī)范的側(cè)重點(diǎn)不一樣。但是隨著 OSGi 的成熟，OSGi 聯(lián)盟于最近成立了企業(yè)專家組（EEG，Enterprise Expert Group），開(kāi)始帶領(lǐng) OSGi 進(jìn)軍企業(yè)應(yīng)用領(lǐng)域，這將使得 OSGi 與 SCA 有了越來(lái)越多的交叉。因此，分析這兩種技術(shù)，將有助于對(duì)這兩種技術(shù)的理解，并可以通過(guò)集成或借鑒對(duì)方來(lái)促進(jìn)這兩種技術(shù)的發(fā)展。下面我們將首先介紹這兩種技術(shù)的關(guān)注點(diǎn)，然后對(duì)這兩種技術(shù)做分析比較。
SCA 和 OSGi 各自的關(guān)注點(diǎn)分析
只有了解了 SCA 和 OSGi 的關(guān)注點(diǎn)，我們才能更好的了解這兩種技術(shù)的應(yīng)用場(chǎng)景，也才能更為客觀的將這兩種技術(shù)做比較，下面討論下這兩種技術(shù)的各自關(guān)注點(diǎn)。
SCA的關(guān)注點(diǎn)
SCA 的目的是成為構(gòu)建 SOA 應(yīng)用的編程模型，它的應(yīng)用領(lǐng)域是企業(yè)應(yīng)用集成領(lǐng)域。SOA 雖然提了很多年，但到目前，在概念方面，各大廠商關(guān)于 SOA 也都有著不同的理解；在實(shí)現(xiàn)技術(shù)方面，也大都是在使用具體的 Web Service，但 Web Service 是一種運(yùn)程調(diào)用技術(shù)，對(duì)于如何開(kāi)發(fā)本地 SOA 應(yīng)用中的服務(wù)，目前也無(wú)統(tǒng)一認(rèn)知；在組件模型方面，目前也沒(méi)有統(tǒng)一的組件模型來(lái)裝配和管理服務(wù)。所以，當(dāng)前的 SOA 應(yīng)用開(kāi)發(fā)缺乏服務(wù)組件模型支持，缺乏從組件層次上來(lái)進(jìn)行服務(wù)聲明、發(fā)布、組裝以及定義互操作性。另外，基于企業(yè)應(yīng)用的特點(diǎn)，不同的應(yīng)用系統(tǒng)可能有不同的實(shí)現(xiàn)技術(shù)，如何能將這些采用不同的技術(shù)實(shí)現(xiàn)的功能發(fā)布為 SOA 中的服務(wù)，并能夠更多的關(guān)注服務(wù)的聲明，而屏蔽底層的實(shí)現(xiàn)，也是 SOA 應(yīng)用開(kāi)發(fā)中需要關(guān)注的一個(gè)問(wèn)題。
而 SCA 通過(guò)一系列規(guī)范的定義，解決了上述問(wèn)題：組件裝配模型提供了對(duì)服務(wù)聲明、發(fā)布、組裝，并通過(guò)綁定功能，來(lái)屏蔽不同服務(wù)間的通信細(xì)節(jié)；支持不同的編程技術(shù)作為服務(wù)組件的實(shí)現(xiàn)，從而可以更好的將遺留系統(tǒng)封裝為系統(tǒng)中的服務(wù)；策略框架同時(shí)提供了對(duì)應(yīng)用系統(tǒng)中 QoS 的支持，以保證企業(yè)應(yīng)用中的質(zhì)量需求。
OSGi的關(guān)注點(diǎn)
OSGi 規(guī)范因?yàn)樽畛醯某霭l(fā)點(diǎn)是為移動(dòng)設(shè)備創(chuàng)建計(jì)算環(huán)境，因此更多的考慮了框架和服務(wù)在運(yùn)行時(shí)刻的動(dòng)態(tài)匹配等問(wèn)題。移動(dòng)設(shè)備通常都是在同一個(gè)嵌入式環(huán)境中工作，所 OSGi 不需要關(guān)心 QoS，不需要支持多種不同的實(shí)現(xiàn)技術(shù)，也不需要支持分布式調(diào)用。
在了解了 SCA 和 OSGi 的關(guān)注點(diǎn)之后，我們就可以對(duì) SCA 和 OSGi 做一個(gè)詳細(xì)比較，下面先給出 SCA 和 OSGi 的異同點(diǎn)對(duì)比表，然后再針對(duì)各個(gè)比較項(xiàng)，作相關(guān)分析。
| 項(xiàng)目 | SCA | OSGi |
|---|---|---|
| 容器實(shí)現(xiàn) | 未定義 | 定義 |
| 模塊定義 | 未定義 | 定義 |
| 組件實(shí)現(xiàn)語(yǔ)言 / 技術(shù) | 語(yǔ)言無(wú)關(guān)（Java、C++ 等） | Java |
| 裝配模型 | 健壯 | 欠健壯 |
| 設(shè)計(jì)期服務(wù)綁定 | 支持 | 不支持 |
| 運(yùn)行期服務(wù)綁定 | 支持 | 支持 |
| 生命周期 | 未定義 | 定義 |
| QoS | 支持 | 不支持 |
| 依賴管理 | 支持設(shè)計(jì)期和運(yùn)行期服務(wù)依賴管理 | 運(yùn)行期服務(wù)和包依賴管理 |
| 遠(yuǎn)程服務(wù) | 支持 | 不支持 |
| 回調(diào)服務(wù) | 支持 | 不支持 |
| 會(huì)話服務(wù) | 支持 | 不支持 |
| 服務(wù)版本管理 | 不支持 | 支持 |
容器實(shí)現(xiàn)
SCA 規(guī)范的最初目的是成為 SOA 的編程模型，著重解決的是如何創(chuàng)建、組裝、部署和使用服務(wù)，它是面向應(yīng)用開(kāi)發(fā)人員的，所以它并不關(guān)心如何去開(kāi)發(fā)支持 SCA 應(yīng)用運(yùn)行的容器。
而 OSGi 規(guī)范因?yàn)樽畛醯某霭l(fā)點(diǎn)是為移動(dòng)設(shè)備創(chuàng)建計(jì)算環(huán)境，因此更多的考慮了框架和服務(wù)在運(yùn)行時(shí)刻的動(dòng)態(tài)匹配等問(wèn)題。所以，它首先關(guān)心的就是如何構(gòu)建一個(gè)運(yùn)行環(huán)境，以便能夠運(yùn)行 OSGi 應(yīng)用。
目前來(lái)看，SCA 規(guī)范中對(duì) SCA 容器的實(shí)現(xiàn)尚沒(méi)有一個(gè)指導(dǎo)性的意見(jiàn)，但業(yè)界有著基于 OSGi 構(gòu)建 SCA 容器的討論，這也是一種將 OSGi 集成到 SCA 中的一個(gè)比較好的方式。
模塊定義
在模塊的定義方面，SCA 規(guī)范只是定義了 SCA 復(fù)合組件作為最小可部署單元，但并沒(méi)有定義個(gè)明確的打包格式要求，也沒(méi)有定義模塊的動(dòng)態(tài)更新和綁定以及模塊間的包依賴，更沒(méi)有定義模塊中的包的可見(jiàn)性。其實(shí)也可以說(shuō)，SCA 規(guī)范在模塊的定義方面幾乎沒(méi)有做工作，SCA 規(guī)范著重定義了設(shè)計(jì)期的服務(wù)聲明和綁定。相比 SCA 規(guī)范，OSGi 規(guī)范則定義了明確的模塊層，并在模塊層中定義了類加載機(jī)制、包的可見(jiàn)性、包依賴以及模塊的打包和描述文件格式。模塊化的定義目前引起了越來(lái)越多的重視，JCP 正在制定 Java 的模塊化規(guī)范 JSR277。
組件實(shí)現(xiàn)語(yǔ)言/ 技術(shù)
SCA 組件的實(shí)現(xiàn)可以是 Java、C++、BPEL、Spring、EJB、WebService 等，而 OSGi 只支持 Java 語(yǔ)言實(shí)現(xiàn)，這也是由于二者的出發(fā)點(diǎn)不同導(dǎo)致。OSGi 應(yīng)用都是運(yùn)行在同一個(gè) JVM 中，所以并不需要考慮多種實(shí)現(xiàn)技術(shù)，而企業(yè)應(yīng)用中，則會(huì)有多種實(shí)現(xiàn)技術(shù)，這就需要 SCA 能夠支持多種實(shí)現(xiàn)技術(shù)
裝配模型和服務(wù)綁定
SCA 服務(wù)裝配模型是整個(gè) SCA 規(guī)范中的核心，而 OSGi 在早期版本中并沒(méi)有服務(wù)裝配模型，在 OSGi DS（Declarative Service）規(guī)范出來(lái)之后，OSGi 才有了明確的組件裝配模型。
SCA 和 OSGi 的裝配模型都可以聲明和發(fā)布服務(wù)，但 SCA 更偏重設(shè)計(jì)期的組件組裝，而且定義了靈活的組件裝配模型，特別是提供了可嵌套的組件裝配模型，可以由最小的原子組件組裝成一個(gè)大系統(tǒng)，而 OSGi 則缺乏組件組裝模型。
在服務(wù)綁定方面，SCA 的服務(wù)綁定需要從兩個(gè)層次上看，在同一個(gè)復(fù)合組件內(nèi)部中的引用，如果沒(méi)有設(shè)定自動(dòng)連線，那它實(shí)際上采用的設(shè)計(jì)期綁定，因?yàn)樵谠O(shè)計(jì)期就需要指定所需要引用的組件及其服務(wù)，這是因?yàn)?SCA 不支持組件和服務(wù)的版本管理，所以在運(yùn)行期永遠(yuǎn)只有一個(gè)同名組件存在，所以也就沒(méi)必要支持運(yùn)行期綁定；在跨復(fù)合組件和跨域間的引用，SCA 采用的是運(yùn)行期綁定，因?yàn)閺?fù)合組件是 SCA 的最小可部署單元，開(kāi)發(fā)人員可能會(huì)在運(yùn)行期重新部署同名的復(fù)合組件。這兩者的差異，相信也是由于目標(biāo)不同導(dǎo)致，OSGi 容器作為一個(gè)嵌入式運(yùn)行環(huán)境，必然需要考慮到各種 OSGi 應(yīng)用的熱插拔和服務(wù)的動(dòng)態(tài)綁定，從而更重視運(yùn)行期的服務(wù)裝配，而 SCA 作為企業(yè)應(yīng)用，既需要考慮支持設(shè)計(jì)期服務(wù)綁定（其實(shí)就是目前廣泛應(yīng)用的利用構(gòu)造方法和 set 方法進(jìn)行依賴注入），也需要考慮跨復(fù)合組件和域間的動(dòng)態(tài)引用。
OSGi 核心規(guī)范中并沒(méi)有定義裝配模型， OSGi DS 規(guī)范作為補(bǔ)足性規(guī)范提出了面向服務(wù)的裝配模型。OSGi DS 中的裝配模型并不支持在設(shè)計(jì)期綁定服務(wù)，而是在運(yùn)行期通過(guò)服務(wù)描述來(lái)查找并綁定服務(wù)，基于這種綁定策略，會(huì)有一定的效率問(wèn)題，但是將極大的提高系統(tǒng)的靈活性和可擴(kuò)展性。
生命周期管理
SCA 規(guī)范由于忽視運(yùn)行期 SCA 系統(tǒng)的變化需求，從而沒(méi)有定義組件的生命周期，但不同的組件實(shí)現(xiàn)技術(shù)可能會(huì)有其自己的生命期周期定義，比如在 SCA Java 版的客戶和實(shí)現(xiàn)模型規(guī)范中，它定義了兩個(gè)用于組件初始化和銷(xiāo)毀時(shí)需要調(diào)用的方法，供 SCA 組件在初始化和銷(xiāo)毀時(shí)作一些預(yù)處理。相比 SCA，OSGi 則提供了完善的生命周期管理。
QoS
由于 OSGi 規(guī)范是面向在同一個(gè) JVM 中運(yùn)行的網(wǎng)絡(luò)設(shè)備以及像 Eclipse 這樣的插件系統(tǒng)，所以在 OSGi 中的服務(wù)不需要 QoS 問(wèn)題，也不需要支持遠(yuǎn)程服務(wù)、回調(diào)服務(wù)和會(huì)話服務(wù)。SCA 規(guī)范則是面向企業(yè)集成領(lǐng)域，所以 SCA 規(guī)范需要考慮 QoS、分布式訪問(wèn)、服務(wù)的回調(diào)和會(huì)話等問(wèn)題。
依賴管理及其它
OSGi 規(guī)范支持運(yùn)行期的服務(wù)和包依賴，而 SCA 規(guī)范只支持設(shè)計(jì)期的服務(wù)依賴，這使得 SCA 系統(tǒng)與 OSGi 系統(tǒng)相比，欠缺靈活性和可擴(kuò)展性。
從現(xiàn)有的應(yīng)用來(lái)看，OSGi 更多的是用來(lái)作為一個(gè)技術(shù)框架來(lái)開(kāi)發(fā)一個(gè)產(chǎn)品，如開(kāi)發(fā) SCA 容器等，而 SCA 規(guī)范更多的是被用在面向企業(yè)應(yīng)用的組件的組裝規(guī)范。
由于 SCA 不強(qiáng)調(diào)在運(yùn)行期的服務(wù)管理，服務(wù)管理應(yīng)該會(huì)利用其它軟件來(lái)實(shí)現(xiàn)，所以它也沒(méi)有提供版本管理機(jī)制，而 OSGi 則提供了版本管理機(jī)制，拿 Eclipse 而言，我們可以裝多個(gè)不同版本的同一個(gè)插件，而不會(huì)影響系統(tǒng)的使用。
限于 OSGi 最初是為了為移動(dòng)設(shè)備而準(zhǔn)備，所以 OSGi 服務(wù)只能在同一個(gè) JVM 中調(diào)用，且不能支持遠(yuǎn)程調(diào)用，這是其企業(yè)應(yīng)用領(lǐng)域的一大缺點(diǎn)，但目前，已經(jīng)有很多關(guān)于分布式 OSGi 這方面的討論。
通過(guò)以上分析，可看出 SCA 和 OSGi 有著很多明顯的區(qū)別，而這些不同其實(shí)也造就了他們之間有著很強(qiáng)的互補(bǔ)性。下面將簡(jiǎn)單介紹下，如何將 OSGi 集成到 SCA 中來(lái)，以便利用 OSGi 的特性來(lái)增強(qiáng) SCA 應(yīng)用。
正如上文介紹，SCA 和 OSGi 由于最初定位的不同，造成了兩者之間有諸多不同之處，但兩者實(shí)際上更多的是一種互補(bǔ)，而不是競(jìng)爭(zhēng)?；诋?dāng)前已有的規(guī)范和實(shí)現(xiàn)，SCA 和 OSGi 的集成工作可以在下面三個(gè)方面展開(kāi)：1. 可以充分利用已有的 OSGi 應(yīng)用，并能夠?qū)?OSGi 應(yīng)用中的服務(wù)發(fā)布成為 SCA 的服務(wù)；2. 能夠讓 SCA 通過(guò)引用來(lái)調(diào)用外部 OSGi 服務(wù)，這也是另外一種可以讓 OSGi 服務(wù)變?yōu)?SCA 服務(wù)的途徑；3. 基于 OSGi 構(gòu)建 SCA 容器。下面簡(jiǎn)單介紹下，如何在這三個(gè)方面來(lái)集成 SCA 和 OSGi。
使用OSGi 作為 SCA 的組件實(shí)現(xiàn)
一種能夠充分利用 OSGi 特性的方法，是將 OSGi 作為 SCA 服務(wù)組件的實(shí)現(xiàn)，而 SCA 的可擴(kuò)展模型也支持 OSGi 作為 SCA 服務(wù)組件實(shí)現(xiàn)，這樣就可以將 OSGi 服務(wù)作為 SCA 服務(wù)發(fā)布，通過(guò)這種途徑，可以將 OSGi 服務(wù)變成可支持遠(yuǎn)程訪問(wèn)的 SCA 服務(wù)，從某種程度上克服 OSGi 服務(wù)不支持跨 OSGi 容器訪問(wèn)這種缺陷。雖然目前 OSOA 組織并沒(méi)有發(fā)布將 OSGi 作為組件的實(shí)現(xiàn)的規(guī)范，但目前 Apache Tuscany 項(xiàng)目已經(jīng)嘗試將 OSGi 作為 SCA 的服務(wù)組件實(shí)現(xiàn)。
使用SCA OSGi 綁定
SCA 和 OSGi 集成的第二個(gè)方面是 SCA 應(yīng)用能夠通過(guò)引用來(lái)訪問(wèn) OSGi 服務(wù)，SCA 應(yīng)用可以通過(guò)綁定來(lái)聲明所需要訪問(wèn)服務(wù)的協(xié)議，目前 OSOA 組織已經(jīng)發(fā)布了 JMS、JCA、Web Service、EJB 這幾種綁定協(xié)議，同將 OSGi 作為 SCA 的組件實(shí)現(xiàn)一樣，雖然 OSOA 目前沒(méi)有發(fā)布 OSGi 綁定規(guī)范，但 Apache Tuscany 項(xiàng)目目前已經(jīng)嘗試支持 OSGi 綁定。
使用OSGi 構(gòu)建 SCA 容器
另一種可以將 OSGi 和 SCA 進(jìn)行集成的方式，就是基于 OSGi 規(guī)范來(lái)開(kāi)發(fā) SCA 容器。這種方式可以最大化的將 OSGi 集成到 SCA 中來(lái)。首先，由于利用 OSGi 來(lái)構(gòu)建 SCA 容器，這就可以較簡(jiǎn)單的做到前兩個(gè)方面的集成；其次，可以將 OSGi 服務(wù)注冊(cè)中心以及 SCA 服務(wù)注冊(cè)中心合并為一個(gè)，甚至可以做到在同一個(gè) SCA 域中，支持 SCA 應(yīng)用通過(guò) SCA 綁定的方式來(lái)訪問(wèn) OSGi 服務(wù)。
集成 OSGi 后的 SCA 將有更多的優(yōu)點(diǎn)，下面作一個(gè)簡(jiǎn)單討論。
SCA 和 OSGi 是互補(bǔ)的，通過(guò)以上這三種方式來(lái)將 OSGi 集成到 SCA 中，可以使 SCA 具有以下幾個(gè)方面的特點(diǎn)：1. 支持 OSGi 這種主流技術(shù)作為服務(wù)組件的實(shí)現(xiàn)，給開(kāi)發(fā)人員提供了更多的技術(shù)選擇；2. 可以更容易的通過(guò) SCA 的裝配模型，將已有的 OSGi 服務(wù)發(fā)布為 SCA 服務(wù)，從而實(shí)現(xiàn) OSGi 服務(wù)的遠(yuǎn)程調(diào)用支持；3. 可以利用 OSGi 在模塊化、動(dòng)態(tài)性方面的優(yōu)勢(shì)來(lái)彌補(bǔ) SCA 在這兩方面的不足。
目前業(yè)界關(guān)于 SCA 和 OSGi 集成的討論也越來(lái)越多，可以預(yù)見(jiàn)，這兩種技術(shù)可以通過(guò)互補(bǔ)的方式，來(lái)促進(jìn)這兩種技術(shù)的發(fā)展。
本文介紹了 SCA 在各個(gè)演化階段中的發(fā)展和變化，并將 SCA 與 OSGi 技術(shù)進(jìn)行了對(duì)比分析，最后還探討了如何將 OSGi 集成到 SCA 中。通過(guò)以上介紹，可以發(fā)現(xiàn)，SCA 經(jīng)過(guò)短短幾年的發(fā)展，已經(jīng)有了長(zhǎng)足的進(jìn)步，再加上諸多主流廠商的支持，使得其極有可能成為下一代 SOA 編程模型。
聯(lián)系客服
