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