用 OSGi 完成应用的模块化——BPS 的设计选择

OSGi 是一个基于 Java 的服务平台规范，它是为那些需要长时间运行，动态更新并且对运行环境的影响尽可能小的系统制定的。迄今为止，很多工具厂商（Eclipse 是第一个）和应用服务器厂商（IBM、BEA、Oracle）都已经采用了 OSGi 来创建“微核与插件”的架构，这样一来，应用就可以被更好的模块化，并且可以在运行时动态装配。但是对于开发者而言，OSGi 更重要的特点则是：在开发应用时，它将成为更加优秀的组件模型。 JSR 291（OSGi 核心规范 R4.1）在经过多方争论后得出：

…为既有的 Java SE 平台定义了动态的组件框架，其中包括了组件的生命周期。这个动态的组件模型将会支持由组件组装应用和在组件之间隐藏实现细节，同时还会提供组件的生命周期管理功能。

当我们在 Java 的世界中使用组件开发时，OSGi 会成为我们的备选工具之一吗？有一家公司已经决定用 OSGi 来构建下个版本的产品架构，InfoQ 就这个话题，与该公司进行了交流。 BPS 是一家销售风险管理软件的 ISV ，该公司的产品可以帮助公司服从内部审计并遵守业务流程（例如，Sarbanes-Oxley 404 法案）。在那些规章制度以及对 IT 环境的要求都十分严苛的大型金融机构中，他们的产品已经成了主流。InfoQ 对 BPS 的首席架构师 Gavin Terrill 做了一次访问，在访问中 Gavin 谈到：

我们目前一直力求解决的问题是：怎样才能在一个 VM 里面，同时运行一个服务的多个版本。比如说，现在有两个应用程序，A 和 B，它们都与在我们的程序 C 集成。在 C 被部署以后，又增加了不少特性，用来支持 A 的下一个版本。那么我们该如何在不重启服务器，不更改任何 B 所依赖的功能的前提下，用新的代码来更新已部署的应用呢？而 OSGi 可以动态地提供组件（bundle），并为组件标记版本号，这样一来我们的问题就迎刃而解了。 我们的另一个目标是在代码库中引入面向服务（service oriented）的方式。注意这里的 S 和 O 都是小写的——我们希望系统可以做到松耦合，将概念和本地化测试分离，但是我们并不想用跨进程（out-of -process）的方式来实现，因为这样只会增加更多的复杂性，就像 Jini 和 DPWS（先前的 UPnP）一样。我们在产品中已经融入了这些想法，充分利用了 Java 中的接口，并利用 Spring 框架的依赖注入对这些接口做了相应实现。而 OSGi 则在这个基础上又有所提升，它以轻量级的方式把服务变得更加模块化。

就 OSGi 为什么比传统的 EAR/WAR 文件更好的话题，Gavin 说：

虽然现在已有的机制本身并没有什么问题，但我认为对于实际应用而言，EAR/WAR 的粒度显得太大了。如果我只需要改变一个 jar 文件，为什么我需要重启整个应用呢？ 关于如何部署 Java 应用的话题，已经在 Java 社区中引发了大量的讨论，从 jar 文件的引入直到 JSR 277/294——“Java 模块系统（Java Module System）”（JSR 277）是 Java SE 7 的先行者，有趣的是，它第一眼看上去很像是从.Net 的 Assembly 思想中成型的——然而， OSGi 在 Eclipse 及其他应用中取得的成功给我们树立了信心。如果一样东西已经经过了重重考验，并且解决了我们曾碰到过的那些乱七八糟的部署问题，那还有什么好争的呢？

OSGi 的设计主旨与我们的需求很贴近：一个轻量级的进程内（in-process）服务容器框架，并提供了完整生命周期管理。

因为 BPS 的应用是架构在 Spring 基础上的，所以他们打算在新的架构中使用 Spring-OSGi 。最近，Spring OSGi 刚刚发布了第一个 Milestone。

使用 OSGi 来重新架构对 BPS 来说是一次巨大的冒险。Gavin 回忆说：“记得 2004 年的时候，BPS 决定冒险对产品进行重构，当时看上去采用 Spring 框架比起使用传统的 EJB 来，风险要大得多。但最终从开发人员和用户的反馈来看，这次冒险为我们赢得了大量的时间。这次采用 OSGi 对我们来说也是如此，因为它毕竟还处于发展初期，但我相信，在多年以后当我们架构 IT friendly，面向服务的企业级 Java 应用时，OSGi 就会成为事实上的标准了。”

OSGi 可以作为一种架构资产，来推动各个组织应用面向组件的软件开发。InfoQ 在去年 11 月曾报道过 Piero Campanelli 的分析报告，他在报告中列出了 OSGi 的如下几个优点：

• 真正的组件开发——虽然组件开发概念很简单，但是真正开发组件化软件的时候，却是困难重重的。OSGi 的结构可以解决这些问题，例如依赖跟踪，版本跟踪和服务绑定。
• 跨团队的安全开发——OSGi 的微核结构保证了组件和扩展是独立且可控的。
• 公司项目的标准化管理——如果所有的项目都分解成 OSGi 组件，那么它们就可以很容易重用。 Eclipse repository 就是这样子的。
• 版本跟踪——人们常常会有这样的疑问，“我可以集成这个库吗？”，亦或“它会不会与这个版本的另外一个库冲突？”，OSGi 所提供的标记版本的功能，就解决了这些疑惑。
• 辅助架构设计——通过 OSGi，架构师无需进行完整的构建，就可以判断构建所依赖的类库是否依然可用。

InfoQ 一直在追踪报道 OSGi 的最新进展，请参见 InfoQ.com/OSGi （英文）和 InfoQ.com/cn/OSGi （中文）。

查看英文原文： OSGi for application modularity - one company’s design choice

译者简介：李剑，中国Eclipse 社区插件开发版版主，在JavaEye 拥有 RCP 专栏，北航软件工程硕士。现就职于 Ethos ，热衷于设计模式，敏捷软件开发的研究与实践。为 InfoQ 中文站贡献内容，请邮件至 china-editorial@infoq.com 。