OSGi 系列（一）之什么是 OSGi ：Java 语言的动态模块系统

OSGi 系列（一）之什么是 OSGi ：Java 语言的动态模块系统

OSGi 的核心：模块化、动态。基于 OSGi 就可以模块化的开发 java 应用，模块化的部署 java 应用，还可以动态管理模块。

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

1. 什么是 OSGi

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

2. OSGi 标准

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

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

这里你需要理解 OSGi 框架的三个最重要部分：模块层、生命周期层、服务层。

• 模块层 ：关注打包和代码共享。

  OSGi 是严格要求模块化的，模块有个专有名词 bundle。每个模块都是一个 bundle，一个 Business Logic 由多个 bundle 来实现。

  注：后面全部使用 bundle 代替模块来表述。

• 生命周期层 ：关注提供执行模块管理和对底层 OSGi 框架的访问。

  bundle 是需要 OSGi 进行解析的，每个 bundle 在变得可用之前，都需要完整经历该生命周期。

• 服务层 ：关注模块，特别是模块内的组件的交互和通讯。

  OSGi 技术全面贯彻了 SOA，每个 bundle 都是其他 bundle 提供服务，夸张一点说，不提供服务的 bundle 就没有存在的价值。

2.1 OSGi 三层架构-模块层

模块化其实就是计算机科学中常见的一个概念：将一个大型系统分解为多个较小的互相协作的逻单元，通过强制设定模块之间的逻辑边界来改善系统的维护性和封装性。

模块层定义了 OSGi 中的模块 bundle：

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

• bundle 是开发、部署 OSGi 应用的基本单元。

• bundle 的核心是 META-NF 目录下的 MANIFEST.MF 文件。

• bundle 定义了其所包含的包的可见性、可以认为是在 public/private/protected 的基础上的一个扩展。

• bundle 的 java 包共享、屏蔽的规则。通过 Export-Package、Import-Package 方式进行交互。

• 每个 bundle 都有单独的类加加载器。

来看看在 MANIFEST.MF 中可以定义哪些 Bundle 的的元数据信息：

属性	属性描述
Bundle-Activator	Bundle 的 Activator 类名
Bundle-Category	Bundle 的分类属性描述
Bundle-Classpath	Bundle 的 Classpath
Bundle-Copyright	Bundle 的版权
Bundle-Description	Bundle 的描述信息
Bundle-DocURL	Bundle 的文档 URL 地址
Bundle-Localization	Bundle 的国际化文件
Bundle-ManifestVersion	定义 Bundle 所遵循的规范的版本, OSGI R3 对应的值为1, OSGI R4 对应的值为2
Bundle-Name	Bundle的有意义的名称
Bundle-NativeCode	Bundle 所引用的 Native Code 的地址
bundle-RequiredExecutionEnvironment	Bundle 运行所需要的环境，如可指定为需要 OSGI R3、Java1.4、Java1.3 等
Bundle-SymbolicName	Bundle 的唯一标识名,可采用类似 java package 名的机制来保证唯一性
Bundle-Version	Bundle 的版本
Dynamiclmport-Package	Bundle 动态引用的 package
Export-Package	Bundle对外暴露的 package
Fragment-Host	Fragment 类型 Bundle 所属的 Bundle 名
Import-Package	Bundle 引用的 package
Require-Bundle	Bundle 所需要引用的其他的 Bundle

2.2 OSGi 三层架构-生命周期

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

OSGi 生命周期层有两种不同的作用:

• 在应用程序外部，定义了对 bundle 生命周期的相关操作。OSGi 生命周期层允许在执行时，从外部安装、启动、更新、停止、卸载不同的 bundle 进而定制应用的配置。

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

2.3 OSGi 三层架构-服务层

OSGi 的服务层除了面向服务的编程模型，还有一个区别于其他很多类似模型的特性。也就是说，当一个 bundle 发现并开始使用 OSGi 中的一个服务了以后，这个服务可能在任何的时候改变或者是消失。

OSGi 框架有一个中心化的注册表，这个注册表从 publish-find-bind 模型：

3. OSGi 纲要规范

除了上述 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 容器的实现)

4. 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 技术采用了很多懒加载机制。比如服务可以被注册，但是直到被使用时才创建。

5. OSGi VS 传统 java 模块化

"OSGi" 相比 "传统 java 模块化" 有以下优势：

• 基于接口编程，完全隐藏底层代码实现
• 动态性(对扩展开放，即使是运行时的)
• 版本控制

部分支持 OSGi 的项目：

Apache cxf、Apache thrift、Apache activemq、Apache curator Activiti、drools、mysql-connector-java、postgresql(java client)、rabbitmq(java client)、hazelcast

OSGi 的缺点：

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

6. OSGi 开源框架介绍

1. Equinox：OSGi R4 core framework 的一个实现，一组实现各种可选的 OSGi bundle 和一些开发基于 OSGi 技术的系统所需要的基础构件。 Eclipse 是基于 Equinox 项目开发的一个典型例子。具体内容可以从 http://www.eclipse.org/equinox/ 下载。

   比较适合不需要集成太多外部技术的应用，如桌面应用开发，当需要进行集成时，会遇到相当多的兼容性问题;

2. Apache Felix：实现 OSGi R4 规范(包括 OSGi 框架，Standard Service 和其它 OSGi 相关技术)的另一个开源项目。具体内容可以从 http://felix.apache.org/ 下载。

   与 Equinox 非常相似，都属于基础环境。但也有一个最大的不同，其兼容性、可扩展性都比较强，能够很方便的集成 Web Container、DataSource 管理等许多实际开发中必须具备的组件。但是这里有个很大的隐患：所有的集成都需要手工完成，质量、测试都无法保证，作为系统最重要的基础运行环境，其稳定性、可靠性是至关重要的。

3. Apache Karaf：一个基于 OSGi 的运行环境，它提供了一个轻量级的 OSGi 容器，可以用于部署各种组件和应用程序。它提供了很多的组件和功能用于帮助开发人员更加灵活的部署应用，更适合作为商业化产品的开发、运行平台。具体内容可以从 http://karaf.apache.org/ 下载。

结论：使用 karaf 作为接下来的 OSGi 基础平台，进行下一步的 JavaEE 与 OSGi 整合工作。

参考：

http://blog.csdn.net/cz_jjq/article/details/50378661