开源文档《OSGi 进阶》发布暨作者访谈录

OSGi 正在变得炙手可热，无论是 OSGi 与 JSR 277 之争，还是 Struts2 开始使用 OSGi 来完成插件的热部署，都使它越来越频繁地进入开发人员的视线。而近日， Bluedavy 在去年发布了名为《 OSGi 实战》的开源文档后，又发布了此系列的第二篇：《 OSGi 进阶》。InfoQ 中文站就这次发布邀请 Bluedavy 对文档的写作背景、OSGi 的设计理念及当前的应用现状进行了访谈。

在谈到编写第二篇开源文档《 OSGi 进阶》的原因时，Bluedavy 说道：

《OSGi 实战》主要是为了向大家介绍 OSGi 的好处，以及 OSGi 到底是什么，具体怎么去用，目的是为了能吸引更多的人关注 OSGi、了解认识 OSGi； 《OSGi 进阶》则是为了和大家分享基于 OSGi 设计实际的项目 / 产品、集成流行的 Java 框架去实现 B/S、分布式系统、如何将传统的系统重构为基于 OSGi 的系 统等方面的一些经验，希望能让更多的人将 OSGi 应用到实际的项目 / 产品中去。 第一篇 OSGi 实战 Opendoc 发布后，应该说还是起到了一定的效果的，无论是从 javaeye 上的 OSGi 圈子、我个人的 blog 以及我个人的 MSN 上，都有不少的朋友开始讨论 OSGi，尝试 OSGi 应用到实际的项目的可能性，从我 MSN 上一些好友我也了解到，国内已经有些公司开始在商业的产品中应用 OSGi 了。

但是看到那么多的朋友对 OSGi 非常有兴趣，但由于不知道基于 OSGi 怎么去设计实际的项目 / 产品，又或是因为 OSGi 与流行 Java 框架不好集成的原 因，最终放弃了在实际的项目 / 产品中使用 OSGi，这也是促成我编写第二篇 Opendoc 的原因之一，我希望能将大家对于 OSGi 的兴趣转化为真实的使 用；另一方面的原因则是整个业界发展的大趋势，短短的一年间，各大公司、开源项目都公开支持 OSGi，使得 OSGi 进入企业应用领域的步伐比想像中顺利了 很多。

我们知道，模块化的开发方式早已在企业开发中得到了广泛应用，也一直是系统设计时的基本准则。而在 OSGi 中，每一个模块都 对应于自己的单个 bundle，以声明的形式来表示对其他 bundle 中 package 的依赖，或是暴露某些接口以供其他 bundle 调用，从而实现了物 理上的模块隔离。这种方式与传统的模块开发相比其优点在哪里呢？Bluedavy 回答说：

由于 Java 一直以来在物理隔离式的模块化开发 / 部署上都支持的不好，以至于基于 Java 构建的系统都没有做到真正的模块化。在模块化不是物理隔离方式实现的情况下，非常容易出现的现象是模块之间的界限在不知不觉中抹去了，最后整个系统的依赖关系会逐步变的复杂。 一个比较典型的例子：假设在一个留言板系统中，留言列表和新增留言划分为了两个模块，这两个模块是没有强耦合的，但在非物理隔离的模块化实现时，我们很容 易出现的做法就是在留言列表的页面上直接编写一个新增留言的功能链接，其实这也就隐藏式的将这两个模块强耦合在一起了。到了物理隔离的模块化实现时，就会 开始考虑这个问题。

这点就像 Bea microServices 的人的一句话：“Until modularity is not enforced,it is not there”。

在《 OSGi 实战》一书中，Bluedavy 曾经描述过，像 OSGi 这样一个为动态扩充、修改系统功能提供了支持的模块系统可以带来什么样的好处：- 基于 OSGI 的系统，可通过安装新的 Bundle、更新或停止现有的 Bundle 来实现系统功能的插拔。

• OSGi 有一整套完整的机制去实现动态改变系统行为。

• 基于 OSGi 的系统不会受到运行在其中的 Bundle 的影响，不会因为 Bundle 的崩溃而导致整个系统的崩溃。

• 只有在请求发生时 OSGi 才去完全加载、启动相应的 Bundle、Service，保证了系统的高效

• 规范的、可积累的模块

但是，无论是技术框架的选型，还是架构方案的选择，都不可能只看到其优势所在就简单的做出定论。每一种选择，都需要考虑到是否与既有方案可以顺利结合，应 用环境是否足够成熟，有充分的外界条件支持等等。那么对于 OSGi 来说又是什么样子的呢？Bluedavy 给出了自己的答复：

