【框架学习】OSGI 基础 - hippowc/hippowc.github.io GitHub Wiki

OSGI

OSGi技术是 Java 动态化模块化系统的一系列规范。OSGi 一方面指维护 OSGi 规范的 OSGi Alliance(OSGi 联盟)，另一方面指的是该组织维护的基于 Java 语言的服务(业务)规范。简单来说，OSGi 可以认为是 Java 平台的模块层，为大型分布式系统以及嵌入式系统提供一种模块化架构减少了软件的复杂度。

OSGi 联盟(OSGi Alliance)于 1999 年开始着手制定 OSGi 规范，其主要目的就是要制定一套开放式标准，以便向局域网及其中的设备提供可管理的服务；其基本思路是，一旦您在网络设备(如服务器和嵌入式设备)上使用了 OSGi 服务平台，您就可以在网络上的任何地方管理这些设备上运行的软件组件的生命周期，可以在后台对这些组件进行安装、升级或卸载，但不需要打断该设备的正常运行。Eclipse 就是基于 OSGi 开发的。

OSGI标准

OSGI R1 于 2000 年发布，现在最新的标准版本是 R5，到现在为止应用最广泛的当属是 2005 年发布的 R4。

其中主要定义了 OSGi 框架。OSGi 框架提供了一个通用安全可管理的 java 框架，能够支持可扩展可下载的应用(即 bundles)的部署。OSGi 框架是 OSGi 技术最基础也是最核心的部分。OSGi 框架的三个最重要部分：

  • 模块层 ：关注打包和代码共享。OSGi 是严格要求模块化的，模块有个专有名词 bundle。每个模块都是一个 bundle，一个 Business Logic 由多个 bundle 来实现。
  • 生命周期层 ：关注提供执行模块管理和对底层 OSGi 框架的访问。bundle 是需要 OSGi 进行解析的，每个 bundle 在变得可用之前，都需要完整经历该生命周期。
  • 服务层 ：关注模块，特别是模块内的组件的交互和通讯。OSGi 技术全面贯彻了 SOA，每个 bundle 都是其他 bundle 提供服务
模块层
  • bundle 是以 jar 包形式存在的个模块化物理单元，里面包含了代码，资源文件和元数据(metadata)，井且 jar 包的物理边界也同时是运行时逻辑模块的封装边界。
  • bundle 是开发、部署 OSGi 应用的基本单元。
  • bundle 的核心是 META-NF 目录下的 MANIFEST.MF 文件。
  • bundle 定义了其所包含的包的可见性、可以认为是在 public/private/protected 的基础上的一个扩展。
  • bundle 的 java 包共享、屏蔽的规则。通过 Export-Package、Import-Package 方式进行交互。
  • 每个 bundle 都有单独的类加加载器。
生命周期层

状态是 Bundle 在运行期的一项动态属性，不同状态的 Bundle 具有不同的行为，生命周期层规范定义了 Bundle 生命周期过程之中的 6 种状态。

Installed -- Resolved -- Uninstalled. 其中Resolved 分为：Starting -- Active -- Stopping

生命周期的作用：

  • 在应用程序外部，定义了对 bundle 生命周期的相关操作。OSGi 生命周期层允许在执行时，从外部安装、启动、更新、停止、卸载不同的 bundle 进而定制应用的配置。
  • 在应用程序内部，定义了 bundle 访问其执行上下文的方式，为 bundle 提供了一种与 OSGi 框架交互的途径以及一些执行时的便利条件。
服务层

当一个 bundle 发现并开始使用 OSGi 中的一个服务了以后，这个服务可能在任何的时候改变或者是消失。OSGi 框架有一个中心化的注册表，这个注册表从 publish-find-bind 模型

其他规范

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

  • LOG Service(日志服务)
  • HTTP Service(注册 servlet 和资源)
  • Configuration Admin(配置管理)
  • Event Admin(事件通知)
  • Declarative Services(定义轻量级的面向服务的组件模型)
  • Blueprint(一个类似 IOC 容器的实现)

OSGI 特点

从开发的角度：

  • 复杂性的降低：基于 OSGi 的组件横型 bundle 能够隐藏内部实现，bundle 基于服务进行交互。
  • 复用：很多第三方的组件可以以 bundle 的形式进行复用。
  • 简单：核心的 API 总过包括不超过 30 个类和接口。
  • 小巧: OSGi R4 和实现仅需要 300KB 的 JAR file 就足够。在系统中引入 OSGi 几乎有什么开销。
  • 非侵入式：服务可以以 POJO 的形式实现，不需要关注特定的接口。

从可维护的角度

  • 切合真实运行环境：OSGi 框架是动态的，bundle 能够进行即时的更新，服务可以根据需要动态增加或者删除。
  • 易于部署：OSGi 定义了组件是如何安装和管理的，标准化的管理 API 使得 OSGi。 能够和现有和将来的各种系统有机的集成。
  • 动态更新：这是 OSGi 被最经常提起的一个特性，即所谓的 "热插拔" 特性，bundle 能够动态的安装、启动、停止、更新和卸载，而整个系统无需重启。
  • 适配性：这主要得益于 OSGi 提供的服务机制、组件可以动态的注册、获取和监听服务，使得系统能够在 OSGi 环境调整自己的功能。
  • 版本化：bundle 可以版本化，多版本能够共存而不会影响系统功能。
  • 懒加载：OSGi 技术采用了很多懒加载机制。比如服务可以被注册，但是直到被使用时才创建。

缺点：

  • 目前只支持Java
  • 入门高、技术更加复杂
  • 相对的重量级
  • 资料匮乏
  • lib 支持的不好，很多 lib 无法在 OSGi 环境下运行

OSGI开源实现

Equinox
  • OSGi R4 core framework 的一个实现，一组实现各种可选的 OSGi bundle 和一些开发基于 OSGi 技术的系统所需要的基础构件。
  • 应用：Eclipse
  • 相关资料：http://www.eclipse.org/equinox/ 。
Apache Felix
  • 实现 OSGi R4 规范(包括 OSGi 框架，Standard Service 和其它 OSGi 相关技术)的开源项目。
  • 相关资料：http://felix.apache.org/
  • 子项目：Apache Karaf：使用Felix作为OSGI内核，通过提供console，ssh等其他功能的综合版本。http://karaf.apache.org/
  • 子项目：Apache Aries：作为Felix的补充，提供OSGi企业级规范
  • 应用：ServiceMix
Spring DM

目前已经不再使用

Knopflerfish

Knopflerfish其实是OSGi的先行者，但是由于没有强力的靠山，再后来的竞争中显然不如前三者有人气。它本身是一个相当标准OSGi框架，提供了绝大多数标准功能，但是无论在人气上，开发进度上，文档完善上都不如其他的三者。

OSGI其他规范

Blueprint

如果应用使用了大量的OSGI服务的话，直接使用OSGI API开发OSGI应用的方式显然是不合适的。幸好，OSGI规范里为我们提供了很多方便的方式去使用这些OSGI服务，包括Declarative Service（声明式服务DS）、Blueprint、iPojo等等。

Blueprint规范的实现：

  • Apache Aries blueprint
  • Eclipse Gemini blueprint