InfoQ 有一個討論串，總結了對於 SpringSource Application Platform 公告的回應。Michael Burke 在該討論串中提出了一個很棒的問題，可以概括為「忘記圍繞 OSGi 的炒作，如果我將目前封裝為 EAR 的應用程式移植到 OSGi bundles，我可以期望看到什麼好處？」。

我開始在 InfoQ 討論串上回答這個問題，但我的答案變得太長，不適合作為評論，所以我在這裡回答。

這個問題問得很好。您在基於 OSGi 的應用程式與傳統基於 JEE EAR 的應用程式中看到的主要區別是改進的模組化。所以問題變成，這種改進的模組化是否給我帶來任何好處，如果有，那是什麼？「設計規則，模組化的力量」這本書對這個問題進行了非常透徹的闡述。這是一個很棒的背景知識，但我感覺 Michael 可能正在尋找一些比您在那本書中找到的更少理論性的東西！讓我們將模組化的好處分解為兩類：您應該期望在開發時體驗到的好處，以及您應該期望在執行時體驗到的好處。

開發時的好處。

• 嚴格的開發時（和執行時）模組邊界強制執行
OSGi 有機制來確保模組邊界受到開發團隊的尊重。使用 OSGi，模組匯出的類型是明確宣告的（如果沒有匯出，則不可見），並且模組的依賴項也是明確宣告的（這可以包括版本範圍相容性資訊）。這意味著，當使用開發工具時，團隊無法透過程式碼自動完成功能讓自己違反模組邊界，並且在執行時，OSGi 服務平台將阻止一個模組看到另一個模組的私有內部結構。因此，您的應用程式架構在開發週期中保持乾淨和受保護，而不是透過（通常是無意的）不必要的耦合而慢慢崩潰。
• 一種有效運作的服務導向架構，用於管理模組之間的服務依賴關係。
模組之間的依賴關係不僅限於類型——模組還需要提供服務（想想 Spring beans）供其他模組使用，並且可能依賴於其他模組提供的服務（再次想想 Spring beans）。不要將您的應用程式基本上視為一個大型應用程式上下文，而是將其視為一組透過本地服務註冊表互動的對等上下文。Spring beans（組件）對於模組是私有的，除非明確匯出。跨模組的 Bean 參考由執行時管理。再次強調，這意味著在模組上工作的開發人員可以自由地進行任何內部變更，只要外部契約（發佈的 beans、匯出的類型）保持不變即可。當使用 Spring Dynamic Modules 時，模組的匯入和匯出類型以及匯入和匯出服務都是宣告式指定的（前者在 OSGi manifest 中，後者在 Spring 設定檔中）。
• 更好地根據您的需求建構開發團隊的能力
「組織遵循架構」。很容易指派一個團隊來處理給定的模組或多個模組。要求一個團隊實作一個跨越多個模組的功能要困難得多。因此，自然而然地趨勢是，您的技術架構（您如何將系統劃分為模組）決定了您的組織結構——即您能夠多麼有效地在團隊和個人之間劃分工作。模組化您的應用程式的更大彈性意味著建構您的團隊的更大彈性。有時您會看到相反的情況：「架構遵循組織」。當存在形成分散式團隊的共置人員組時，這種情況往往會發生。為了做出明智的工作分配，您希望盡可能將模組與地點對齊。因此，如果您無法移動人員，那麼在合理程度上，您的架構是由您的組織決定的。您在模組分解方面擁有的彈性越大，您找到適合您的方案的機會就越大。
• 更快的團隊協作開發
當模組具有清晰的邊界時——定義明確的外部介面、明確指定的依賴關係和受保護的內部結構，在這些模組上工作的團隊更容易並行開發，而不會意外地互相干擾。明確指定的互動更容易進行 Stub 和 Mock，也更容易整合。這應該會提高團隊的生產力並加快開發週期。
• 更快的測試週期
當您在容器中進行測試時，用於 Eclipse 的 SpringSource Application Platform 開發工具利用 OSGi 服務平台動態更新執行系統中給定模組的能力。與您的專案相關聯的增量建構器會在您進行變更時自動更新執行平台實例中的模組。這可以是任何變更——程式碼或其他。因此，例如，如果您在 Web 層工作，持續與您的 Web 應用程式互動並在過程中進行測試，則 Web 模組將在每次變更時刷新——並且您無需等待每次重新初始化您的持久層。Spring Dynamic Modules 提供的服務參考的智慧型管理確保在刷新後修復所有模組間連結。這種開發體驗非常令人上癮：您已被警告！
• 支援版本控制作為依賴項管理的一部分
當模組指定其依賴項時，它可以為其相容的依賴項版本提供版本範圍（可以限制為單一版本）。OSGi 允許在執行時同時存在多個版本的 Java 套件。這允許以下情況：模組 A 上的團隊需要某個程式庫的版本 x，而模組 B 上的團隊需要某個程式庫的版本 y（x 和 y 不相容）。只要模組 A 和模組 B 永遠不需要在它們之間交換來自該程式庫的類型，這就可以順利運作。如果模組 A 和模組 B 確實需要在它們之間交換類型，那麼 OSGi 服務平台將在部署時而不是執行時偵測到這種潛在的衝突（假設兩個模組的 manifest 已正確產生）。
• 更少的障礙
與我的其他觀點（與一般 OSGi 相關）不同，這一點是 SpringSource Application Platform 特有的。我們確信，如果您開始在 SpringSource Application Platform 上開發基於 Spring 和 OSGi 的企業應用程式，您會遇到比您嘗試直接針對 OSGi 服務平台進行開發（即使程式設計和部署模型相同）時更少的障礙，企業程式庫不會像您期望的那樣在 OSGi 下運作。

