OSGi 4.2規范終於在9月中旬發布，下面介紹一些OSGi 4.2新規范中的特性。本文原文來自InfoQ的Alex Blewitt發布的消息。
51CTO編輯推薦：OSGi入門與實踐全攻略
一些 OSGi 實現，例如 Equinox 3.5 與 Felix 2.0 早已針對 OSGi 4.2 規范做了一些兼容實現，但當時 OSGi 4.2 還沒有發布，當然也不能說其實現了 OSGi 4.2 規范。現在規范正式發布了，各實現團隊還需要進行一些調整已完全滿足規范要求。
新的規范裡有哪些特性呢？
框架啟動（ 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 規范發布測試套件相關信息。
