OSGi 系列(一)之什么是 OSGi :Java 語言的動態模塊系統


OSGi 系列(一)之什么是 OSGi :Java 語言的動態模塊系統

OSGi 的核心:模塊化、動態。基於 OSGi 就可以模塊化的開發 java 應用,模塊化的部署 java 應用,還可以動態管理模塊。

OSGi(Open Service Gateway Initiative) 技術是 Java 動態化模塊化系統的一系列規范。OSGi 一方面指維護 OSGi 規范的 OSGi Alliance(OSGi 聯盟),另一方面指的是該組織維護的基於 Java 語言的服務(業務)規范。簡單來說,OSGi 可以認為是 Java 平台的模塊層,為大型分布式系統以及嵌入式系統提供一種模塊化架構減少了軟件的復雜度。

1. 什么是 OSGi

OSGi 聯盟(OSGi Alliance)於 1999 年開始着手制定 OSGi 規范,其主要目的就是要制定一套開放式標准,以便向局域網及其中的設備提供可管理的服務;其基本思路是,一旦您在網絡設備(如服務器和嵌入式設備)上使用了 OSGi 服務平台,您就可以在網絡上的任何地方管理這些設備上運行的軟件組件的生命周期,可以在后台對這些組件進行安裝、升級或卸載,但不需要打斷該設備的正常運行。Eclipse 就是基於 OSGi 開發的。

2. OSGi 標准

OSGI R1 於 2000 年發布,現在最新的標准版本是 R5,到現在為止應用最廣泛的當屬是 2005 年發布的 R4。

其中主要定義了 OSGi 框架。OSGi 框架提供了一個通用安全可管理的 java 框架,能夠支持可擴展可下載的應用(即 bundles)的部署。OSGi 框架是 OSGi 技術最基礎也是最核心的部分。

這里你需要理解 OSGi 框架的三個最重要部分:模塊層、生命周期層、服務層。

圖1.1 OSGi 框架組成

  • 模塊層 :關注打包和代碼共享。

    OSGi 是嚴格要求模塊化的,模塊有個專有名詞 bundle。每個模塊都是一個 bundle,一個 Business Logic 由多個 bundle 來實現。

    注:后面全部使用 bundle 代替模塊來表述。

  • 生命周期層 :關注提供執行模塊管理和對底層 OSGi 框架的訪問。

    bundle 是需要 OSGi 進行解析的,每個 bundle 在變得可用之前,都需要完整經歷該生命周期。

  • 服務層 :關注模塊,特別是模塊內的組件的交互和通訊。

    OSGi 技術全面貫徹了 SOA,每個 bundle 都是其他 bundle 提供服務,誇張一點說,不提供服務的 bundle 就沒有存在的價值。

2.1 OSGi 三層架構-模塊層

模塊化其實就是計算機科學中常見的一個概念:將一個大型系統分解為多個較小的互相協作的邏單元,通過強制設定模塊之間的邏輯邊界來改善系統的維護性和封裝性。

模塊層定義了 OSGi 中的模塊 bundle:

  • bundle 是以 jar 包形式存在的個模塊化物理單元,里面包含了代碼,資源文件和元數據(metadata),井且 jar 包的物理邊界也同時是運行時邏輯模塊的封裝邊界。

  • bundle 是開發、部署 OSGi 應用的基本單元。

  • bundle 的核心是 META-NF 目錄下的 MANIFEST.MF 文件。

  • bundle 定義了其所包含的包的可見性、可以認為是在 public/private/protected 的基礎上的一個擴展。

  • bundle 的 java 包共享、屏蔽的規則。通過 Export-Package、Import-Package 方式進行交互。

  • 每個 bundle 都有單獨的類加加載器。

來看看在 MANIFEST.MF 中可以定義哪些 Bundle 的的元數據信息:

屬性 屬性描述
Bundle-Activator Bundle 的 Activator 類名
Bundle-Category Bundle 的分類屬性描述
Bundle-Classpath Bundle 的 Classpath
Bundle-Copyright Bundle 的版權
Bundle-Description Bundle 的描述信息
Bundle-DocURL Bundle 的文檔 URL 地址
Bundle-Localization Bundle 的國際化文件
Bundle-ManifestVersion 定義 Bundle 所遵循的規范的版本, OSGI R3 對應的值為1, OSGI R4 對應的值為2
Bundle-Name Bundle的有意義的名稱
Bundle-NativeCode Bundle 所引用的 Native Code 的地址
bundle-RequiredExecutionEnvironment Bundle 運行所需要的環境,如可指定為需要 OSGI R3、Java1.4、Java1.3 等
Bundle-SymbolicName Bundle 的唯一標識名,可采用類似 java package 名的機制來保證唯一性
Bundle-Version Bundle 的版本
Dynamiclmport-Package Bundle 動態引用的 package
Export-Package Bundle對外暴露的 package
Fragment-Host Fragment 類型 Bundle 所屬的 Bundle 名
Import-Package Bundle 引用的 package
Require-Bundle Bundle 所需要引用的其他的 Bundle

2.2 OSGi 三層架構-生命周期

狀態是 Bundle 在運行期的一項動態屬性,不同狀態的 Bundle 具有不同的行為,生命周期層規范定義了 Bundle 生命周期過程之中的 6 種狀態。

圖1.2 Bundle生命周期的6種狀態

OSGi 生命周期層有兩種不同的作用:

  • 在應用程序外部,定義了對 bundle 生命周期的相關操作。OSGi 生命周期層允許在執行時,從外部安裝、啟動、更新、停止、卸載不同的 bundle 進而定制應用的配置。

  • 在應用程序內部,定義了 bundle 訪問其執行上下文的方式,為 bundle 提供了一種與 OSGi 框架交互的途徑以及一些執行時的便利條件。

