這段時間看了不少的文章都是關(guān)于 SCA 與 OSGI之間比較的。且不論他們之間到底有沒有關(guān)系，我們來看看他們的定義 SCA 服務(wù)構(gòu)件架構(gòu) (Service Component Architecture) 是一套規(guī)范，它描述了采用面向服務(wù)的體系結(jié)構(gòu)來搭建應(yīng)用和系統(tǒng)時的模型。 SCA 擴展并完善了以前實現(xiàn)服務(wù)的方法，并且 SCA 構(gòu)建在開放的標準之上， 例如： Web Service 服務(wù)構(gòu)件架構(gòu) SCA （ Service Component Architecture ）為建設(shè)基于面向服務(wù)的體系結(jié)構(gòu)的應(yīng)用和系統(tǒng)提供了一種編程模型。這基于一種觀點，即業(yè)務(wù)功能以一系列服務(wù)的形式被對外提供出來，然后它們被組合在一起去實現(xiàn)滿足特定業(yè)務(wù)需求的解決方案。這些復合的應(yīng)用，可以包含專門為此應(yīng)用程序創(chuàng)建的新服務(wù)，也可以包含來自已有的系統(tǒng)和應(yīng)用程序的業(yè)務(wù)功能，重復利用就像其中的一部分一樣。 SCA 即為組合服務(wù)提供了模型，也為服務(wù)構(gòu)件的創(chuàng)建，包括在 SCA 組裝中重用已有應(yīng)用系統(tǒng)的功能提供了模型。 OSGi OSGi 是什么， OSGi 是一種服務(wù)運行平臺。通過實現(xiàn)能夠提供服務(wù)的符合 OSGi 規(guī)范的組件，用戶可以將其組件發(fā)布到 OSGi 運行平臺，供用戶和其他組件使用。 OSGi 組件提供的服務(wù)具有兩個層面的含義：系統(tǒng)層面，即一個組件為其他組件提供服務(wù)，這些服務(wù)體現(xiàn)為 Java 接口的實現(xiàn)；業(yè)務(wù)層面，即一個組件為外部系統(tǒng)或用戶提供某種業(yè)務(wù)服務(wù)實現(xiàn)。 從概念看我們可以很快發(fā)現(xiàn)他們的相同點和不同點。 他們都是一種組件模型，而且是面向服務(wù)的編成模型，都對服務(wù)組件模型作了相應(yīng)的定義。在兩種模型中都有“模塊”，“組件”，“服務(wù)”這 3 種共同的概念。我們分別從這三種感念來看看他們之間的差別 模塊： 可能 OSGi 對于模塊的概念定義的更完善一點，支持模塊的動態(tài)更新和依賴，而 SCA 對于模塊的概念中沒有涉及動態(tài)更新的概念 ( 實際如果把 SCA 中的模塊映射到 JEE 中的 EAR 塊就可以做到了 ) ，對于模塊間依賴關(guān)系的定義也沒有 OSGi 中 Export/import 定義的完美，對于一個包的引用，要存在 2 個不同的副本，至少 WPS （ IBM 中 SCA 的實現(xiàn)）中是這樣。所以說模塊的定義 OSGi 要比 SCA 要完善，實際上這樣是兩種模型出發(fā)點是完全不同的， OSGi 設(shè)計之初主要是面向網(wǎng)絡(luò)設(shè)備的，最后被 Eclipse 所采用才為大家所知的，而 SCA 從一開始就是面向企業(yè)級應(yīng)用的，所以這方面沒有 OSGi 定義的完善。模塊的定義 OSGi 是在 MANIFEST.MF 文件中通過元數(shù)據(jù)定義的，而 SCA 是在 sca.module 文件中定義的 xml 格式。從這點上我們就可以看出來， OSGi 只能是在 java 平臺上（他的規(guī)范中說明也是只適合 java 平臺的，規(guī)范的 0layer 定義了它的最小 runtime ），而 SCA 是一種跨平臺的規(guī)范，它不依賴于平臺，你可以是 Java 環(huán)境也可以 C++ 環(huán)境。 對于組件的概念，個人感覺 OSGi 是在 DS （ OSGI R4 的 Declarative Services ）出來以后才有了比較定性的定義，而 SCA 從一開始就非常強調(diào)組件的定義，對于 SCA 組件可以是一個 webservice ，一個 java 對象，一個有限狀態(tài)機中的規(guī)則對象，也可以是一個 BPEL 流程對象，還可以一個人工干預(yù)的工作流對象，更可以是許多組件的組合對象，這一點 OSGi 組件是做不到，也不要想 OSGi 能夠做到，因為他們的設(shè)計出發(fā)點根本是不同的，不要把企業(yè)級應(yīng)用的東西強加到 OSGi 中來，在 OSGi 中的組件可以發(fā)布 / 查找服務(wù)， SCA 也可以這么做，對于服務(wù)的引用， OSGi 只能是在 single JVM 中，不要怪 OSGi 要知道他當初設(shè)計的目標就是網(wǎng)絡(luò)設(shè)備，不用考慮企業(yè)級應(yīng)用中的分布式，服務(wù)質(zhì)量什么的。但是組件概念上 SCA 有一點還是弱于 OSGi ， OSGi 對服務(wù)的引用可以做到動態(tài)更新，一個服務(wù)改變了，它可以動態(tài)的或者是靜態(tài)的更新應(yīng)用它服務(wù)的組件對象，這一點在網(wǎng)絡(luò)設(shè)備中是非常重要的，但是在 SCA 這種企業(yè)級應(yīng)用中到底需不許多要我們還需要考慮，畢竟如果我們是面向接口編成，而不用關(guān)心細節(jié)是什么，你的服務(wù)再怎么更新，只要我們的接口不變就不會用什么問題。 而服務(wù)，最大的差別可能就是 OSGi 是在 single JVM 內(nèi)的所以對于服務(wù)的引用永遠都是直接的內(nèi)存引用吧，而 SCA 在服務(wù)的引用上附加了 Binding 的概念也就多了一個協(xié)議的選擇層，很象 jmx 中 distributed layer ， SCA 對于服務(wù)的 Export/Import 都需要 Binding 一個具體的實現(xiàn)，你的服務(wù)可以通過 WebService 來發(fā)布，也可以通過 RMI ， JMS 等等來發(fā)布。這一點是 SCA 的設(shè)計出發(fā)點來決定的（面向企業(yè)級的應(yīng)用開發(fā)）。對于服務(wù)的調(diào)用，不僅僅是必須在環(huán)境內(nèi)的調(diào)用，也可以在環(huán)境外進行調(diào)用，比如你在一個 JSP 頁面想要調(diào)用 SCAExport 出來的服務(wù)，你就可以通過 SCA 提供的 Tools 直接調(diào)用， OSGi 是不支持環(huán)境外調(diào)用的。 從以上來看 OSGi 和 SCA 除了基于同樣的設(shè)計方法，其他的不具什么可以比較性，因為他們設(shè)計的根本意圖上是不同的，一個是用在單一個的 JVM 中的面向網(wǎng)絡(luò)設(shè)備或者像 Eclipse 這種應(yīng)用，不需要考慮服務(wù)質(zhì)量，服務(wù)的可靠性，分布式，等等。而 SCA 從誕生之初就為了解決 SOA 應(yīng)用中的規(guī)范性，而且與他同級別的還有 SDO 來定義服務(wù)的數(shù)據(jù)對象，這一點也是 OSGi 中沒有定義的。 有人會說 OSGi 最近正在定義在企業(yè)級應(yīng)用的規(guī)范（ EEG ）， Eclipse 的 RSP 也在做相應(yīng)的努力。但是如果是在 SCA 之外另開辟出一個新的模型空間，個人覺得不太可能，畢竟 SCA 是 IBM ， BEA ， Oracle ， Sap 這些廠商在認識到許多現(xiàn)有技術(shù)的不足之后總結(jié)出來的設(shè)計模型，是這些廠商經(jīng)驗的積累，就像 OSGi 是 OSGi 組織在網(wǎng)絡(luò)設(shè)備應(yīng)用中的積累的一樣，這兩種技術(shù)只能出現(xiàn)互補性，再說 SCA 模型的定義充分體現(xiàn)的軟件界一貫的規(guī)則“重用”，不管是 IBM 的 WPS ，還是 Apache 的 Tuscany 都是以現(xiàn)有平臺為出發(fā)點設(shè)計的，是把 SCA 這種模型與現(xiàn)實技術(shù)做一定的映射，例如，如何實現(xiàn)異步調(diào)用就可以以借助 JEE 環(huán)境中的消息或者 Corba 中消息機制。 真希望看到 OSGi 的 EEG 組織和 SCA 規(guī)范定制組織合作的場景。這樣不僅可以讓組件服務(wù)思想得到升華，還能為企業(yè)級開發(fā)開辟一個新的天地。 以上觀點純屬個人感觸，不代表任何特別的言論，其實最近正打算吧原有的平臺遷移到 OSGi 平臺上，在研究過程中發(fā)現(xiàn)了許多有趣的地方。 歡迎大家一起討論 OSGi 和 SCA 技術(shù)。
posted on 2008-03-15 09:22 風 閱讀(493) 評論(0) 編輯 收藏