OSGi 4.2 規範發布了

 

OSGi 4.2 規範發布了

原文：OSGi 4.2 released
，Infoq

作者：Alex Blewitt

於 2009 年 9 月 16 日

譯者：88250
於 2009 年 9 月 17 日

 

 

OSGi 聯盟
前天發布了 OSGi 4.2
規範。雖然早期草稿已經早己可用，但這是最終規範發布版本。

一些 OSGi 實現，例如 Equinox
3.5 與 Felix
2.0 早已針對 OSGi 4.2 規範做了一些相容實現，但當時 OSGi 4.2 還沒有發布，當然也不能說其實現了 OSGi 4.2 規範。現在規範正式發布了，各實現團隊還需要進行一些調整已完全滿足規範要求。

新的規範裡有哪些特性呢？InfoQ 曾經發布了一篇關於新 OSGi 規範預測的文章
，現在規範正式發布了，看看究竟有哪些特性是我們必須關注的：

• 架構啟動（
  Framework launching）
  
  以前雖然可以在 Java 應用中（例如 Equinox 的 servlet 橋接
  ）啟動嵌入的 OSGi 引擎，但針對特定引擎都有特定的啟動方式。雖然有一些封裝器（例如 Pax Runner
  ）使得引擎啟動相對容易，但還是必須熟悉特定引擎的知識。在現在的規範中，定義了透明的啟動機制使得不需要知道 OSGi 實現引擎就可以將其啟動。這樣一來，不管是在 Equinox 還是 Felix 下測試都只用替換啟動類路徑下的相應引擎 Jar 包就可以了。

• 遠程服務（Remote Service）
  
  以前也許你曾經聽說過分布式 OSGi（Distributed OSGi）以及
  RFC 113，而 OSGi 4.2 中的遠程服務就是類似技術的新名字，它將各個 OSGi 虛擬機器（OSGi VMs）串連到了一起。遠程服務採用了服務
  的概念（熱拔插 OSGi 應用的精髓），提供了匯出服務到遠程消費端與在本地消費遠程服務的機制。與其他分布式方法（例如 RMI）不同的是，遠程服務不需要實現特殊介面，也不用拋出 checked exception
  。當然，發生異常的時候遠程服務不會裝作工作正常，可以把異常看作是一種在任何情況下都因該進入並作用於 OSGi 環境的服務。

• 籌備服務（Blueprint Service）
  
  OSGi 4.2 中的籌備服務的概念非常類似於控制反轉 /
  依賴注射。它允許用戶端從外部設定檔指定已連線的服務，此服務將被動態地串連到用戶端。向聲明式服務一樣，你可以對服務類型上做些限制，例如是否為強制
  （mandatory）；但與聲明式服務也有些不同，當所需服務缺失時籌備服務可以提供一個預設的服務代理實現，當客戶代碼嘗試調用此服務時，用戶端將被
  服務代理阻塞，直到真正的服務串連成功。綜上，使用籌備服務的特性可以避免與 OSGi 產生耦合，這使得應用既可以在 OSGi
  環境內運行，也可以脫離 OSGi 環境運行。

• Bundle 追蹤器（Bundle Tracker）
  
  OSGi 早已有了服務追蹤器，用於監控服務的來龍去脈；而 Bundle 追蹤器是追蹤 bundles 的一個擴充。在以前在服務中就可以使用
  BundleListener 來監聽 bundle 動態進出，而如今的 BundleTracker 與 ServiceListener
  有著同等的可用性。其可被用於執行動態註冊當籌備服務或是聲明式服務正在讀取（與處理）中繼資料。例如，一個基於 Web
  的引擎就可以自動地掃描出新安裝的 bundles，並通過 HttpService 自動註冊 servlets。

• 服務鉤子（Service Hooks）
  
  在判斷存在什麼服務時，是可以對服務之間的事件進行攔截、過濾的。例如在實現一個基於角色的許可權模型或是針對不同產品級禁用 /
  可用對應功能集。另一個方法是提供代理服務（或是負載平衡）從而攔截其他 bundle
  的事件將其隱藏，以備在後續階段代理給其他機制（例如分布式服務）。另外，監聽鉤子也可以在服務沒有被註冊前按需將服務啟動。

• 條件化的許可權（Conditional permissions）
  
  OSGi 4.2 在有關許可權方面的升級包含了拒絕訪問（DENY access）與允許訪問。在認證簽名後，可以為 bundles 子集顯示地指定操作許可權。可以鎖定未簽名的 bundles 的安裝，有助於構建一個安全的 OSGi 平台。

 

OSGi 4.2 規範相對於 4.1 版還有很多變化，例如 OSGi bundles 有自己的 MIME 類型 （application/vnd.osgi.bundle
），
可以為某個 bundle 指定表徵圖以及許可證，對於聲明式服務可以簡化其許可權集合設定（使用包內友好替代了 protected）。DS
schema 也允許其他對特定服務資訊有助的 XML 元素。另外，提供了一個機制使得應用管理員可以在應用結束是擷取該應用的傳回值。

Equinox 3.5 已經提供了一些類似的功能，Apache Felix
對類似功能在這個月初也通過了測試（早於 4.2 規範發布）。這個月結束前，OSGi 官方將針對 4.2 規範發布測試套件相關資訊。

InfoQ 採訪了 Richard Nicholson， Paremus
的奠基人兼 CEO，作者 Paremus Service Fabric
OSGi 雲
。對於新規範，他有著如下見解：

“在過去幾年中，我們構建基於分布式 OSGi 的系統的經驗使得我們非常迫切地想看到相關規範，OSGi 4.2 規範中的遠程服務與籌備服務特性正式地將其標準化了。”

你認為 OSGi 4.2 最值得關注的部分是什麼呢？