我很高興報告(與 Adrian 一起)經過 3 個里程碑和 2 個候選釋出版後,Spring Dynamic Modules(之前稱為 Spring OSGi)1.0 已正式釋出。
自我上一篇帖子(關於 1.0 M1)以來,許多功能得到了改進或增加;我將在未來的博文中更詳細地討論它們(還有參考文件詳細解釋了該庫),所以我在此僅列舉幾點:
- 一致性
我們希望提供一個強大、簡單且一致的程式設計模型。這就是 Spring Dynamic Modules 構建在 Spring 之上,並利用其久經考驗的概念、可靠性和普適性的原因。
- 高度非侵入性
推薦使用 Spring DM 的方式是不要在你的程式碼中使用它的類,也不要在你的 Bundle 清單檔案中匯入它們。如果你不在程式碼中使用 Spring,只將其用於應用程式配置,同樣的規則也適用。Spring DM 會為你建立應用程式上下文,因此你無需依賴 Spring 或 Spring DM。而且不用擔心自定義名稱空間或 XML Schema 之類的事情,我們已經涵蓋了這些。
- OSGi 服務動態生命週期管理
這是 Spring DM 最重要的特性之一——能夠像與普通 Bean 一樣與 OSGi 服務互動。你無需編寫任何程式碼即可釋出和消費 OSGi 服務;我們將為你處理這些動態變化——並且你擁有完全的控制權(將來會詳細介紹)。
- 更智慧的整合測試框架
由於我們在內部廣泛使用 Spring-DM 整合測試,我們改進了預設設定、Maven 整合,並使自動清單生成比以前更快、更智慧。例如,該框架會自動確定測試 Bundle 中可用的類,並且不會為其生成匯入語句。
- 簡單的 Bundle 互動
Andy Piper(部落格)添加了一種簡單、宣告式的方式,根據模組生命週期和 Spring Bean 依賴關係來安裝/啟動/停止/更新 Bundle。
- 受管的啟動/關閉上下文建立
在 OSGi 中,應用程式被分解成各種模組(也稱為 Bundle),它們相互依賴於彼此的服務。這在模組之間建立了一個依賴樹,這在啟動和關閉過程中變得非常重要。傳統上,這可以透過根據依賴順序安裝和啟動 Bundle 來解決,然而,這並不能完全解決問題。正如 OSGi 規範建議的那樣,初始化時間長的 OSGi 服務(例如連線池)應該依賴於與用於啟動和停止 Bundle 的執行緒不同的執行緒。這意味著,如果一個 Bundle 已啟動,並不代表其服務也已可用。而且並非每個應用程式都準備好在啟動期間等待所需的服務——事實上,很少有這樣做。這意味著一個 Bundle 將會失敗,因為它依賴的服務在幾毫秒後才釋出(OSGi 預設是一個虛擬機器內平臺,其中事情發生得非常快)。
這種行為並非罕見——事實上,在多核平臺和多個 Bundle 同時啟動時,這種情況非常普遍。Spring DM 透過確定依賴關係(從 Spring 配置中獲取)並在它們可用後才建立應用程式上下文來解決這個問題。在關閉時也會採用類似的過程,Spring DM 將根據依賴順序停止上下文,這樣你就無需擔心啟動或停止你的 Bundle。
- 無執行緒依賴等待
我無法討論依賴機制而不提及 Hal Hildebrand(參見他的部落格)實現的用於依賴等待的“無執行緒”方法(我知道這聽起來有點像矛盾修飾,我們正在為此想一個更好的名字)。由於各種服務需要可用才能使模組正常啟動,因此需要某種形式的等待/監控,這傳統上意味著使用一個執行緒。
然而,在一個 OSGi 平臺上可能有(而且將來會有)多個模組(幾十個很常見)——為每個模組使用一個等待執行緒根本無法擴充套件。我們努力改進這個模型,我相信我們提供了一個非常好的解決方案——在等待過程中完全不使用執行緒。這意味著無論部署了 3 個 Bundle 還是 300 個,都不會消耗 CPU 時間,除非你的模組實際開始啟動。
Spring Dynamic Modules 不僅僅是將一個 API “Spring 化”,而是處理一個不同的執行時環境。
在工具方面,Spring IDE 支援 Spring DM 名稱空間,並且(感謝 Christian)還為 Eclipse PDE 提供了 Spring-DM 特定的目標,這些功能在 Spring IDE nightly builds 中可用(有關安裝和使用外掛的更多資訊可在參考文件中找到)。
未來方向
既然 1.0 已經發布,下一步是什麼?有很多領域需要涵蓋:
Web 支援
OSGi 平臺提供了專用的 Http 服務,但使用它需要編寫程式碼。資源載入、JSP 生成和部署等事情可以大大簡化。這是 1.1 版本的主要重點領域。
持久化
現代持久化工具提供了諸如延遲載入等高階功能,這些功能由於依賴於類生成和代理而會彎曲 OSGi 環境強制執行的模組邊界。我們希望解決這個問題,並像 Web 支援一樣,在使用純 JDBC 或/和 ORM 工具時提供流暢的體驗。
AOP
繼持久化問題之後,我們正在尋找在 OSGi 內部進行通用 AOP 的解決方案。這是一個難題,要正確實現它,需要內部 OSGi 平臺的支援。好訊息是,像 Equinox Aspects 這樣的專案已經開闢了道路,並且 OSGi 企業專家組 (EEG) 也已將此問題提上議程。
說夠了
如果你想了解更多關於 Spring Dynamic Modules 的資訊,請檢視專案頁面和參考文件,並務必使用我們的郵件列表(論壇即將上線)。此外,最近我們製作了一些 OSGi/Spring DM 截圖影片,這些影片可在 Spring DM 主頁上找到。第一個影片(分為兩部分),由我親自制作,展示瞭如何快速建立一個專案,以便使用 Spring DM 進行整合測試。
為什麼是整合測試?因為使用 Spring DM,這是一個非常簡單快捷的過程,也是學習 OSGi 的非常有效的方式(尤其是在模組化方面)。
未來會有更多截圖影片——請告訴我們你想看什麼,我們將根據請求數量進行安排。
事不宜遲,"使用 Spring DM 進行 OSGi 整合測試"
