我很榮幸地宣布（與 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 綱要等問題 - 我們已經涵蓋了它們。

- 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 是一個 VM 內平台，其中的事情發生得非常快）。

這種行為並不罕見 - 事實上，在具有多個 bundle 的多核心平台上，這種行為在啟動時非常常見。 Spring DM 通過確定依賴關係（從 Spring 配置中）並在建立應用程式上下文之前等待它們可用來解決此問題。 在關閉時將使用類似的過程，屆時 Spring DM 將根據其依賴順序停止上下文，因此您不必擔心啟動或停止 bundle。

- 無執行緒依賴等待

我不能討論依賴機制，而不提及用於依賴等待的「無執行緒」方法（聽起來有點像矛盾修飾法，我知道 - 我們正在為其設計一個花哨的標題），該方法由 Hal Hildebrand 實施（請參閱他的部落格）。 由於需要各種服務才能使模組正確啟動，因此需要某種等待/監控，這傳統上意味著使用執行緒。

但是，在 OSGi 平台上可以（並且將會）有多個模組（很容易有幾十個）- 為每個模組使用等待執行緒根本無法擴展。 我們努力改進的一件事是改進此模型，我相信我們提供了一個非常好的解決方案 - 在等待過程中根本不使用執行緒。 這意味著無論部署了 3 個 bundle 還是 300 個 bundle，除非您的模組實際啟動，否則不會花費任何 CPU 時間。

 

Spring Dynamic Modules 不僅僅是將 API「Spring-ifying」，而是處理不同的運行時環境。

 

關於工具，Spring IDE 支援 Spring DM 命名空間，並且（感謝 Christian）還為 Eclipse PDE 提供了 Spring-DM 特定的目標，這是 Spring IDE 夜間建置版本中提供的功能（有關安裝和使用外掛程式的更多資訊，請參閱參考文件中提供的資訊）。

 

未來方向

 

現在 1.0 已經發布，下一步是什麼？ 有很多領域需要涵蓋：

Web 支援

OSGi 平台提供專用的 Http Service，但使用它需要編碼。 諸如資源載入、JSP 產生和部署之類的事情可以大大簡化。 這是 1.1 版本的主要重點領域。

持久性

現代持久性工具提供諸如延遲載入之類的高級功能，這些功能會彎曲 OSGi 環境強制執行的模組化邊界，因為它們依賴於類別產生和代理。 我們希望解決此問題，並且像提供 Web 支援一樣，無論使用純 JDBC 或/和 ORM 工具，都能提供流暢的體驗。

AOP

在持久性問題之後，我們正在尋找在 OSGi 內部進行通用 AOP 的解決方案。 這是一個難啃的骨頭，並且要正確地執行它，需要內部 OSGi 平台支援。 好消息是，像 Equinox Aspects 這樣的專案已經引領了道路，並且 OSGi Enterprise Expert Group (EEG) 也將該問題納入了他們的雷達。

 

說夠了

 

如果您想了解更多關於 Spring Dynamic Modules 的資訊，請參閱 專案頁面和參考文件，並使用我們的郵件清單（論壇將很快出現）。 此外，最近我們製作了一些 OSGi/Spring DM 螢幕錄影，這些錄影可在 Spring DM 首頁上找到。 第一個錄影（由我製作，分為兩個部分）展示了如何快速建立一個專案以使用 Spring DM 進行整合測試。
為什麼要進行整合測試？ 因為使用 Spring DM 進行整合測試是一個非常簡單且快速的過程，並且是學習 OSGi 的一種非常有效的方法（尤其是在模組化方面）。

未來將會有更多的螢幕錄影 - 只需告訴我們您想看什麼，我們將根據請求的數量對它們進行相應的排隊。

事不宜遲，「使用 Spring DM 進行 OSGi 整合測試」