OSGi Compendium服务概览

服务概览

除了OSGi 核心标准(core specification)中的服务，OSGi联盟也定义了一组非核心的(non-core)标准服务，称为compendium服务。Core服务在任何运行的OSGi框架内都是可用的，这要求所有的OSGi框架都要实现核心服务。而compendium服务则不然。这些服务以分离的bundle的形式出现，由框架实施者或者第三方实现并提供，能在任何框架上运行。

名字	描述	包名
LOG	日志信息，警告，调试或者错误信息是通过这个日志服务来处理的。其中主要是由两个服务组成，一个是用日志记录前面提到的各种信息，另一个则是用来获取这些记录好的日志信息。	org.osgi.service.log
HTTP	通过HTTP服务注册servlet和资源	org.osgi.service.http
Device Access	OSGi为一个新的设备匹配一个驱动，并自动下载一个实现该驱动的bundles的机制。这个可用作即插即用方案。	org.osgi.service.device
Configuration Admin	动态的管理Bundle的配置的属性	org.osgi.service.cm
Metatype	提供语法描述机制	org.osgi.service.metatype
Preferences	为每个bundle提供了可持久化参数数据的存取机制	org.osgi.service.prefs
User Admin	使用一个用于授权（检查认证信息）和验证（检查访问权限）目的的用户信息数据库	org.osgi.service.useradmin
Wire Admin	连接数据生产者和消费者	org.osgi.service.wireadmin
IO Connector	该服务以javax.microedition.io包为基础，屏蔽了各种设备和协议之间的实现差异，提供了更加统一和抽象的设备连接API，而具体的实现则交由用户在这个服务的基础上进行扩展。	org.osgi.service.io
Initial Provisioning	定义包的格式以及部署一组bundle的传递方法	org.osgi.service.provisioning
UPnP	发布和寻找UPnP服务	org.osgi.service.upnp
Declarative Services	定义轻量级的面向服务的组件模型，完善OSGi服务层	org.osgi.service.component
Event Admin	提供发布和订阅的基于主题的事件通知	org.osgi.service.event
Deployment Admin	部署管理服务提供一种新的部署方式：部署包(Deployment Packages)。部署包能够将包内的资源看做一个整体而不是松散的文件，比如一个部署包里面可以同时有一个bundle和其对应的配置文件数据。这样做的一个好处就是能让这个整体保持一致性。	org.osgi.service.deploymentadmin
Application Admin	为了支持对一些传统类型的应用程序（比如Applet）的使用和集成，这个服务提供了一个抽象的管理机制。	org.osgi.service.application
DMT Admin	使用来自OMA DM规范的概念来管理各种设备	info.dmtree
Monitor Admin	定义bundle状态变量的发布；管理bundle对状态变量的读取和设定	org.osgi.service.monitor
Foreign Application Access	在OSGi面向服务的架构中允许外部应用加入	org.osgi.application
BluePrint Container	将定义面向服务的组件模型和Spring紧密联合起来	org.osgi.service.blueprint
XML Parser	解决JAXP中定义的类如何在OSGi中使用的问题	org.osgi.util.xml

常见服务介绍

日志服务

日志服务提供了一个通用的日志记录服务。由两个服务组成：写日志服务和读取日志服务。规范定义了使用方法和接口语义，共开发者使用，来记录日志和获取日志。

bundle可以使用Log Service来为操作者记录信息，其他的bundle，可以使用Log Reader Service来得到日志。

• LogService

  这个服务接口允许一个bundle记录日志信息，包括消息，等级，异常，ServiceReference对象和Bundle对象。

• LogEntry

  这个接口允许访问日志实体，它包括被LogService记录的所有信息和一个时间戳。

• LogReaderService

  这个服务接口允许访问最近的LogEntry对象列表，也允许注册一个logListener监听器对象，在LogEntry对象被创建的时候监听器将接收这些对象。

• LogListener 是LogEntry对象的侦听器接口，必须注册在LogReaderService上。

HTTP服务

为了可以访问internet或者其他网络的服务，需要使用标准web浏览器接收、控制服务。如果想在OSGi环境中提供复杂的 Jsp/Struts/WebWorks 等等，或者想用现有的 Web 中间件服务器例如 Tomcat/Resin/WebSphere Application Server 等，都需要另外的途径来实现，目前我提供一些基本的使用 HTTP 服务的方式。

总的来说，OSGi HTTP Service支持通过Mapping URL进行servlet和资源的注册。在使用的时候，通过URL来获取对应的servlet或者资源。

• HttpContext

  允许bundle为servlet或者资源注册提供信息，也可以通过context 的 getService 方法从ServiceRegistry中获得服务引用来获取HttpService，这一点和OSGi其他类型服务类似。

• HttpService

  允许框架中的其他bundle动态地将向URI命名空间中注册或者注销资源或是servlet。

