OSGI开发(基础篇)

这一节讲osgi的一些基础必备知识。

模块层规范和原理

Osgi架构从下层到上层分别为：
1. 执行环境（ Execution Environment）
2. 安全层（ Security Layer）
3. 模块层（ Module Layer）
——模块层是整个 OSGi 中最基础、 最底层的层次。
4. 生命周期层（ Life Cycle Layer）
——生命周期层从“动态”的角度描述了一个模块从安装到被解析、 启动、 停止、 更新、 卸载的过程， 以及在这些过程中的事件监听和 上下文支持环境。
5. 服务层（ Service Layer）
——-服务层是所有 OSGi 标准服务的基础。
6. 框架 API（ Framework API）
——-由一系列通过 Java 语言实现的接口和常量类构成， 为上面各层提供面向 Java 语言的编程接口。

OSGI对模块的定义：
在OSGI中，模块称之为bundle，一个bundle在物理上而言就是一个jar包。Jar包中有一个描述jar包的信息文件，位于jar内部的META-INF目录下的MANIFEST.MF文件。OSGI通过MANIFEST这个文件获取模块的定义信息，比如模块间的互访信息，模块的版本信息等。
一个bundle中一般包含如下的东西：
部署描述文件（MANIFEST.MF，必要的），各类资源文件（如html、xml等，非必须的），还有类文件。这与一个普通的jar包没有任何的区别。但是，除此之外，bundle里还可以放入其它的jar包，用于提供给bundle内部的类引用，即bundle内部的lib库。（跟一个war很类似）。
Note：实际上bundle里可以存放任何的内容，但是在bundle内部不会有嵌套的bundle，即上面提到的存放于bundle中的jar包就只会当成是一个普通的jar包，不管这些jar包中是否含有bundle定义的信息。

描述元数据及其标记的作用：
bundle内部的classpath
——–默认是bundle的根目录，但是可以通过头信息来指定bundle内的多个目录。
Export-Package
——-描述被导出的package
Import-Package
——–描述该bundle需要导入的package
DynamicImport-Package
——–使用此头信息时，OSGI将会扫描该头信息设置的所有包
Require-Bundle
——–描述该bundle所依赖的其他Bundle
Fragment Bundle
——–一个模块就是一个Bundle，但有时候我们会需要将Bundle在物理上分成多个块，而且让细分出来的块属于同一个模块下，那么这个时候就有了Fragment的概念。
Fragment没办法独立存在于OSGI中，需要依附于某个Bundle下，即有一个Bundle作为宿主。一个Fragment只能依附于一个Bundle。
Note：Fragment本身没有自己的classloader，使用的是Bundle的classloader。

OSGI bundle经常会指定版本。这里要注意我们导入的是“版本范围”而不是某个具体的“版本” ， 例如示例中 Bundle D 的 Import-Package 写法，只声明了 version=”3.0.0” 的含义并不是“只导入”3.0.0 版本的Package， 而是导入 3.0.0 或以上版本的 Package， 因为这更符合一般的开发使用场景。 如果需要指定只导入 3.0.0 版的 Package， 需要这样写：
Bundle E（ 只导入 Spring 3.0 版本） :
Import-Package: org.springframework.core; version=”[3.0.0,3.0.0]”

OSGi 提倡使用 Import-Package 和 Export-Package 来构成模块之间的依赖关系， 不提倡使用 Require-Bundle， 从实践经验来说， 依赖的粒度总是越小越好。 Bundle 级别的导入还可能会由于 Package 重复导入和导出而带来一系列逻辑缺陷和性能问题。

最后需要注意到处依赖包的优先级：
1、已经解析的bundl导出的package优先于未解析的bundle导出的package
2、具有更高版本的package优先于
3、具有较低bundle id的bundle导出的package优先高于较高bundle id 导出的package