OSGi 在 Java 业界正是风生水起。几乎所有的 JEE Server，比如 IBM Websphere、Oracle Weblogic 和 Sun glassfish，都采用了 OSGi 作为基础平台，甚至推崇实用主义的 SpringSource 也挟 Spring DM 之势，推出了基于 OSGi 的应用服务器——Spring DM Server。山雨欲来风满楼，乘着这股东风，在 BlueDavy 发布了《OSGi 实战》以及《OSGi 进阶》之后，国内第一本 OSGi 的专业书—— 《OSGi 原理与最佳实践》刚刚面世。InfoQ 中文站精选了其中的两章，特做成迷你书，供各位读者免费下载。
免费下载迷你书
如果你喜欢本书，请通过购买原版《OSGi 原理与最佳实践》支持出版商和InfoQ 中文站。
点击这里：[DOWNLOAD]。
迷你书目录
前言
目录
第 1 章 OSGi 框架简介
1.1 Equinox
1.1.1 简介
1.1.2 环境搭建
1.1.3 HelloWorld
1.1.4 开发传统类型的应用
1.1.5 从外部启动 Equinox
1.2 Felix
1.2.1 简介
1.2.2 环境搭建
1.2.3 应用部署
1.2.4 在 Eclipse 中调试 Felix
1.3 SpringDM
1.3.1 简介
1.3.2 环境搭建
1.3.3 HelloWorld
1.3.4 Web 版 HelloWorld
第 2 章 基于 SpringDM 实现 Petstore
2.1 即插即用的 Petstore
2.2 新一代 Petstore 的实现
2.2.1 环境准备
2.2.2 Utils 模块
2.2.3 Bootstrap 模块
2.2.4 ProductDal 模块
2.2.5 ShoppingCartDal 模块
2.2.6 ProductList 模块
2.2.7 ShoppingCast 模块
2.2.8 ProductManagement 模块
2.3 部署
2.4 Petstore 的扩展
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 版本 Declarative Service 的实现；除了对 DS 的改进外，在 Core 部分也可以看到提出了 Framework Lunch 这样的新规范部分，这对于按照标准使用 OSGi 和嵌入 OSGi 至其他容器提供了很大的帮助。除了以上这些外，还有其他很多的改进，在《OSGi 原理与最佳实践》一书中对 OSGi R4.2 的公众草稿版做了更多详细的分析。
但由于公布的公众草稿版本并不涉及企业应用领域，也就是 EEG 小组的工作，因此尽管大家期待的 RFC 119: Distributed OSGi 以及 RFC 66: OSGi web container 出现在了 Early Draft 中，但并没有出现在公众草稿版中，这两个最受大家关注的规范内容应该会被列入 EEG 出版的规范中。
对于社区这一块，OSGi 尽管已经发展这么多年了，到目前为止确实仍然没有非常成熟的社区，但其相关的 maillist，例如 equinox maillist、OSGi-Dev maillist 以及 Spring-DM maillist 都相当的活跃，业界的 OSGi 的使用者们根据自己的经验提出了不少 OSGi 的最佳实践，其中 Bea 的最佳实践总结以及 Peter 和 BJ Hargrave 在 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 和自动构建。
评论