自从我们上周三发布 SpringSource 应用平台以来，许多开发人员已经下载了 1.0.0 测试版，并开始试用该平台。因此，人们开始询问：“如何在平台上部署我的应用程序，以及我有哪些部署和打包选项？” 此外，开发人员渴望看到有效的示例。作为回应，S2AP 团队将在未来几周内发布几个示例应用程序，以演示这些功能以及更多功能，但在您获得这些示例之前，我想向您简要概述平台中可用的部署和打包选项。阅读本文后，您将准备好使用示例以及您自己的应用程序。

概述

正如 Rob 上周在他的文章介绍 SpringSource 应用平台中提到的那样，该平台支持以下形式打包的应用程序：

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 部署格式中，共享服务 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 模块，则无需担心配置根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 的人来说，在 OSGi 容器的上下文中，PAR 可以被认为是 EAR（企业归档）的替代品。作为一个额外的奖励，PAR 中的模块可以独立地和动态地刷新，例如通过SpringSource 应用平台工具套件（注册测试版程序并查看 Eclipse 工具支持）。

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

接下来的步骤

如果您还没有这样做，我鼓励您加入测试版程序并亲自试用 SpringSource 应用平台。

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

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