译自《OSGi R4规范》

Eclipse从3.0版本开始采用基于OSGi的插件体系结构。

××××××××××××××××××××××××
先简要介绍下OSGi框架

OSGi框架是OSGi服务平台规范的核心部分。该框架提供了一个大众化，安全，可管理的平台，可以支持可扩展可下载应用插件的部署，我们称这些应用插件为Bundle。

与OSGi兼容的设备可以下载和安装OSGi bundles，在不需要的时候还可以在运行时卸载它们。OSGi框架使用一种动态的，可协调的方式管理OSGi环境中bundles的安装和更新，为了完成这个任务，框架会管理bundles、services的依赖细节。

框架使得Bundle的开发者能够充分利用java平台的跨平台性和动态加载能力，这样，开发部署到大规模的嵌入式设备的服务将更加容易。

OSGi框架的功能模块主要划分为以下几个层面：
* 安全管理层面
* 模块层面
* 生命周期层面
* 服务层面
* 部署的服务

安全管理层面基于Java 2的安全机制，但另外添加了一些安全方面的限制，还扩充了Java安全方面的一些管理机制。

模块层面定义了一个基于Java的模块化模型，它更正了Java部署模型的一些缺陷，它在bundles之间的共享包（package）和隐藏包方面定义了严格的规则。模块层面可以在没有生命周期层面和服务层面的情况下使用，生命周期层面提供了一个管理模块层面中bundles的类库，而服务层面则提供一个bundles之间交互的模型。

生命周期层面提供了一个管理bundles生命周期的API。这个API定义了bundles的运行时模型，它定义了bundles是如何启动，停止，安装，更新和卸载的。而且它还提供了一个事件API，使得一个行使管理功能的Bundle能够控制服务层面的行为。生命周期层面依赖于模块层面，它不依赖于安全层面。

服务层面为Java Bundle开发者提供了动态，准确和一致的编程模型，通过解耦服务规范及其实现来简化服务Bundle的开发和部署。这个模型允许Bundle开发者只绑定到接口规范。如果要为了特定需要进行优化，或选择不同的厂商定制，就可以在运行时选择相应的实现来替换。

一致的编程模型使得开发者可以协调各个方面的实现问题 -- 这是很重要的，因为框架有可能要运行在不同的设备平台上，这些平台有着不同的硬件特性，这会影响到实现的诸多方面。但一致的接口可以保证各个组件能够重新被组装起来，构建出稳固的系统。

OSGi框架中，bundles可以在运行时通过服务注册表选择可用的实现。Bundles可以注册新的服务，接受服务的状态信息，查找已存在的服务来适应设备的当前能力。框架的这些机制使得已经部署的bundles能够继续更新和扩展：新的bundles可以被添加以扩充功能，运行中的bundles也可以在不重启系统的情况下被修改和更新。




版权所有 罗明