OSGI的注解服务

2021年11月20日 阅读数:2
这篇文章主要向大家介绍OSGI的注解服务,主要内容包括基础应用、实用技巧、原理机制等方面,希望对大家有所帮助。

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

这个模型是优雅而强大的,它能够使应用程序的构建,脱离bundle,直接经过服务的交互和协做实现。框架

本文给出了一些因为OSGi服务运行在大型系统和普遍部署时,引起的问题:ide

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

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

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

要点:xml

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

实体:对象

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