自上週三釋出 SpringSource 應用程式平臺以來，眾多開發者已下載了 1.0.0 測試版，並開始試用該平臺。因此，人們開始提出這樣的問題：“我如何在平臺上部署我的應用程式？我有哪些部署和打包選項？”此外，開發者們迫切希望看到實際執行的示例。為此，S2AP 團隊將在未來幾周內釋出多個示例應用程式，演示這些功能及更多內容。但在您接觸這些示例之前，我想先對平臺中可用的部署和打包選項進行高層次的概述。閱讀本文後，您將能夠迅速上手示例以及您自己的應用程式。

概述

正如 Rob 上週在他的文章 Introducing the SpringSource Application Platform 中提到的，該平臺支援以下形式打包的應用程式：

1. 原始 OSGi 捆綁包
2. Java EE WAR
3. Web 模組
4. 平臺歸檔 (PAR)

當您將應用程式部署到平臺時，每個部署工件（例如，單個捆綁包、WAR 或 PAR）都會經過一個部署管道。此部署管道支援個性化部署器的概念，這些部署器負責處理具有特定個性（即應用程式型別）的應用程式。平臺的 1.0.0 版本原生支援與上述每種打包選項類似的個性化部署器。此外，部署管道可以透過附加的個性化部署器進行擴充套件，平臺的未來版本將為諸如批處理、Web 服務等個性提供支援。

現在讓我們更仔細地瞭解每個受支援的部署和打包選項，以探討哪一個最適合您的應用程式。

原始 OSGi 捆綁包

SpringSource 應用程式平臺的核心是一個 OSGi 容器。因此，任何符合 OSGi 規範的捆綁包都可以直接部署到平臺上而無需修改。如果您希望透過 OSGi 服務登錄檔在容器內全域性釋出或消費服務，通常會將應用程式部署為單個捆綁包或一組獨立捆綁包。但請注意，由於 PAR 格式的作用域特性，獨立捆綁包將無法跨應用程式邊界消費服務。換句話說，獨立捆綁包無法引用部署在 PAR 中的模組的服務。

WAR 部署選項

對於 Web 應用程式歸檔 (WAR)，SpringSource 應用程式平臺支援以下三種格式。

1. 標準 Java EE WAR
2. 共享庫 WAR
3. 共享服務 WAR

這些格式中的每一種在從標準 Java EE WAR 到 OSGi 化 Web 應用程式的增量遷移路徑中都扮演著獨特的角色。

標準 WAR

正如 Rob 已經指出的，“平臺直接支援標準 WAR 檔案。在部署時，WAR 檔案會被轉換為 OSGi 捆綁包並安裝到 Tomcat 中。所有標準的 WAR 契約都得到了遵守，您現有的 WAR 檔案應該可以直接放入並部署而無需更改。” 對標準、未修改的 WAR 檔案的支援讓您可以在現有 Web 應用程式上試用 SpringSource 應用程式平臺，然後逐漸遷移到共享庫 WAR、共享服務 WAR 和Web 模組格式。

共享庫 WAR

如果您有使用標準 WAR 格式開發和打包 Web 應用程式的經驗，那麼您肯定熟悉庫膨脹的痛苦。因此，除非您將共享庫安裝到 Servlet 容器的公共庫資料夾中，否則您必須將 Web 應用程式所需的所有 JAR 打包到 /WEB-INF/lib 中。在平臺釋出之前，這種庫膨脹基本上是 Web 應用程式的常態，但現在有了更好的解決方案！共享庫 WAR 格式透過允許您透過標準 OSGi 清單頭（如 Import-Package 和 Require-Bundle）宣告對庫的依賴關係，從而減少了應用程式的部署佔用空間並消除了庫膨脹。平臺透過 Import-Library 和 Import-Bundle 清單頭提供了額外的支援，以簡化依賴管理，這些清單頭本質上是宏，會擴充套件為符合 OSGi 規範的 Import-Package 語句。

有關您已擁有的各種庫的詳細資訊，請檢視 SpringSource 企業捆綁包儲存庫。此外，Andy Wilkinson 將於本週晚些時候釋出一篇部落格，解釋如何在應用程式和 SpringSource 應用程式平臺中最大限度地利用捆綁包儲存庫。敬請關注。

共享服務 WAR

