自 Spring Dynamic Modules 的第一個里程碑以來，執行 OSGi 中 Web 應用程式的請求開始湧入。這可能是最受歡迎的功能之一，而且毫不奇怪，一旦 1.0 最終版釋出，Web 支援就一直是 1.1 分支的主要關注點。我很高興地報告，隨著剛剛釋出的 M2，正如 Juergen 已經暗示的那樣，Spring-DM 不僅支援標準的 war（自 1.1.0 M1 起可用），還支援在 OSGi 中執行的 Spring-MVC 應用程式。在本文中，我想簡要討論典型的 OSGi Web 場景和 Spring-DM 的方法。但首先，

為什麼要在 OSGi 中部署 WAR？

簡單問題：OSGi *原生* 提供版本控制、包連線和熱重載入。想象一下在您的應用程式中利用這些功能：您可以停止將庫嵌入WEB-INF/lib並將它們在 Web 應用程式之間共享，避免 taglibs 重複（同時保持多個版本執行），並即時更新應用程式的特定部分。這尤其有用，因為 Web 應用程式往往是分層的，因此在其生命週期中會經歷大量更改。

為什麼 OSGi 中的 Web 應用程式存在問題？

Servlet 規範圍繞著一個*Web 容器*的概念：一個為 Web 元件提供執行時環境的執行時環境，該環境提供標準服務，如生命週期管理（物件建立和處置、執行緒分配）、併發、HTTP 請求處理等。另一方面，OSGi 平臺也作為具有服務登錄檔、包連線和版本控制（僅舉幾例）的託管環境。為了解決這個問題，OSGi 委員會設計了 compendium 規範的一部分，即 Http Service。

順帶一提，在處理兩個託管環境時，會遇到一個有趣的問題：應該使用哪種部署模型？也就是說，哪個是引導平臺，哪個是嵌入式平臺。在我們的案例中，可以將 OSGi 平臺部署為 WAR，或者將 Web 容器（以某種服務形式）部署到 OSGi 平臺內部。更多關於這方面的內容，將在未來的博文中介紹。

這項可選服務提供了一個簡單的 API，用於註冊Servlet以及靜態資源，這些資源會對映到傳入的 HTTP 請求。為了在 OSGi 中Servlet提供服務請求，必須**以程式設計方式**建立Servlet例項並透過上述 API 進行註冊。此外，Http 服務僅支援Servlet2.1 規範，這可能非常不方便，因為過濾器和監聽器（當今幾乎所有 Web 框架都使用）不可用。大多數（如果不是全部）我所知的、用於在 OSGi 中執行 Web 應用程式的解決方案，都依賴於 Http 服務來實現其功能。據我所知，其中一些解決方案透過以下一種技術來解決上述問題：

• 透過強制採用新的宣告式方法或轉換現有的宣告式方法（例如web.xml）來呼叫 Http 服務，從而消除對程式碼的需求
• 透過在 2.1 API 之上進行構建（例如，可以透過裝飾Servlet例項）或透過擴充套件標準 API 來提供Servlet2.1+ 功能

這兩種方法都可以成功併發揮很大作用，然而，在 Spring-DM 中，我們選擇了另一種獨特的方法，即

直接與 Web 容器整合

在 Spring-DM 中，OSGi 和容器空間被橋接起來：WAR 包照常部署到 Web 容器，但它們使用 OSGi 空間作為類路徑和資源查詢。這種方法的主要優點是，對於 OSGi 平臺和 Web 容器來說，都沒有發生重大變化——一切都“照常運作”。

使用 Spring-DM，您可以獲得

• 完整的 Servlet 2.4/2.5、JSP 2.0/2.1 規範支援
• 容器功能的可用性（阻塞與非阻塞 IO、執行緒池中的分配執行緒等）
• 完全訪問web.xml語法，無論是關於過濾器、監聽器、對映宣告、安全還是 JNDI 引用。這在容器與 JTA 事務管理器或 JMS 佇列整合的情況下尤其有用。請注意，Spring-DM 不進行解析（我們認為容器在這方面做得比我們**好得多**）
• 容器特定的配置檔案（例如 Tomcat 的META-INF/context.xml)

以上所有以及更多功能之所以成為可能，是因為 Spring-DM 將 bundle **原生**部署到選定的 Web 容器（目前支援 Apache Tomcat 5.5.x/6.0.x 和 Jetty 6.1.x+）。這意味著 Web 容器負責例項化和管理 Web 應用程式，因此容器支援的幾乎所有內容都可供 OSGi bundle 使用。

雖然 1.1 尚未最終確定，但我鼓勵您嘗試一下 M2。API 基本上已經穩定，新功能也已記錄在案（隨著我們接近 GA 版本，將有更多內容），如果您需要幫助，請檢視 Spring-DM 論壇（是的，我們終於有了！）和郵件列表。此外，如果您恰巧參加了 JavaOne，請光臨 SpringSource 展位，您將從源頭獲得答案。