OSGi框架，包含了一个过程性的服务模型，该模型提供了对服务的发布/查找/绑定。

这个模型是优雅而强大的，它可以使应用程序的构建，脱离bundle,直接通过服务的交互和协作实现。

本文给出了一些由于OSGi服务运行在大型系统和广泛部署时，引发的问题：

  • 启动时间：过程模型要求bundle活跃地注册和回收它的服务，这在启动的时候很正常，要求所有当前的bundle在启动的时候被初始化。在大型系统里，这样直接导致的结果就是启动时间过长。
  • 内存残留：在框架里注册的服务，意味着他的实现，与他相关的类和对象，被加载到内存里，如果服务从来没有被使用，内存被不必要的占用着。
  • 复杂性：服务可以加载和去除在任何时候，这种动态效果导致服务的编程要比传统的变成复杂，这种复杂性对于OSGi服务模型的被采用是负面的影响，同时也带来了健壮性和可靠性的负面影响。

服务组件模型采用声明方式来发布，查找和绑定服务，这个模型简化了通过执行注册服务和处理服务依赖来书写OSGi服务的工作复杂度。最小化了代码数量，允许服务组件按需装载，因而，bundle无需提供BundleActivator类来和服务库中其他类交互。

从系统的整个视角看，服务组件模型意味着减少了启动时间，并且潜在地减少了内存残留；从编程者的视点看，服务组件模型简化了代码的开发难度。

要点：

  • 向回兼容：服务组件模型必须与已存在的服务模块无缝协作。
  • 尺寸约束：服务组件模型不能要求内存和性能很高的系统环境，它要能够运行在资源受到约束的设备上。
  • 延迟激活：组件模型必须支持服务组件的延迟激活，减少内存占用，内存按需分配。
  • 简化：使用声明式服务的编程模型，必然是很简单的，不需要编程者学习大量的API和xml。

实体：

  • 服务组件：服务组件有一个可以解释执行的描述符，通过描述符，创建和暴露服务对象给其他服务，该服务组件也可以有选择性地提供服务（也可以不提供服务）。
  • 组件描述符：一个服务组件的声明，在一个bundle的xml文件里
  • 组件属性：一组可以由组件描述符，配置管理器，和组件工厂来指定的属性。
  • 组件配置：组件配置代表了通过组件属性参数化了的组件描述符，他是一个实体，用以呈现组件依赖和管理组件实例，一个活跃的组件配置有一个组件上下文。
  • 组件实例：是组件实现类的实例。组件实例在组件配置激活时生成，在组件配置结束时被丢弃。组件实例和组件配置息息相关。
  • 延迟组件：只有服务被请求时，组件配置才会激活。
  • 立即组件：组件配置可以立即使用的组件。
  • 工厂组件：组件配置时被工厂创建和激活的。
  • 引用：对目标服务的特定依赖。
  • 服务组件运行时：是一个角色，他用来管理组件和它们的声明周期。
  • 目标服务：在引用接口和目标属性过滤器里定义的服务集合。
  • 相关服务：在组件配置中提及的目标服务。