BlueDavy《OSGi原理与最佳实践》采访

InfoQ中文站就这次出版邀请BlueDavy对OSGi的近况、在具体项目上应用OSGi应该注意的问题和解决方法，以及如何在OSGi开发过程中结合使用敏捷实践的问题进行了一番访谈。

InfoQ：自从你上一次发布<OSGi进阶>后，OSGi联盟最近有什么新进展？OSGi社区发展如何？

BlueDavy：OSGi联盟目前正在制定4.2的规范，并已发布公开草稿版本。在草稿版本中，我很欣慰的看到了OSGi联盟对 OSGi所做出的众多改进，包括了OSGi使用者们期待已久的对于Declarative Services的细节改进，并将其版本定为1.1，目前Equinox也已推出1.1版本DeclarativeService的实现；除了对DS的改进外，在Core部分也可以看到提出了Framework Lunch这样的新规范部分，这对于按照标准使用OSGi和嵌入OSGi至其他容器提供了很大的帮助。除了以上这些外，还有其他很多的改进，在《OSGi 原理与最佳实践》一书中对OSGi R4.2的公众草稿版做了更多详细的分析。

但由于公布的公众草稿版本并不涉及企业应用领域，也就是EEG小组的工作，因此尽管大家期待的RFC 119: Distributed OSGi以及RFC 66: OSGi webcontainer出现在了Early Draft中，但并没有出现在公众草稿版中，这两个最受大家关注的规范内容应该会被列入EEG出版的规范中。

对于社区这一块，OSGi尽管已经发展这么多年了，到目前为止确实仍然没有非常成熟的社区，但其相关的maillist，例如equinox maillist、OSGi-Dev maillist以及Spring-DM maillist都相当的活跃，业界的OSGi的使用者们根据自己的经验提出了不少OSGi的最佳实践，其中Bea的最佳实践总结以及Peter和BJHargrave在2007 JavaOne做的OSGi最佳实践总结给大家提供了很大的帮助。

InfoQ：相信很多人都想在真实项目中使用OSGi。请问如果要基于OSGi开发新系统时需要注意什么问题？如何设计系统的架构才能充分利用OSGi的好处？

BlueDavy：基于OSGi开发新系统时最值得注意的问题就是如何合理地划分模块的粒度，以及遵循OSGi框架的实现方式来构建真正的模块化、动态化的系统。

由于OSGi的强项在于模块化以及动态化，如果想在系统中充分发挥这两个优势，一方面是要让系统真正的模块化，把握好每个模块需要对外提供的功能，充分合理地使用OSGi提供的模块化交互的方式，例如import-package以及OSGi。

Service另一方面则是要让系统真正的动态化，这包括了基于OSGi框架支持的Bundle生命周期管理以及服务组件生命周期管理合理构建动态 化的模块，同时也需要合理处理动态化时所带来的影响，例如引用的服务的注销、对象状态的保留与恢复等。在《OSGi原理与最佳实践》一书中提供了一些构建 模块化和动态化系统的实践建议以及为什么要如此做的分析。

InfoQ：我们也看到在现实中存在着大量的遗留项目。那么，对于把传统的遗留系统改造成基于OSGi的架构，一般需要注意什么问题？

BlueDavy：突出的问题一般是模块ClassLoader隔离后带来的问题，对于OSGi的入门者来 说，ClassNotFoundException或者ClassCastException这类异常会成为常见的现象，这就要求使用者能够对ClassLoader以及OSGi模块隔离和交互这两方面的知识有充分的掌握，就如BEA的microServices的开发者们总结的一样：当你不使 用OSGi来构建模块化系统时，你根本就不知道什么是真正的模块化系统，他们在移植原有的BEA的产品到OSGi上时花了一年多的时间，这也意味着要将传 统系统改造为OSGi架构确实有不小的难度，无论是OSGi知识方面的学习还是设计思想方面的转变。

InfoQ：Oracle收购了Sun，这两家公司势必要在很多方面整合，比如双方对OSGi的态度。我们知道，虽然有很多JEE Server都选择架构在OSGi之上，但是Oracle Fushion 11G里面却没有采用OSGi，请问你认为Oracle收购Sun对OSGi会产生什么影响？

BlueDavy：从我2005年接触OSGi而言，对OSGi的前景一直非常的看好，也许在2005、2006年时OSGi的前景看似一片迷茫，但进入2008、2009后，无论从Java主流应用服务器都基于OSGi来看，还是从Java将从语言级提供对模块化的支持来 看，OSGi已经逐步的得到认可并成为事实性标准。

Oracle在很久之前就开始关注OSGi，并且Oracle也是OSGi联盟的成员之一，尽管Oracle Fushion 11G没有采用OSGi，但我认为这并不表示Oracle否定OSGi，或者不愿意采用OSGi，也许Oracle只是认为目前采用OSGi会对其原有积 累的技术产生不小的冲击，毕竟BEA为了移植到OSGi花了一年多的时间，从另外的角度来看，提供模块化的支持已经成为Java语言发展的必然，OSGi 是目前仅有的已投入实际商业产品使用的模块化规范，另一方面从OSGi对JSR277产生的影响来看，可见OSGi在Java模块化规范方面的领先地位， 因此也许不久后我们就能看到Oracle对OSGi的态度，相信很大概会是好消息。

InfoQ：应用系统开发引入OSGi之后，又如何应用TDD、自动构建等敏捷实践？

BlueDavy：OSGi Service为POJO方式，再加上OSGi和Spring一样支持方法方式的依赖注入，因此对于依赖关系不复杂的OSGi Service的TDD和自动构建没有问题。

对于依赖状况复杂的而言，在Spring中多数仍然会采用配置文件编写依赖注入关系，启动Spring容器，获取相应的bean进行测试的方式。在 这种情况下，目前OSGi容器的支持则不是很好，较Spring容器的单元测试而言复杂很多。一方面是由于OSGi采用的为Bundle部署机制，这就要 求在测试时将所有需要依赖的Bundle部署至OSGi容器中，在目前的情况下这需要通过编写程序来安装。这个状况等到OBR进入使用阶段后会好很多，原 因在于通 过OBR可以很容易的自动安装所需依赖的Bundle；另外一方面则是由于OSGi并不直接提供在外部获取OSGi Service的方法，就像Spring可以通过ApplicationContext来获取Bean。但是，也不是没有办法，如何在外部获取OSGi Service的方法在《OSGi原理与最佳实践》一书中有进行讲解。除了书中讲解的方法外，在OSGi R4.2中新提供的Framework launch也将有助于在OSGi容器外部获取OSGi Service。

鉴于上面的两个原因，在目前的情况下只能自行实现一个单元测试框架，OSGi China User Group最近会公布一个OSGi单元测试框架以方便大家对OSGi程序进行TDD和自动构建。