自上周三发布 SpringSource 应用平台以来，许多开发者下载了 1.0.0 Beta 版本并开始试用该平台。因此，人们开始问：“我如何在平台上部署我的应用，以及我有哪些部署和打包选项？” 此外，开发者们迫切希望看到可运行的示例。为了回应这一需求，S2AP 团队将在未来几周发布几个示例应用，演示这些功能以及更多内容，但在您获取这些示例之前，我想先向您介绍一下该平台中可用的部署和打包选项的高级概览。阅读本文后，您将能够快速上手这些示例以及您自己的应用。

概览

正如 Rob 上周在他的帖子《介绍 SpringSource 应用平台》中提到的，该平台支持以下形式打包的应用

1. 原生 OSGi Bundle
2. Java EE WAR
3. Web 模块
4. 平台归档 (PAR)

当您将应用部署到该平台时，每个部署工件（例如，单个 bundle、WAR 或 PAR）会通过一个部署管道。这个部署管道支持“个性化部署器”的概念，它们负责处理具有特定个性（即应用类型）的应用。该平台的 1.0.0 版本原生支持与上述每种打包选项相对应的个性化部署器。此外，部署管道可以通过添加其他个性化部署器进行扩展，该平台的未来版本将支持诸如批处理、Web 服务等个性化功能。

现在让我们仔细看看每种支持的部署和打包选项，以探索哪种最适合您的应用。

原生 OSGi Bundle

SpringSource 应用平台的核心是一个 OSGi 容器。因此，任何 OSGi 兼容的 bundle 都可以直接在平台上未经修改地部署。如果您想通过 OSGi 服务注册表在容器内全局发布或消费服务，通常会将应用部署为一个单独的 bundle 或一组独立的 bundle。然而请注意，由于 PAR 格式的作用域特性，独立的 bundle 将无法跨应用边界消费服务。换句话说，一个独立的 bundle 无法引用部署在 PAR 内的模块的服务。

WAR 部署选项

对于 Web 应用归档文件 (WAR)，SpringSource 应用平台支持以下三种格式。

1. 标准 Java EE WAR
2. 共享库 WAR
3. 共享服务 WAR

这些格式中的每一种都在从标准 Java EE WAR 到 OSGi 化 Web 应用的增量迁移路径中扮演着独特的角色。

标准 WAR

正如 Rob 已经指出的，“标准 WAR 文件在平台中直接支持。在部署时，WAR 文件被转换为 OSGi bundle 并安装到 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 企业 Bundle 仓库。此外，Andy Wilkinson 将于本周晚些时候发布一篇博客，解释如何在您的应用和 SpringSource 应用平台中最大限度地利用 Bundle 仓库。敬请关注。

共享服务 WAR

一旦您开始使用共享库 WAR 利用声明式依赖管理，您可能会发现自己想迈出下一步，以获取 OSGi 容器的更多益处：在 OSGi 兼容的 bundle 和您的 Web 应用之间共享服务。通过利用 Spring-DM 的强大功能和简洁性，共享服务 WAR 格式将 OSGi 服务注册表置于您的指尖。作为最佳实践，您通常会通过 <osgi:service ... /> 从您的领域、服务和基础设施 bundle 中发布服务，然后通过 <osgi:reference ... /> 在您的 Web 应用的 ApplicationContext 中消费它们。这样做可以促进面向接口编程，并允许您将 Web 特定的部署工件与您的领域模型、服务层等完全解耦，这无疑是朝着正确方向迈出的一步。在三种支持的 WAR 部署格式中，共享服务 WAR 在模块化和减小 Web 应用总体占用空间方面无疑是最具吸引力的。

Web 模块

除了基于 WAR 的部署格式之外，SpringSource 应用平台引入了一种针对 OSGi 兼容 Web 应用的部署和打包选项，即Web 模块格式。Web 模块的结构与共享服务 WAR 相似，因此可以充分利用所有三种 WAR 部署格式。此外，Web 模块通过新的 OSGi 清单头（例如 Web-DispatcherServletUrlPatterns 和 Web-FilterMappings）减少了基于 Spring MVC 应用的配置。有关这些以及其他 Web-* 清单头的更多详细信息，请查阅平台的程序员指南。该平台的未来版本还将支持 web.xml 片段以及上述清单头。

如果您正在构建一个基于 Spring MVC 的 Web 应用并将其作为 Web 模块，您无需担心为您的 DispatcherServlet 配置一个根 WebApplicationContext 或 ApplicationContext。根据您 Web 模块的 /META-INF/MANIFEST.MF 中的元数据，平台将即时为您自动生成一个配置恰当的 web.xml，并且您的应用将使用 Spring-DM 为您的 Web 模块创建的 ApplicationContext。未来版本还将增加对简化配置基于 Spring Web Flow 的 Web 应用的支持。

从 WAR 到 Web 模块的迁移路径

下图以图形方式描绘了从标准 WAR 到 Web 模块的迁移路径。如您所见，库从部署工件内部移到 Bundle 仓库。类似地，服务从 WAR 内部移到外部 bundle 中，并通过 OSGi 服务注册表访问。此外，随着您向 Web 模块迁移，部署工件的总体占用空间会减小。

平台归档

最后的关键是 PAR（平台归档）部署格式。PAR 是一个标准的 JAR 文件，它将您应用的所有模块（例如，服务、领域和基础设施 bundle，以及 Web 应用的 WAR 或 Web 模块）包含在一个单独的部署单元中。这使您可以将整个应用作为一个单独的实体进行部署、刷新和取消部署。对于熟悉 Java EE 的人来说，在 OSGi 容器的环境中，PAR 可以被视为 EAR（企业归档）的替代品。额外的好处是，PAR 内的模块可以独立地、即时地刷新，例如，通过 SpringSource 应用平台工具套件（注册 Beta 计划并查看 Eclipse 工具支持）。

此外，PAR 限定了您的应用在平台内的模块范围。范围限定提供了物理和逻辑的应用边界，保护您的应用内部不受平台内其他任何应用的影响。这意味着您的应用无需担心与其他正在运行的应用冲突（例如，在 OSGi 服务注册表中）。您可以获得加载时织入、类路径扫描、上下文类加载等支持，并且平台会为您完成繁重的工作，使所有这些在 OSGi 环境中无缝运行。如果您想充分利用 SpringSource 应用平台和 OSGi 提供的所有优势，将您的应用打包和部署为 PAR 绝对是推荐的选择。

下一步

如果您还没有这样做，我鼓励您加入Beta 计划并亲自试用 SpringSource 应用平台。

您可以在用户指南和程序员指南中找到最新的文档，如果您在部署应用时遇到任何问题，或者对如何改进平台有任何建议，请随时创建 JIRA 问题。

最后同样重要的是，请务必关注SpringSource 团队博客上即将发布的文章，以了解平台的相关新闻，并查看可运行的示例，包括一个已模块化并打包为 PAR 的 OSGi 化 Spring PetClinic 示例应用。