InfoQ 上有一个 讨论主题，总结了对 SpringSource Application Plaform 发布的反应。Michael Burke 在该主题上提出了一个 很好的问题，可以概括为“抛开围绕 OSGi 的炒作，如果我将当前打包为 EAR 的应用程序移植到 OSGi 捆绑包，可以预期看到哪些好处？”。

我开始在 InfoQ 主题中回答这个问题，但我的答案对于评论来说太长了，所以我将在本文中进行解答。

这是一个很好的问题。在基于 OSGi 的应用程序与传统的基于 JEE EAR 的应用程序之间，您将看到的最大区别是模块化得到了改进。因此，问题变成了，这种改进的模块化是否会给我带来任何好处，如果是，它们是什么？这本书“设计规则，模块化的力量”对这个问题进行了非常全面的探讨。这是一个很好的背景，但我有一种感觉，Michael 可能正在寻找比这本书中更不那么理论化的东西！让我们将模块化的好处分为两类：您应该在开发期间体验到的好处，以及您应该在运行时体验到的好处。

开发期间的好处。

• 严格执行模块边界（开发和运行时）
OSGi 拥有机制来确保开发团队尊重模块边界。使用 OSGi，模块导出的类型被明确声明（如果未导出，则不可见），并且模块的依赖项也被明确声明（这可能包括版本范围兼容性信息）。这意味着在使用开发工具时，团队无法通过代码补全违反模块边界，并且在运行时，OSGi 服务平台将阻止一个模块查看另一个模块的私有内部。因此，您的应用程序架构在开发周期中保持干净和受保护，而不是通过（通常是无意的）不必要的耦合而逐渐崩溃。
• 用于管理模块之间服务依赖关系的真正有效的面向服务架构。
模块之间的依赖关系当然不限于类型 - 模块还需要为其他模块提供服务（例如 Spring bean），并且可能依赖于其他模块提供的服务（再次例如 Spring bean）。不要将您的应用程序视为一个大型应用程序上下文，而应将其视为通过本地服务注册表交互的一组对等上下文。Spring bean（组件）对模块是私有的，除非显式导出。模块之间的 Bean 引用由运行时管理。这再次意味着开发人员可以自由地对模块进行任何他们喜欢的内部更改，只要外部契约（发布的 bean、导出的类型）保持不变即可。使用 Spring Dynamic Modules 时，模块的导入和导出类型以及导入和导出服务都是声明式指定的（前者在 OSGi 清单中，后者在 Spring 配置文件中）。
• 更好地根据您的意愿构建开发团队的能力
“组织服从架构”。很容易指派一个团队来处理某个模块或多个模块。要求一个团队实现跨越多个模块的功能则要困难得多。因此，自然会发生的是，您的技术架构（您如何将系统划分为模块）决定了您的组织结构——即您能够多有效地将工作分配给团队和个人。应用程序模块化的灵活性越大，构建团队的灵活性就越大。有时您会看到相反的情况：“架构服从组织”。当有一组协同工作的个人组成一个分布式团队时，这种情况往往会发生。为了进行合理的作业分配，如果您能够做到，则需要将模块与位置对齐。因此，如果您无法移动人员，那么在一定程度上，您的架构将由您的组织决定。模块分解的灵活性越大，找到适合您的解决方案的机会就越大。
• 更快的基于团队的开发
当模块具有清晰的边界——明确定义的外部接口、明确指定的依赖项和受保护的内部结构时，在这些模块上工作的团队更容易并行开发，而不会意外地踩到彼此的脚趾。明确指定的交互更容易存根和模拟，也更容易集成。这应该会带来更高效的团队和更快的开发周期。
• 更快的测试周期
当您在容器内进行测试时，Eclipse 的 SpringSource Application Platform 开发工具利用了 OSGi Service Platform 在运行系统中动态更新给定模块的能力。与您的项目关联的增量构建器会在您进行任何更改时自动更新正在运行的平台实例中的模块。这可以是任何更改——代码或其他。因此，例如，如果您正在 Web 层工作，持续与您的 Web 应用程序交互并进行测试，则 Web 模块将在每次更改时刷新——您无需每次都等待持久层重新初始化。Spring Dynamic Modules 提供的服务引用之间的智能管理可确保在刷新后修复所有模块间链接。这种开发体验非常令人上瘾：我已经警告过您了！
• 支持作为依赖项管理一部分的版本控制
当模块指定其依赖项时，它可以为与其兼容的依赖项版本提供一个版本范围（可以限制为单个版本）。OSGi 允许在运行时同时存在多个 Java 包的版本。这允许以下场景：在模块 A 上工作的团队需要版本 x 的某个库，而在模块 B 上工作的团队需要版本 y 的某个库（并且 x 和 y 不兼容）。只要模块 A 和 B 从未需要在它们之间交换该库的类型，这将毫无困难地工作。如果模块 A 和 B确实需要在它们之间交换类型，那么 OSGi Service Platform 将在部署时而不是在运行时检测到这种潜在冲突（假设两个模块的清单已正确生成）。
• 更少的障碍
与我的其他观点（与 OSGi 一般相关）不同，这一点特别针对 SpringSource Application Platform。我们相信，如果您开始在 SpringSource Application Platform 上开发基于 Spring 和 OSGi 的企业应用程序，与您尝试直接开发到 OSGi Service Platform（即使编程和部署模型相同）相比，您会在企业库在 OSGi 下无法按预期工作方面遇到更少的障碍。