執行時的好處

執行時的好處源於 OSGi 中的模組不僅僅是開發時的建構。它們在執行時非常存在，有自己的生命週期，並且可以在執行系統中進行檢查。

• 關於已安裝模組及其佈線的完整資訊在執行時可用——操作團隊從未有過的洞察層次。
您可以列出所有已安裝的 bundles 及其版本，查看它們正在匯出和匯入的套件，以及查看它們正在匯出和匯入的服務（以及提供這些服務和套件的 bundles 的身分）。以前，操作團隊對執行應用程式的了解很少或沒有超出 JEE 部署單元層次，OSGi 改變了這一切。（順便一提，SpringSource Application Management Suite 提供了更多的洞察力，但那是另一個主題）。
• 隔離變更
由於可以獨立安裝、解除安裝、更新和刷新模組，因此您可以透過將變更範圍縮小到較小的單元（bundle）來降低對生產應用程式進行變更的風險。應用程式的其餘部分（其他 bundles）可以保持不變。是的，您可能會有一個漫長的變更控制流程，這意味著實際上進行變更的速度不會更快，但至少您現在可以更確定地進行變更，而不會引入任何其他意外的差異。
• 共享依賴項
OSGi 對版本控制的支援使得在平台上安裝受信任版本的企業程式庫並在應用程式之間共享它們成為可能。
• 僅使用您需要的伺服器設施
由於伺服器平台本身是以模組化的方式建立在 OSGi 之上的，因此您可以將平台配置為僅具有支援目前在其上執行的應用程式或多個應用程式所需的服務。

與 OSGi 無關的好處

如果您根本不在乎 OSGi 呢？？？那麼 SpringSource Application Platform 是否帶來任何好處？

是的，它確實帶來好處。

我喜歡這樣看待 SpringSource Application Platform

首先，它是一個伺服器。一個輕量級的可配置伺服器，專注於服務性（請參閱Rob 關於該平台的原始文章）。它具有有用的功能，例如每個應用程式分離的追蹤和日誌檔、死鎖偵測、故障偵測和傾印處理、智慧型執行緒池和工作竊取等等。基於這些原因，它是部署 Web 應用程式的好地方。

其次，它是一個理解基於 Spring 的應用程式的伺服器。Spring 已開箱即用整合，部署人員可以簡化封裝和部署基於 Spring 的應用程式的流程——例如，透過消除對樣板 web.xml 檔案的需求，僅用於配置 Spring 的 DispatcherServlet。

第三，也是僅僅第三，它支援終端使用者應用程式的 OSGi，提供我上面已經概述的好處。