我很高興地報告（和 Adrian 一起），經過 3 個里程碑版本和 2 個候選釋出版本，Spring Dynamic Modules（之前稱為 Spring OSGi）1.0 已釋出。

自我的上一篇文章（關於 1.0 M1）以來，許多功能得到了改進或新增；我將在未來的文章中詳細介紹它們（還有詳細解釋該庫的參考文件），所以這裡只列舉一些

- 一致性

我們希望提供一個強大、簡單且一致的程式設計模型。這就是 Spring Dynamic Modules 構建在 Spring 之上並利用其成熟的概念、可靠性和普遍性的原因。

- 高度非侵入性

使用 Spring DM 的推薦方式是不要在您的程式碼中使用其類，也不要在您的 Bundle Manifest 中匯入它們。如果您只將 Spring 用於應用程式配置而不用於程式碼，同樣的規則也適用。Spring DM 會為您建立應用程式上下文，因此您無需依賴 Spring 或 Spring DM。並且不必擔心自定義名稱空間或 XML Schema 之類的事情 - 我們已經涵蓋了這些。

- OSGi 服務動態生命週期管理

這是 Spring DM 最重要的特性之一 - 能夠像處理普通 Bean 一樣與 OSGi 服務互動。您無需編寫任何程式碼即可釋出和消費 OSGi 服務；我們將為您處理動態性 - 並且您擁有完全的控制權（未來將對此進行更多介紹）。

- 更智慧的整合測試框架

由於我們在內部廣泛使用了 Spring-DM 整合測試，我們改進了預設配置、Maven 整合，並使自動 Manifest 生成比以前更快、更智慧。例如，框架會自動確定測試 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 每夜構建版本中的可用功能（有關安裝和使用該外掛的更多資訊可在參考文件中找到）。

 

未來方向

 

既然 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 整合測試”