一、导言
OSGi(TM)规范为网络服务定义了一个标准的，面向组件的，计算环境。为网络设备（既包括嵌入式也包括服务器）添加OSGi服务平台功能后，就能够在任何位置获取控制这个网络设备上的软件组件的生命周期的能力。网络设备上的软件组件可以被任意的安装、更新或者删除而不影响该设备的运行。这些组件是一些能够动态发现和使用其他组件的类库或者应用程序，这些组件可以是商业组件通过购买获得，也可以是自行开发的。OSGi联盟为许多通用的功能如HTTP服务器、配置、日志、用户管理、XML等等开发了标准的组件接口。
软件组件架构引发了软件开发过程中日益突出的问题：软件产品存在大量的配置信息需要开发和维护。标准的OSGi组件架构大大的简化了这些配置步骤。
二、框架
OSGi规范的核心组件就是OSGi框架（OSGi Framework）。该框架为应用程序（称为“bundles”）提供了一个标准的环境。OSGi框架分为四层：
如图所示：
L0: 运行环境(Execution Environment )
L1: 模块（Modules ）
L2: 生命周期管理（Life Cycle Management ）
L3: 服务注册表（Service Registry ）
此外，存在一个安全系统与各个层面紧密结合。
L0：运行环境即为Java运行环境。Java2的框架如J2SE, CDC, CLDC, MIDP等都是合法的运行环境。OSGi基于基础框架和运行OSGi bundles所需的最小需求定义了标准的运行环境。
L1：模块层定义了类加载策略。OSGi框架是一个强大的并且严格定义的类加载模型，它建立在Java之上并添加了类加载模块化。在Java中，通常只有单一的类路径定义包含了所有的类和资源，OSGi模块层定义了模块内部的私有类路径和模块间可控制的路径连接。
L2：生命周期层控制能够动态安装、启动、停止、更新和卸载的bundles。Bundles依赖于模块层的类加载策略同时提供了在运行时环境中管理模块的API。生命周期层是动态建立的，通常不是应用程序的一部分。广泛的依赖机制确保了运行环境中的正确操作。
L3：服务注册表为bundles的动态特征提供了协作模型。Bundles之间可以使用传统的类共享机制实现协作，但是类共享机制对于动态安装和卸载的模块来说无法提供一致性，因此服务注册表为bundles之间共享对象提供了一致的模型。许多服务与服务器端对象相似，如Http服务器，其他的服务代表这真是世界中的一个对象，例如身边的蓝牙电话。
OSGi框架的安全建立在Java语言安全和Java2安全模型之上。Java语言的设计排除了许多可能的安全漏洞，例如病毒代码使用缓冲区溢出攻击将不再可能。Java语言中的访问描述符限定了代码对其他开发人员的可见性。OSGi框架通过允许Java标准机制中不可用的私有类扩展了这一模型。Java2安全模型为代码访问资源提供了全面的模型，OSGi框架支持完全的许可动态管理。
三、标准服务
在框架之上，OSGi联盟定义了许多服务，这些服务通过Java接口指定。Bundles可以实现这些接口并在注册表中作为服务注册，使用这些服务的客户组件可以在注册表中查找这些服务，并在这些服务可与或不可用时进行跟踪。
下面部分为OSGi发布版本3中的服务给出了一个简单的概括。
四、框架服务
OSGi框架提供了一个许可管理服务，一个包管理服务和一个启动级别服务。这些服务在规范中都处于可选实现部分，起着指挥框架运作的功能。
许可管理：现有或将来的bundles的操作许可通过该服务操纵，一旦这些操作许可被设定，这些许可将被立即激活。
包管理：Bundles之间可以共享包中的类和资源，bundles更新后系统需要重新计算bundles之间的依赖性。包管理服务提供了系统当前包共享的状态，同时也能够刷新共享的包，这意味着依赖关系将被打破并需要重新计算。
启动级别：启动级别表示一组bundles需要在其他bundles之前初始化或者启动。启动级别服务提供设定系统当前的启动级别，设定bundle的启动级别和查询当前设定的功能。
（待续）
附录：
原文链接 。
联系作者，不当之处，敬请批评指正。
本文地址：http://com.8s8s.com/it/it12792.htm