OpenDoc Series':OSGI实战(序)

本篇 Opendoc 按照学习开源框架的基本流程进行编写,从体验 OSGI 到基于 OSGI 框架的实战,到深入 OSGI,完成对于 OSGI 从入门到深入学习的过程,后对于 OSGI 的现状和发展发表些自己的看法和思考,限于笔者的水平以及时间,文内难免有些错误,还请大家不吝指正,也希望本文能作为国内 OSGI 的抛砖之作,引出更多的关于 OSGI 的 Opendoc,在我的 blog 上也会不断的编写关于自己在 OSGI、Equinox 上的实战的体会和心得,欢迎大家多多交流。


OpenDoc Series':OSGI实战(二)

以一个用户登录验证模块来体验下OSGI有什么不同的地方! 例如用户登录验证模块。要求可动态的替换(系统运行期)用户登录验证的方式,如目前需要的有三种验证方式:LDAP 验证、DB 验证以及配置文件验证;同时要求可随时增加新的验证方式(系统运行期),如 CA 验证方式等。 这是常见的一种较为简单的动态修改和改变系统行为的需求,分别来看看传统的实现方式和基于 OSGI 的实现方式。


OpenDoc Series':OSGI实战(三)

在上一个章节中,从需求实现和技术角度分别体验了 OSGI,对于基于 OSGI 搭建的系统和传统的系统有什么不同有了个大概的印象,那么到底 OSGI 给我们带来了什么呢? 从需求实现方面,OSGI 为动态扩充、修改系统功能和改变系统行为提供了支撑,而在传统的开发方式下,要实现系统的动态扩充、修改以及改变是一件很麻烦的事。 从技术角度方面...


OpenDoc Series':OSGI实战(四)

OSGI 案例:说了这么多 OSGI 的好,吹了这么多的”牛”,来以事实证明下 OSGI 并不是什么实验品,而是已经在业界被证明切实可用的东西。 OSGI 典型的应用案例主要有两个,都非常的著名,分别是 Eclipse 和 BMW 汽车的应用控制系统。


OpenDoc Series':OSGI实战(五)

在开源界中实现 OSGI 的框架比较知名的有:Equinox、Knopflerfish、Oscar。


OpenDoc Series':OSGI实战(六):1

讲了这么多 OSGI 的相关”废话”,开始走入正题,任何东西,仅仅说是没用的,在本章节中我们基于 OSGI 框架(Equinox)来实现体验 OSGI 章节中的用户登录验证模块。OSGI 框架是一个微核结构的容器,所有的模块都需要运行在容器范围内,在 OSGI 中所有模块的部署都必须以 Bundle 的方式来进行部署,那么到底什么是 Bundle 呢?


OpenDoc Series':OSGI实战(六):2

从开发角度来看,Service 有点象虚拟的概念,因为在编写 Service 时和编写普通的 Java 类(POJO)没有任何的区别,其实在上面已经写过三个 Service 类了,分别是LDAPValidatorImpl、DBValidatorImpl 以及 ConfigFileValidatorImpl。 在 OSGI 框架中,Service 是个实际的概念,只有通过 BundleContext 注册成 Service 才能使得一个 POJO 作为 Service 在 OSGI 框架中被使用,同时也只有通过 BundleContext 来获取发布到框架中的 Service,通过 Service 的方式来实现 Bundle 之间实例级的依赖, 和 Import-Package、Require-Bundle 不同的地方在于通过 Service 获取的是其他 Bundle 中类的实例。


OpenDoc Series':OSGI实战(六):3

对于测试的支持无疑是现在对于框架的重要考评点,那么来看看基于 OSGI 框架的系统怎么做测试呢,由于做集成测试的方法只和系统的结构(B/S、C/S)有关,和框架没什么关系,所以在这里只谈基于 OSGI 框架的系统是如何做单元测试的。 编写单元测试时重要的就两点: 1. 设置测试类的依赖(通过 Mock、实例化等方法); 2. 测试在某种输入的情况下方法执行的输出是否和预期的结果一致。


OpenDoc Series':OSGI实战(七):1

经过对 OSGI 框架使用的学习,相信大家对于 OSGI 中的概念有了或多或少的理解,同时也会在使用的过程中产生各种各样的疑问,在这个章节中将深入学习 OSGI 框架背后的思想,学习 OSGI 规范中是怎么定义 Bundle 的元数据的、怎么来管理 Bundle 的、怎么来管理 Service 的等等,以在实践中更好的使用 OSGI 框架搭建系统,同时通过对于 OSGI 的学习,不断的改善和提升之前在实战章节中的用户登录验证模块,以使其更加的贴合实际的应用。


OpenDoc Series':OSGI实战(七):2

StartLevel Service 是 OSGI 规范中的核心服务,是 OSGI 框架必须实现的服务,通过 StartLevel Service 可以动态的设置和改变 Bundle 的启动顺序,OSGI 框架在启动 Bundle 时按照启动顺序和 Bundle ID 的倒序来启动系统。 在 OSGI 中,启动顺序称为 StartLevel,在之前的实战章节中,没有去控制 Bundle 的启动顺序,通过 config.ini 可以静态的设置系统的启动级别和各 Bundle 的启动级别,而通过在运行期获取 StartLevelService 则可动态的改变系统、各 Bundle 的启动级别以及新安装的 Bundle 的启动级别。


OpenDoc Series':OSGI实战(七):3

规范描述: Configuration Admin Service 是 OSGI 中非常重要的一个服务,它用于动态的管理 Bundle 的配置的属性,而这些属性的存储可能是在本地、也有可能是在远端、甚 至可能会在某些设备上,基于 Configuration Admin Service 就可以统一的、动态的、远程的完成 Bundle 配置属性的管理工作了。 规范中的这张图挺形象的解释了 Configuration Admin Service 的作用。


OpenDoc Series':OSGI实战(八)

之前的章节中对于 OSGI 的应用都只是让大家对于 OSGI 的实战有个较为实际的概念,并没有在整个系统级别去应用 OSGI,要在整个系统级别上应用 OSGI,还是会带来不少的挑战的,但相对于 OSGI 能带来的优势,相信这是值得的,在应用 OSGI 时应大程度的发挥基于 OSGI 搭建系统的优势以及减少基于 OSGI 系统带来的挑战。 由于基于 OSGI 搭建系统带来的是架构级别的改变,带来的大的影响莫过于设计层面,同时对于系统开发和部署也产生了影响。