初探Java企业级开源框架OSGi

    第一次接触OSGi 是2006年看见的一则网上新闻，该新闻中提到BMW 汽车的通信-娱乐(infotainment)系统采用了OSGi 架构，这套系统主要用来控制汽车上的音箱、灯光、导航和通讯等设备，整个系统由1000多个模块组成，启动时间却只需要3.5秒钟，这对于一个基于Java 的框架来讲，具有两个重大意义：一、说明了Java 执行效率并不差；二、OSGi 框架的性能尤其优秀。因此笔者对OSGi 框架产生了极大的兴趣，后来终于在一个项目中负责研究和开发基于OSGi 框架的应用程序，从此对它便情有独钟。令人欣慰的是，OSGi 在2007年取得了诸多战果：BEA 公司、Eclipse 基金会和Interface21 公司相继加入OSGi 联盟；在EclipseCon 2007大会上引起了业界的广泛关注，其中以Spring-OSGi、Web Service 与OSGi 等技术最为引人注目，这也标志着OSGi 将在未来与企业应用紧密结合；OSGi R4 标准发布，相关内容被成功的写入JSR 291 规范中；Spring 2.5 框架的发布，宣称其所有jar 包都兼容OSGi 标准；虽然OSGi 没能成功进入JavaEE 6 草拟计划中，但是Sun 公司宣称会在下一代Java EE 标准中重点考虑OSGi。因此笔者个人认为，在不久的将来OSGi 势必会在企业应用中发挥出强大的作用，基于OSGi 框架的产品也将层出不穷。本文从OSGi 的历史背景、OSGi 的特点、OSGi 开源框架介绍、OSGi 开发环境部署、OSGi 版的Hello World 五个部分对OSGi 框架进行概要的介绍，希望读者能从中有所收获。

    OSGi 的历史背景

    什么是OSGi 呢？OSGi——Open Service Gateway Initiative 字面上的意思是一个公共的服务平台。1999年OSGi 联盟成立，它是一个非盈利的国际组织，旨在建立一个开放的服务规范，为通过网络向设备提供服务建立开放的标准，是开放业务网关的发起者。OSGi 联盟的初始目标是构建一个在广域网和局域网或设备上展开业务的基础平台。历史总是具有惊人的相似性，正如Java 诞生于一个嵌入式开发的项目中，却被应用于网络平台的开发，对OSGi 的最早设计也是针对嵌入式应用的，诸如机顶盒、服务网关、手机、汽车等都是其应用的主要环境。后来，由于OSGi 的诸多优秀特性（可动态改变系统行为，热插拔的插件体系结构，高可复用性，高效性等等），它被应用于许多PC 上的应用开发，因此逐步为开发者所知和钟爱。现在人们对OSGi 的理解已经远远不是它字面和初衷所能解释的了，笔者认为称其为一个轻巧的、松耦合的、面向服务的应用程序开发框架更为确切一些。

    OSGi 真正被大家所知还是和Eclipse 有密切关系的。Eclipse 很多年都是Java 开发者的首选IDE，相信只要是一个Java 开发者，应该没有人不知道Eclipse 的。在Eclipse 3.0 以前的版本中，它本身有一套自身的插件体系，而该插件体系的设计非常精巧细致，受到许多开发者的推崇，但是Eclipse 基金在Eclipse 3.0 发布的时候，做出了一个大胆的行为，就是将Eclipse 逐步迁移到OSGi 框架中，并自己实现了一个OSGi 开源框架，取名为Equinox，该框架随着每次Eclipse 的发布也会相应的更新。Eclipse 之所以这么做，其一是因为Eclipse 的插件体系与OSGi 的设计思想不谋而合，其二也是因为OSGi 更为规范，其对插件体系的定义也更为完整一些。事实证明Eclipse 在采用OSGi 架构后，无论从性能、可扩展性这两个方面来讲还是从二次开发的角度来定义，都取得巨大的成功。下图展示了Eclipse 与OSGi 框架的关系。

    OSGi 的特点

    在介绍OSGi 框架的特点之前，先简单的介绍一下OSGi 框架的各个部分，如下图所示。

    解释一下上图中每一层的含义，其中OS 层和JVM 层可以不用详细介绍了，重点需要关注的是应用程序Bundles 层。框架本身提供的类加载，生命周期管理，服务注册和规范服务也都是针对Bundles 的。每一个在OSGi 框架中运行的逻辑单元称为一个Bundle，Bundle 实际是一个符合特定形式的jar 文件。每一个Bundle 的功能可以是抽象的也可以是具体的。所谓抽象，就是它不是一个具体的应用，没有完成一些业务功能，而只暴露了一些接口或者功能给其他的Bundle 使用；所谓具体，就是该Bundle 可以独立的完成一个功能，例如连接数据库，获取数据等等。Bundle 有六种状态，分别是：installed（安装完成，本地资源成功加载），resolved（依赖关系满足，即该Bundle 要么是准备好运行了，要么是已经被停止了），starting（Bundle 正在被启动），stopping（Bundle 正在被停止），active（Bundle 被激活，正在运行中），uninstalled（Bundle 被卸载了）。OSGi 有它自身的类加载机制从而控制这些加载的Bundles 彼此之间的依赖关系，而生命周期管理也是OSGi 的一大亮点，由于可动态的对这些加载的Bundles 进行安装、卸载、启动、停止等操作，所以可以动态的改变应用程序的运行状态。当一系列的Bundles 存在于服务器中的时候，那么它们之间必然会存在通信协作的部分，比如说一个通过网页捕获用户输入的Bundle 执行的时候，它必须首先需要一个Web 服务器服务的支持，那么这个时候服务注册器就会从整个OSGi容器中寻找这个服务，如果能完成服务的匹配，那么相应的功能就会很自然的实现了。OSGi 规范还规定了一组预设的服务，包括日志、服务管理等等，这些服务在主流的开源框架中都有实现。OSGi 框架中还包括一个安全层，OSGi 的安全层扩展了Java 的安全机制，增并加了一些新的约束以填补了Java安全机制中的遗漏。

[1] [2] [3] 下一页