运行时的好处

运行时的好处源于 OSGi 中的模块不仅仅是开发时构造。它们在运行时非常存在，具有自己的生命周期，并且可以在运行系统中进行检查。

• 有关已安装模块及其连接的完整信息在运行时可用——这是操作团队以前从未有过的洞察力水平。
您可以列出所有已安装的捆绑包及其版本，查看它们正在导出和导入的包，以及查看它们正在导出和导入的服务（以及提供这些服务和包的捆绑包的标识）。以前，操作团队对运行应用程序的了解仅限于 JEE 部署单元级别，而 OSGi 改变了这一切。（顺便说一句，SpringSource Application Management Suite 提供了更多见解，但那是另一个话题）。
• 隔离更改
由于可以独立安装、卸载、更新和刷新模块，因此您可以通过将更改范围缩小到较小的单元（捆绑包）来降低对生产应用程序进行更改的风险。应用程序的其余部分（其他捆绑包）可以保持不变。是的，您可能确实有一个漫长的变更控制流程，这意味着在实际中进行更改的速度并没有更快，但至少您现在可以更有把握地进行更改，因为您没有引入任何其他意外差异。
• 共享依赖项
OSGi 对版本控制的支持使得在平台中一次安装企业库的受信任版本，然后在应用程序之间共享它们变得切实可行。
• 仅使用您需要的服务器功能
由于服务器平台本身以模块化方式构建在 OSGi 之上，因此您可以配置平台以仅包含支持当前在其上运行的应用程序或应用程序所需的服务。

与 OSGi 无关的好处

如果您根本不在乎 OSGi 呢？那么 SpringSource Application Platform 会带来任何好处吗？

是的，会的。

我喜欢这样看待 SpringSource Application Platform

首先，它是一个服务器。一个轻量级可配置的服务器，专注于可服务性（请参阅 Rob 关于该平台的原始文章）。它具有有用的功能，例如每个应用程序分开的跟踪和日志文件、死锁检测、故障检测和转储处理、智能线程池和工作窃取等。由于这些原因，它是部署 Web 应用程序的好地方。

其次，它是一个理解基于 Spring 的应用程序的服务器。Spring 已集成到开箱即用，部署程序可以简化基于 Spring 的应用程序的打包和部署过程 - 例如，无需使用样板 web.xml 文件来配置 Spring 的 DispatcherServlet。

第三，并且仅此而已，它支持针对最终用户应用程序的 OSGi，从而带来我上面已经概述的优势。