自上周三发布 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 示例应用程序。