2.3 OSGi 三層架構-服務層

OSGi 的服務層除了面向服務的編程模型,還有一個區別於其他很多類似模型的特性。也就是說,當一個 bundle 發現並開始使用 OSGi 中的一個服務了以后,這個服務可能在任何的時候改變或者是消失。

OSGi 框架有一個中心化的注冊表,這個注冊表從 publish-find-bind 模型:

圖1.3 OSGi服務層

3. OSGi 綱要規范

除了上述 OSGi 核心規范(core specification)中的服務,OSGi 聯盟也定義了一組非核心的(non-core)標准服務,稱為 compendium 服務。Core 服務在任何運行的 OSGi 框架內都是可用的,這要求所有的 OSGi 框架都要實現核心服務。而 compendium 服務則不然。這些服務以分離的 bundle 的形式出現,由框架實施者或者第三方實現並提供,能在任何框架上運行。

  • LOG Service(日志服務)
  • HTTP Service(注冊 servlet 和資源)
  • Configuration Admin(配置管理)
  • Event Admin(事件通知)
  • Declarative Services(定義輕量級的面向服務的組件模型)
  • Blueprint(一個類似 IOC 容器的實現)

4. OSGi 特點

從開發的角度:

  • 復雜性的降低:基於 OSGi 的組件橫型 bundle 能夠隱藏內部實現,bundle 基於服務進行交互。
  • 復用:很多第三方的組件可以以 bundle 的形式進行復用。
  • 簡單:核心的 API 總過包括不超過 30 個類和接口。
  • 小巧: OSGi R4 和實現僅需要 300KB 的 JAR file 就足夠。在系統中引入 OSGi 幾乎有什么開銷。
  • 非侵入式:服務可以以 POJO 的形式實現,不需要關注特定的接口。

從可維護的角度:

  • 切合真實運行環境:OSGi 框架是動態的,bundle 能夠進行即時的更新,服務可以根據需要動態增加或者刪除。
  • 易於部署:OSGi 定義了組件是如何安裝和管理的,標准化的管理 API 使得 OSGi。 能夠和現有和將來的各種系統有機的集成。
  • 動態更新:這是 OSGi 被最經常提起的一個特性,即所謂的 "熱插拔" 特性,bundle 能夠動態的安裝、啟動、停止、更新和卸載,而整個系統無需重啟。
  • 適配性:這主要得益於 OSGi 提供的服務機制、組件可以動態的注冊、獲取和監聽服務,使得系統能夠在 OSGi 環境調整自己的功能。
  • 版本化:bundle 可以版本化,多版本能夠共存而不會影響系統功能。
  • 懶加載:OSGi 技術采用了很多懶加載機制。比如服務可以被注冊,但是直到被使用時才創建。

5. OSGi VS 傳統 java 模塊化

"OSGi" 相比 "傳統 java 模塊化" 有以下優勢:

  • 基於接口編程,完全隱藏底層代碼實現
  • 動態性(對擴展開放,即使是運行時的)
  • 版本控制

部分支持 OSGi 的項目:

Apache cxf、Apache thrift、Apache activemq、Apache curator Activiti、drools、mysql-connector-java、postgresql(java client)、rabbitmq(java client)、hazelcast

OSGi 的缺點:

  • 目前只支持Java
  • 入門高、技術更加復雜
  • 相對的重量級
  • 資料匱乏
  • lib 支持的不好,很多 lib 無法在 OSGi 環境下運行

6. OSGi 開源框架介紹

  1. Equinox:OSGi R4 core framework 的一個實現,一組實現各種可選的 OSGi bundle 和一些開發基於 OSGi 技術的系統所需要的基礎構件。 Eclipse 是基於 Equinox 項目開發的一個典型例子。具體內容可以從 http://www.eclipse.org/equinox/ 下載。

    比較適合不需要集成太多外部技術的應用,如桌面應用開發,當需要進行集成時,會遇到相當多的兼容性問題;

  2. Apache Felix:實現 OSGi R4 規范(包括 OSGi 框架,Standard Service 和其它 OSGi 相關技術)的另一個開源項目。具體內容可以從 http://felix.apache.org/ 下載。

    與 Equinox 非常相似,都屬於基礎環境。但也有一個最大的不同,其兼容性、可擴展性都比較強,能夠很方便的集成 Web Container、DataSource 管理等許多實際開發中必須具備的組件。但是這里有個很大的隱患:所有的集成都需要手工完成,質量、測試都無法保證,作為系統最重要的基礎運行環境,其穩定性、可靠性是至關重要的。

  3. Apache Karaf:一個基於 OSGi 的運行環境,它提供了一個輕量級的 OSGi 容器,可以用於部署各種組件和應用程序。它提供了很多的組件和功能用於幫助開發人員更加靈活的部署應用,更適合作為商業化產品的開發、運行平台。具體內容可以從 http://karaf.apache.org/ 下載。

結論:使用 karaf 作為接下來的 OSGi 基礎平台,進行下一步的 JavaEE 與 OSGi 整合工作。

參考:

http://blog.csdn.net/cz_jjq/article/details/50378661


免責聲明!

本站轉載的文章為個人學習借鑒使用,本站對版權不負任何法律責任。如果侵犯了您的隱私權益,請聯系本站郵箱yoyou2525@163.com刪除。



 
粵ICP備18138465號   © 2018-2025 CODEPRJ.COM