InfoQ 有一個 討論帖 總結了對 SpringSource 應用平臺釋出公告的反應。Michael Burke 在該帖中提出了一個 很棒的問題，可以這樣轉述：“拋開圍繞 OSGi 的炒作，如果我將目前打包為 EAR 的應用程式移植到 OSGi bundles，我能期望看到什麼好處？”

我開始在 InfoQ 帖子中回答這個問題，但我的答案對於評論來說太長了，所以我將在這裡解決。

這個問題問得很好。OSGi 應用程式與傳統 JEE EAR 應用程式之間的主要區別在於模組化程度的提高。所以問題就變成了，這種改進的模組化是否能給我帶來任何好處，如果能，它們又是什麼？《設計規則：模組化的力量》一書對這個問題進行了非常詳盡的闡述。這是一部很棒的背景讀物，但我感覺 Michael 可能想了解一些比那本書更具實踐性的內容！我們把模組化的好處分為兩類：在開發階段可以預期的好處，以及在執行時可以預期的好處。

開發階段的好處。

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

執行時優勢

執行時優勢源於這樣一個事實：OSGi 中的模組不僅僅是開發時期的構造。它們在執行時真實存在，擁有自己的生命週期，並且可以在執行系統中進行檢查。

• 有關已安裝模組及其連線的完整資訊可在執行時獲得——這是運維團隊以前從未有過的洞察力。
您可以列出所有已安裝的 Bundle 及其版本，檢視它們正在匯出和匯入的包，以及它們正在匯出和匯入的服務（以及提供這些服務和包的 Bundle 的身份）。以前，運維團隊除了 JEE 部署單元級別之外，對正在執行的應用程式幾乎沒有可見性，OSGi 改變了這一切。（另外，SpringSource Application Management Suite 提供了更多洞察力，但那是另一個話題）。
• 隔離變更
由於可以獨立安裝、解除安裝、更新和重新整理模組，因此您可以透過將更改限定在較小的單元（bundle）來降低對生產應用程式進行更改的風險。應用程式的其餘部分（其他 bundle）可以保持不變。是的，您可能有一個漫長的變更控制流程，這意味著實際進行更改並沒有更快，但至少您現在可以更有信心地進行更改，確保沒有引入任何其他意外差異。
• 共享依賴項
OSGi 對版本控制的支援使得在平臺中一次性安裝企業庫的受信任版本，然後在應用程式之間共享它們變得實用。
• 只使用您需要的伺服器功能
由於伺服器平臺本身以模組化的方式構建在 OSGi 之上，因此您可以將平臺配置為只包含您需要的服務，以支援當前在其上執行的一個或多個應用程式。

非 OSGi 相關的好處

如果您對 OSGi 根本不感興趣怎麼辦？SpringSource Application Platform 還能帶來什麼好處嗎？

是的，有。

我喜歡這樣看待 SpringSource Application Platform

首先，它是一個伺服器。一個輕量級可配置的伺服器，專注於可維護性（請參閱Rob 關於該平臺的原始帖子）。它具有有用的功能，例如每個應用程式獨立的跟蹤和日誌檔案、死鎖檢測、故障檢測和轉儲處理、智慧執行緒池和工作竊取等。因此，它是部署 Web 應用程式的絕佳選擇。

其次，它是一個理解基於 Spring 應用程式的伺服器。Spring 開箱即用，部署器可以簡化基於 Spring 應用程式的打包和部署過程——例如，透過取消對樣板 web.xml 檔案以配置 Spring 的 DispatcherServlet 的需求。

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