深入理解OSGI的模块化

Posted 2020-10-03 窗边冷月光

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了深入理解OSGI的模块化相关的知识，希望对你有一定的参考价值。

定义

OSGI（Open Service Gateway Initiative）技术是面向Java的动态模型系统。

OSGI框架实现了一个优雅、完整和动态地组件模型。应用程序（bundle）无需重新引导可以被远程安装、启动、升级和卸载。

OSGi技术提供允许应用程序使用精炼、可重用和可协作的组件构建的标准化原语。这些组件能够组装进一个应用和部署中。

OSGi服务平台提供在多种网络设备上无需重启的动态改变构造的功能。

为了最小化耦合度和促使这些耦合度可管理，OSGi技术提供一种面向服务的架构，它能使这些组件动态地发现对方。

OSGi联盟已经开发了例如像HTTP服务器、配置、日志、安全、用户管理、XML等很多公共功能标准组件接口。这些组件的兼容性插件实现可以从进行了不同优化和使用代价的不同计算机服务提供商得到。然而，服务接口能够基于专有权基础上开发。

OSGi的主要职责就是为了让开发者能够创建动态化、模块化的Java系统。

OSGI框架

模块和模块化

模块（module）：定义了一个逻辑边界，这种模块本身精确的控制了哪些类是完全被封装起来的，而哪些类需要暴出来作为外部使用。

模块化（modularity）：将一个大型系统分解为多个较小的互相协作的逻辑单元，通过强制设置模块之间的逻辑边界来改善系统的维护性和封装性。

构成

OSGi框架从概念上可以分为三层：模块层、生命周期层和服务层。

Module Layer：模块层关注代码的打包和共享；

Lifecycle Layer：生命周期层提供运行时管理以及对OSGI框架的访问接口；

Service Layer：服务层关注模块之间的交互和通信。

模块层

模块层是 OSGi 框架中最基础的部分。

OSGi 的模块化，是通过为 Jar 包添加metadata 来定义哪些类该暴露，哪些类该隐藏，其控制单元叫做 Bundle（jar 包）。

首先，必须先了解一个基本概念——什么是Bundle？

bundle 是以 jar 包形式存在的一个模块化物理单元，里面包含了代码，资源文件和元数据（metadata），并且jar包的物理边界也同时是运行时逻辑模块的封装边界。

如何定义Bundle

Bundle 是 OSGi 中的基本组件，其表现形式仍然为 Java 概念中传统的 Jar 包。

通过 META-INF 目录下的 MANIFEST.MF 文件对其予以进一步的定义。

通常一个 MANIFEST.MF 文件的内容如下：

Manifest-Version: 1.0

Bundle-ManifestVersion: 2

Bundle-Name: Util

Bundle-SymbolicName: com.ibm.director.la.util

Bundle-Version: 1.0.0

Bundle-RequiredExecutionEnvironment: J2SE-1.5

Import-Package: org.osgi.framework;version="1.3.0"

Export-Package: com.ibm.director.la.util;uses:="org.osgi.framework"

Bundle-ClassPath: lib/junit.jar,

MANIFEST.MF 文件存储的实际上是 Bundle 的元数据。

元数据的内容可以精确的定义 Bundle 的各种特征，同时能更好的对 Bundle 进行标识同时帮助用户对Bundle进行理解。

MANIFEST.MF文件格式

1. 属性声明的一般格式：name：value

2. 一行不超过72个字符，下一行继续则由单个空格字符开始

3. 每个子句（clause）进一步分解为一个目标（target）和一组由分号分隔的name-value对参数（parameter）

元素解释：

Bundle-SymbolicName 唯一的bundle名称，相当于在系统中的id。singleton表示是否使用单启动方式 #可选的

Bundle-Version 主要的版本号

Bundle-ManifestVersion 定义了bundle遵循规范的规则，1表示r3规范 2表示r4和以后的版本

a) 唯一有效的值是2

b) 没有Bundle-ManifestVersion的Bundle不要求指定Bundle- SymbolicName属性

Bundle-Name bundel名称

Bundle-Vendor 发布商

Bundle-RequiredExecutionEnvironment 需要的执行环境

Build-Jdk jdk版本

Created-By 创建者

Bundle-Activator Activator类路径

Import-Package 引用包的信息，包括包名称和版本号，只有引用了这些包，才能让classloader装载

a) 导入一个包并没有导入它的子包

b) Import-Package通过属性导入特定的包

c) 除java.*

d) 对于任意属性，OSGI只支持相等匹配

e) Version及其值的格式是OSGI规范所定义，支持更加灵活的匹配方法

f) 需要指定一个精确的版本范围，使用“[1.0.1,2.0.1]”这样的格式

