OSGI Declarative Services 规范

      看了下OSGI的Declarative Services 规范,和开始想象的功能不一样.其实就是把手动注册服务改为通过指定配置文件,平台自动注册Bundle暴露的服务.采用component 方式封装 Service,方便了对 Service 的复用.Component 可以是 Service 的提供者和引用者，一个 Component 可以提供 0 至多个 Service，也可以引用 0 至多个 Service,通过XML文件描述和服务组件相关的信息，SCR(Service Component Runtime)根据服务组件配置文件(包括如组件的类型、组件的实现以及引用的服务等信息)控制着组件配置的激活(Activate)和钝化(Deactivate).

      注: Component, 其实它就是Bundle中对应的普通的java类.每个Bundle中可能会定义多个Component,每个Component又会暴露多个服务接口.

      该规范主要解决的问题是:它是一个面向服务的组件模型，它制订的目的是更方便地在 OSGi 服务平台上发布、查找、绑定服务，对服务进行动态管理，如监控服务状态以及解决服务之间的复杂的依赖关系等问题。Declarative Services 采用服务组件的延迟加载以及组件生命周期管理的方式来控制对于内存的占用以及启动的快速，很好的解决了传统的 OSGi 服务模型在开发和部署比较复杂应用时内存占用大、启动慢等问题，并且对服务组件的描述采用XML来实现，十分便于用户理解和使用.

     一. Component

 

     规范里提到了Component Satisfied 的概念. 在 Declarative Services 中，Component Satisfied 与 Component 的生命周期密切相关。如 Component 激活的前提条件之一就是 Component Satisfied，而在 Component 的运行过程中，出现 Unsatisfied 时，Component 将被钝化。主要由以下两点决定 Component 是否处于Satisfied 状态：

     1.只有在 Bundle 处于 Active 状态时，Component 才有可能为 Enabled 状态，在 Bundle处于 Stop 状态时，Bundle 中所有的 Component 都处在 Disabled 状态。

     2.Component 的配置是可以被引用和解析的，Component 中引用的 Service 也是 Satisfied 的，引用的 Service 至少有一个是处于可用状态的，或者引用的 Service 在服务组件配置文件里配置了可为 0 个可用状态的 Service。

     当上述两个条件中任何一个不满足时，组件配置将变为 Unsatisfied 状态，组件配置将被钝化.

 

     在 Bundle 启动时， Declarative Services 装载相应的服务组件配置文件，配置文件在MAINFEST.MF 文件的 Service-Component 属性指定.

     例如:

          

Manifest-Version: 1.0
Bundle-ManifestVersion: 2
Bundle-Name: DSExample Service
Bundle-SymbolicName: dsExample
Bundle-Version: 1.0.0
Bundle-Localization: plugin
Import-Package: org.osgi.framework;version="1.3.0",
 org.osgi.service.component;version="1.0.0"
Service-Component: OSGI-INF/component.xml
Export-Package: ds.example.service
  

      当解析配置文件完成后，获取服务组件引用的 Service ，如果判断组件 Satisfied 状态的两个条件满足时， Declarative Services 就认为这个组件是 Satisfied 的。     

 

     规范定义了三种类型的组件,Immediate Component,Delayed Component,Factory Component.

     1. Immediate Component 

         对于 Immediate Component，如果组件配置处于 Satisfied 状态，将会立即被激活，并且如果该配置指定了服务，那么 SCR 会注册该服务并且立即激活该服务组件。在 SCR 激活组件配置时，实现服务组件类的 activate 方法将会被调用，在SCR钝化组件配置时，deactivate方法将会被调用

     2.Delayed Component

        对于 Delayed Component ，如果组件配置处于Satisfied状态,该组件并不会立即被激活，Declarative Services 会根据组件配置文件中的 Service 的配置，注册相应的Service 的信息，直到该服务组件被请求时， Declarative Services 才会激活该组件配置 。 Delayed Component 延迟了 Component 类的创建，当该服务组件的服务收到请求时，该 Component 类的 activate 方法才会被调用。如果一个 Component 不是 Factory Component，并且在其组件配置文件中指定了服务，组件的 immediate 属性设置为 false,那么该组件就是 Delayed Component

     3.Factory Component.

        通过在组件配置文件中设置 Component 的 factory 属性，将 Component 声明为 Factory Component。该组件在激活后注册的是一个 Component Factory 服务，只有在调用 Component Factory 的 newInstance 方法后才会激活相应的各个组件，每一次调用 newInstance 方法，都会创建和激活一个新的组件配置。如果在组件配置文件中声明了服务，那么在该组件激活之前，声明的服务被注册

        

    在三种类型的服务组件中，Delayed Component 很好的解决了系统服务的动态性问题，同时也节省了内存的占用。