作者
林昊
发布于
2009年10月16日 上午5时47分
- 社区
- Architecture,
- Java
- 主题
- 开放源代码,
- 应用服务器,
- 平台,
- 企业架构
- 标签
- OSGi,
- 图书
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中文站。
点击这里：
免费下载这本书（PDF）
免费下载这本书（PDF）
。
迷你书目录
《OSGi原理与最佳实践》原书详细信息
前言
目录
第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和自动构建。