从应用的架构层面选择的话，OSGi 足够成熟，理由在于目前企业应用领域的关键问题，在 OSGi 中都逐步的有了对应的解决方案，这些解决方案中最有影响力 的当属 Spring 和 OSGi 的结合，Spring-OSGi 使得 OSGi 的应用很容易的获得 Spring 提供的企业应用需求功能的实现的支持。 目前用 OSGi 来做企业应用，应该说技术上的瓶颈已经不多了，只是怎么去充分的发挥 OSGi 的优势，是有一定的挑战的。

记者又请 Bluedavy 就“企业应用的关键问题”和“OSGi 中对应的解决方案”做出更详尽的解释，他说道： > OSGi EEG 小组在总结 OSGi 进入企业应用领域需要解决的问题上列出了这么几点：

• 分布式系统的支持； 在分布式系统上，目前 SCA 是个好的解决方案，SCA 的实现有 Newton 和 Tuscany，另外就是通过集成 Axis 来通过 webservice 实现分布式的通讯。

• OSGi 服务的扩展，以支持从外部发布 / 调用 OSGi 服务，同时需要考虑多种语言的支持，而非仅仅是 Java； 这点呢，一方面就得依靠和 Java 流行框架的集成，像 Spring-OSGi 就实现了在 Spring 的 bean 中调用 OSGi 服务，另一方面就得依靠 SCA 了。

至于我们这些程序员在实际的项目 / 产品中可能会碰到的企业应用开发的问题可能会有下面几个：

• 怎么样把 OSGi 和 Webwork+Spring+Hibernate 这样的架构集成起来。类似 Webwork+Spring+Hibernate 这样的 架构无疑是目前 Java B/S 应用领域最为流行的技术组合拳，而且这样的三者的结合确实基本上解决了企业应用领域的关键需求，例如分布式的调用、事务机制等，如果 OSGi 能和这 样的技术组合拳集成，自然也就使得 OSGi 应用能够应对企业应用领域的需求了，在 OSGi 进阶的 Opendoc 中详细的介绍了 OSGi 与这个技术组合拳的 集成方法，并诞生了一个 OSGi+Hibernate+Spring+Webwork 的脚手架以及基于此脚手架的留言板系统。

• 传统的系统能不能重构为 OSGi 系统。无论对于项目还是产品而言，如果需要将新的项目 / 产品改变为基于 OSGi 的项目 / 产品，那么就有一个问题就是如何将 在以前项目 / 产品中积累的东西重构为可部署至 OSGi 系统，这相信也是大部分关注的问题，这个问题在 OSGi 进阶 Opendoc 中也以一个实际的例子来进 行了讲解。

• 既然使用了 OSGi，如果发挥不出它的优势的话，就毫无意义了。OSGi 系统的典型特征是：模块化、动态化和可扩展。要做到这三点从设计 / 实现层面都要进 行把握，在 OSGi 进阶 Opendoc 中也从实际项目 / 产品的角度去介绍了如何去设计、如何去实现，同时也总结了一些 OSGi 的设计模式和最佳实践，使得 大家在应用 OSGi 实现实际的项目 / 产品时充分的发挥 OSGi 的优势。

在自己的实际应用中，Bluedavy 也碰到过一些比较棘手的问题，其中包括：某些 Java 框架依然需要开发人员自己来实现集成；目前 OSGi HttpService 尚不支持 *.action 这样的通配方式的 servlet mapping，对于 filter 也不支持等等。但是最主要的问题还是落在了如何去构建模块化、动态化和可扩展的系统上面。正因为它的重要性，在 《OSGi 进阶》一书中，Bluedavy 用了整整两章的篇幅来论述 OSGi 的设计模式和最佳实践。也许随着 OSGi 的广泛应用，开发人员对于系统设计的认识，也会 提高到一个新的层次。 在访谈的最后，Bluedavy 对 OSGi 目前的应用现状做了总结：

OSGi 在过去的一年中得到了众多企业应用软件领域的商业公司的支持，例如 IBM、BEA、Oracle、SAP、IONA，这些公司都在自己的商业产品 中开始采用 OSGi；而开源领域的则有像 Spring、Struts 2、Newton 这些的加入。无疑 OSGi 将成为企业应用软件领域的重要内容，在此希望国内的同仁们也能更多的来关注 OSGi，并将 OSGi 应用到实际的 项目 / 产品中去。

此外，记者还了解到，OGSi 的官方中文站点（osgi.org.cn）正在筹备建设中，不日即将上线；同时，OSGi 中国 User Group 也获得了 OSGi 联盟授权，成为继日本 User Group、韩国 User Group、法国 User Group 以及西班牙 User Group 后的第五个官方认可的 User Group，负责中国范围内 OSGi 的宣传和推广。可以预见，在不久的将来，OSGi 在国内一定会迎来更加广阔的应用前景。 请继续关注 InfoQ 中文站，我们会为您带来更多关于 OSGi 的精彩报道。