一旦您開始利用共享庫 WAR 的宣告式依賴管理，您很可能會發現自己希望邁出下一步，以進一步收穫 OSGi 容器的益處：在您的 OSGi 相容捆綁包和 Web 應用程式之間共享服務。透過構建在 Spring-DM 的強大功能和簡易性之上，共享服務 WAR 格式讓 OSGi 服務登錄檔觸手可及。作為最佳實踐，您通常會透過 <osgi:service ... /> 從您的域、服務和基礎設施捆綁包釋出服務，然後透過 <osgi:reference ... /> 在您的 Web 應用程式的 ApplicationContext 中消費它們。這樣做促進了面向介面程式設計，並允許您將 Web 特定的部署工件與您的領域模型、服務層等完全解耦，這無疑是朝著正確方向邁出的一步。在三種受支援的 WAR 部署格式中，就模組化和 Web 應用程式的整體佔用空間減少而言，共享服務 WAR 是迄今為止最具吸引力的。

Web 模組

除了基於 WAR 的部署格式，SpringSource 應用程式平臺還為符合 OSGi 規範的 Web 應用程式引入了一種部署和打包選項，即Web 模組格式。Web 模組的結構與共享服務 WAR 類似，因此可以充分利用所有三種 WAR 部署格式。此外，Web 模組透過新的 OSGi 清單頭（如 Web-DispatcherServletUrlPatterns 和 Web-FilterMappings）減少了基於 Spring MVC 的應用程式的配置。有關這些以及其他 Web-* 清單頭的更多詳細資訊，請查閱平臺的 程式設計師指南。平臺的即將釋出的版本也將支援 web.xml 片段以及上述清單頭。

如果您正在構建一個基於 Spring MVC 的 Web 應用程式作為 Web 模組，您無需擔心配置根 WebApplicationContext 或用於 DispatcherServlet 的 ApplicationContext。根據您的 Web 模組的 /META-INF/MANIFEST.MF 中的元資料，平臺將為您即時自動生成一個配置適當的 web.xml，您的應用程式將使用 Spring-DM 為您的 Web 模組建立的 ApplicationContext。未來的版本還將增加對簡化基於 Spring Web Flow 的 Web 應用程式配置的額外支援。

從 WAR 到 Web 模組的遷移路徑

下圖以圖形方式描繪了從標準 WAR 到 Web 模組的遷移路徑。如您所見，庫從部署工件內部移至捆綁包儲存庫。類似地，服務從 WAR 內部移至外部捆綁包，並透過 OSGi 服務登錄檔訪問。此外，隨著您向 Web 模組遷移，部署工件的整體佔用空間會減小。

平臺檔案

最後一部分是 PAR（平臺歸檔）部署格式。PAR 是一個標準 JAR，其中包含應用程式的所有模組（例如，服務、域和基礎設施捆綁包，以及用於 Web 應用程式的 WAR 或 Web 模組），作為一個單一的部署單元。這允許您將整個應用程式作為一個單一實體進行部署、重新整理和解除安裝。對於熟悉 Java EE 的人來說，PAR 在 OSGi 容器的上下文中可以被視為 EAR（企業歸檔）的替代品。作為一個額外的優勢，PAR 中的模組可以獨立地、動態地重新整理，例如透過 SpringSource 應用程式平臺工具套件（註冊測試版程式並檢視 Eclipse 工具支援）。

此外，PAR 還在平臺內對應用程式的模組進行作用域。作用域提供了物理和邏輯的應用程式邊界，將應用程式的內部細節與平臺內部署的任何其他應用程式隔離開來。這意味著您的應用程式不必擔心與其他正在執行的應用程式（例如，在 OSGi 服務登錄檔中）發生衝突。您獲得了載入時織入、類路徑掃描、上下文類載入等支援，並且平臺為您完成了所有這些工作，以使其在 OSGi 環境中無縫執行。如果您想充分利用 SpringSource 應用程式平臺和 OSGi 提供的一切，將您的應用程式打包和部署為 PAR 絕對是推薦的選擇。

接下來該怎麼做

如果您還沒有這樣做，我鼓勵您加入 測試版計劃，親自試用 SpringSource 應用程式平臺。

您可以在使用者指南和程式設計師指南中找到最新的文件，如果您在部署應用程式時遇到任何問題，或對我們如何改進平臺有任何建議，請隨時建立 JIRA 問題。

最後但同樣重要的是，請務必關注SpringSource 團隊部落格上的後續帖子，以瞭解有關平臺的最新訊息，並檢視實際執行的示例，其中包括一個經過模組化並打包為 PAR 的 OSGi 化 Spring PetClinic 示例應用程式。