g) 当没有指定版本范围时，默认的值是“0.0.0”

Export-Package 对外暴露的Package

a) 标准Jar文件默认公开一切内容，而Bundle中默认不公开任何内容

b) 可导出多个包，用逗号分隔

c) 可以给导出包增加任意属性

d) 可以给导出包设置Version，默认为0.0.0

Require-Bundle 直接引用整个bundle

Bundle-ClassPath Bundle 的 Classpath，内部类路径

Fragment-Host Fragment 类型 Bundle 所属的 Bundle名

DynamicImport-Package Bundle动态引用的 package

OSGI类的查找顺序

1. 如果类所在的包以“java.”开头，委托给父类加载器

2. 如果类所在的包在导入包中，委托给导出该包的Bundle

3. 在Bundle自身的类路径上查找

依赖解析

含义

1. 只有满足所有的依赖（Import-Package），bundle才可用

2. OSGI框架的一个最重要任务之一就是：通过自依赖解析自动化地进行依赖管理

依赖解析规则

1 级联解析

2 Import-Package的属性约束和版本约束

3 多个Bund满足Import-Package依赖（多个Provider）时：

3.1 已解析的（resolved）bundle优先级高，未解析的（installed）bundle优先级低

3.2 相同优先级，有多个匹配时，版本高者优先，版本相同则选最先安装的bundle

4 一个bundle只能看到某个package的唯一一个实例

5 uses 子句

5.1 用于限制Export-Package

5.2 需要用到uses子句的场景

5.2.1 导出包中的类，其方法签名中包含了其Import-Package中的类

5.2.2 导出包中的类，继承了其Import-Package中的类

5.3 users约束是可传递的

5.4 谨慎使用uses，大大·限制解析的灵活性

生命周期层

作用

1 在应用程序外部，生命周期层精确低定义了对bundle生命周期的相关操作

2 对生命周期的操作，允许你动态地改变进行于框架中的bundle组成，并以此来管理和演化应用程序

3 在应用程序内部，生命周期层定义了bundle访问其执行上下文的方式，为bundle提供了一种与OSGI框架交互的途径以及一些执行时的便利条件

4 OSGI框架支持对bundle形式的JAR文件实现全生命周期管理，包括：安装、解析、启动、停止、更新和卸载

5 运行时生命周期管理，“动态类路径”

下图为 Bundle 生命周期的状态转移图：

重要接口

生命周期层的API主要是由以下三个核心接口来组成的：

BundleActivator，BundleContext 和 Bundle。

BundleActivator：让你能够捕捉bundle的start和stop事件，并对这两个事件作出自定义的反应。

其中：

1 调用start()方法的激活器实例与调用stop()的实例是同一个

2 当stop()方法被调用之后，激活器实例就被丢弃并不再不用

3 如果一个bundle被停止后，又重新启动，那么将创建一个新的激活器实例，同时它的start()方法和stop()方法也将被适时触发。

BundleContext：一个bundle在框架中的执行时上下文，这个上下文提供了和框架进行交互的方法。

其中：

1 在bundle属于active状态时，BundleContext才有意义，即start()方法被调用和stop()方法被调用之间的时间点

2 注册服务：

方法如下：

public ServiceRegistration registerService(String clazz, Object service,

Dictionary properties);

调用例子：

@Override

public void start(BundleContext context) throws Exception {

Dictionary<String, String> props = new Hashtable<String, String>();

props.put("ServiceName", "Calculation");

context.registerService(ICalculation.class.getName(), new Calculation(), props);

System.out.println("Service registered!");

}

3 获取服务：

有几种方式：

1、ServiceReference ref = context.getServiceReference(LogService.class.getName());

优点：很难说有什么优点，硬要说几句的话，那就是逻辑够简单，调用最少，适合一次性操作。
缺点：需要判断返回值是否为null，需要手动申请和释放service，由于OSGi的动态性，请在获取ref后尽快使用，无法保证ref长期有效。每次访问都会有service获取和释放的开销。
用途：适合于不频繁的调用service，且在service不可用时也能继续执行后续操作的场景。

2、使用ServiceListener

优点：只在Service变更时产生一次service获取开销，动态感知service的注册和注销。
缺点：在ServiceListener注册之前已经存在的Service无法监听到。需要自己维护service的获取和释放。在需要监听多个Service实例时，使用并不方便。

3、使用ServiceTracker

ServiceTracker其实是对ServiceListener实现方式的封装，使得对service的获取更加简洁，同时也解决了不能监听到已经存在的Service的问题(其实就是在增加ServiceListener的同时调用BundleContext.getAllServiceReferences方法以获取现有的Service引用)。