• registerResources

  注册资源，提供本地路径、虚拟访问路径和相关属性即可完成注册，客户可以通过虚拟访问路径和资源名称访问到资源。

• registerServlet

  注册servlet，提供标准 Servlet 实例、虚拟访问路径、相关属性以及 HttpContext（可以为 null）后即可完成注册，客户可以直接通过虚拟访问路径获取该 Servlet 的访问。

• NamespaceException

  当请求注册servlet或者是资源出现错误的时候抛出异常。

Event Admin服务

提供基本的发布-订阅事件模型。事件发布者通过调用Event Admin Service的sendEvent或postEvent方法对外发布事件，事件订阅者则通过实现Event Handler并注册为EventHandler的服务来订阅感兴趣的事件。每个event包括一个topic，topic是一个字符串和一组属性。事件处理器以服务的形式注册，使用meatadata元数据来描述他们对什么topic和属性感兴趣。事件可以以同步或者是异步的方式发送，通过使用白板模式发送到匹配的事件处理器。其他类型的OSGi事件（例如框架、bundle、service、日志事件）通过Event Admin Service实现来匹配和发布。

• Event

  Event对象有一个topic以及一个Dictionary对象来表示事件的属性。

• Event Admin

  为Event Handler和Event Publisher提供发布/订阅模型的服务。

• Event Handler

  接收Event对象的服务。

• Event Publisher

  通过Event Admin发送事件的Bundle。

• Event Subcriber

  Event Handler的别名。

• Topic

  Event类型的名字。

Configuration Admin服务

CM用于动态的管理Bundle的配置的属性，而这些属性的存储可能是在本地、也有可能是在远端、甚至可能会在某些设备上，基于Configuration Admin Service就可以统一的、动态的、远程的完成Bundle配置属性的管理工作了。

Configuration Admin Service，是用于管理Bundle属性、并在属性发生变更时通知相应的BUNDLE。这样，系统就能够动态的修改配置属性，而不需要重启系统。

它的实现原理：当一个BUNDLE需要能够动态的改变它的属性值时，该需要向OSGi CM注册该属性，注册时需要使用一个PID来标识这个配置属性。在OSGi CM框架中，PID是用来唯一标识一个配置项属性集。在配置项的管理BUNDLE中可以通过PID和BUNDLE的location来得到该配置的值，也可以更新该配置属性值(以Dictionary的形式)并通知该配置属性所对应的BUNDLE该配置属性已经改变了。

其中ConfigurationAdmin,ManagedService均为CM定义的规范的服务接口，该BUNDLE向OSGi框架注册配置属性时需要实现ManagedService接口的update方法来改变该BUNDLE运行时配置属性。配置管理BUNDLE可以通过Configuration Admin的getConfiguration方法得到BUNDLE的配置属性，对其他bundle的配置进行初始化或者更新，而非配置管理bundle只可以更新自己的配置。

声明式服务

声明式服务(Declararive Services)对OSGi的核心框架进行了改善和提升。尽管OSGi核心框架中的服务层对于面向服务的的系统已经提供了完整的服务注册、查找、绑定和监听的定义，但对于服务的发布、使用而言并不是非常方便，DS则提升了Service的发布和使用的简便性，同时更好的去实现Service的动态性，不过DS除了具备DI Container的特征之外，还有一点更为根本的是保证了系统的动态性。DS提出了完整的Service-Oriented Component Model（SOCM）概念，使得在Bundle中可以按照Component＋Service的方式进行开发。

BluePrint Container

Blueprint Container规范定义面向服务的组件模型和Spring紧密联合起来，为 OSGi 定义了一个 依赖性注入（dependency injection）框架。这个规范的基础来自与Spring Dynamic Modules项目。它的目的是处理 OSGi 的动态特性，即服务可以在任何时间变得可用和不可用。该规范的另一个意图是处理普通旧 Java 对象（POJO），这样相同的对象就可以用于 OSGi 框架的内部和外部。定义并描述应用程序各个组件的 Blueprint XML 文件对 Blueprint 编程模型十分重要。规范描述了组件如何被实例化，以及如何相互连接在一起形成一个可以运行的应用程序。

一旦扩展器确定某个包是 Blueprint 包（需要有一些配置文件）后，它将为这个包创建一个 Blueprint Container。这个 Blueprint Container 负责完成以下操作：

• 解析 Blueprint XML 文件
• 实例化 BluePrint Container
• 将组件连接在一起

Gemini Blueprint是对Blueprint Container的一个实现，有兴趣的读者可以参见《Gemini Blueprint介绍》这一节加深对规范的理解。

结语

上面只是对Conmpendium服务的简要介绍，如果有兴趣了解的更多，可以访问http://www.osgi.org/download/r4v42/r4.cmpn.pdf深入学习。