OSGi in action 读书笔记 第二章

第二章 精通模块性

这种主要是讲一下OSGi的模块性。什么是模块性，一般说来为什么模块性如此重要，以及模块性如何让你在未来的Java开发，构建和维护中受益。

具体的，这一章讲会介绍OSGi的bundle的元数据，以及如何用这些元数据来描述你的应用的模块性。当然了，还有一个例子。

 

2.1 什么是模块性

什么是模块呢？一般的，一个完整的系统由若干相对独立的块组成，这些块就叫模块。模块定义了可以实施的逻辑边界。内部细节只能模块内可见，外界只能看见模块明确对外公开的部分。

 

2.1.1 模块性 vs. 面向对象

模块性和面向对象的相识点在于他们都是为了隔离关注，也就是把一个系统分隔成有较少重合的单元，然后你就可以各个击破。当你的系统需要某些功能的时候，你坐下来开始写一些类去实现需要的功能。而且大多数情况下，你会写很多类，或者使用第三方提供的类库。当你的应用完成以后，类之间的逻辑关系都是体现在低层的代码层级的。光从类名你是很难判断类之间的依赖关系的，除非去自己看代码。所以，类封装了数据，而不是代码。而模块呢，封装了代码。其实java里的package也是封装代码的一种形式，但它的功能比较弱。所以，在java开发中，面向对象可以看出是模块的实现方式。你使用对象来构建模块。所以开发单独的类是从小处着手关注具体功能实现，而模块是从大出入手关注应用的总体结构。

模块的定义：一些逻辑上封装了的实现类+可选的基于实现类的公开的API+对外部代码的依赖

小贴士：逻辑模块性 vs. 物理模块性

模块定义了你应用的逻辑边界，并影响代码可见性。逻辑的模块性指的就是代码可见性。而物理模块性指的是你的代码的打包方式以及部署方式。在OSGi中，这两个概念基本上被合并了。但是就模块性而言，它们是不同的概念。

 

2.1.2 关于车的模块性

讲了一个车的例子，来解释不同的模块可能需要相同的类，但如果用的是相同类的不同种别，java就无法实现了，因为java总是使用在类路径中最先找到的类。没完全明白这个例子和作者想要表达的东西。

 

2.2 为什么要模块化

模块化就是为了让你的应用高内聚，低耦合。高内聚指的是你的应用的每个模块只完成独立功能。低耦合指的是各个模块之间的依赖性要尽可能的少。

更具体的，一旦你用OSGi来模块化你的应用，所有的对外部代码的依赖都会显示声明，使得重用更为简单，因为你不再需要去翻文档去查看你用的类库到底需要哪些其他的类库。而且由于你的应用的模块性，各个应用组可以各自开发各自的模块，这特别适合于多组多地点的开发项目或者大型的开源项目。

 

2.3 模块化一个简单的绘画程序

这里就不赘述了。

 

2.4 bundle介绍

bundle的定义：一个模块化的物理单元，一般是jar的打包形式，包含代码，资源文件和元数据。jar文件的边界也作为运行时逻辑单元的封装边界。

bundle和普通的jar包的主要区别是bundle包含模块的元数据。虽然所有的jar文件都有manifest.mf这个文件。

 

2.4.1 bundle在物理模块性方面的角色

你不需要什么额外的数据来决定一个类是否属于一个模块。你只要把你的类放在jar包里就表明你的类属于这个模块。所以bundle也是你的模块的部署单元。bundle的元数据是放在manifest文件里的。关于这个元数据是应该放在manifest文件里还是直接放在源文件里（以annotation的形式），业界一直有争论。书中给了一个小贴士，详细描述了各自的优缺点。把元数据放在manifest文件里的好处有这么几个：

· 当你对元数据做了更改，你不用重新编译bundle

· 你不用访问代码区添加或修改元数据

· 你不用把类加载到虚拟机从而去访问相关的元数据

· 你的代码不需要依赖OSGi的API，从而你可以把你的代码用在别的框架里

· 你可以把你的代码用在多个模块里

· 你可以把你的代码运行在更老的或者不支持annotation的虚拟机里

 

2.4.2 bundle在逻辑模块性方面的角色

bundle在逻辑模块性方面的角色主要是控制代码的可见性。你必须在元数据中明确指出你的bundle种的哪些包是可以被外部访问的。否则，即使你包中的类是public的，外部也不能访问。

 

2.5 使用元数据来定义bundle

模块相关的元数据主要有以下三类：

· 人工可读的信息 - 这些信息是可选的，纯粹给使用bundle的人用的

· bundle识别 - 这些信息用来唯一确定一个bundle

· 代码可见性 - 这些信息用来定义哪些代码是内部可见，哪些内部代码是外部可见

书中给了个小贴士详细解释了jar文件manifest文件的语法

 

2.5.1 人工可读的信息

人工可读的信息主要是提供一些信息，譬如这个bundle是干什么的，来自哪里等，主要帮助使用bundle的人了解它。下面是一个实例：

Bundle-Name: Simple Paint API
Bundle-Description: Public API for a simple paint program.
Bundle-DocURL: http://www.manning.com/osgi-in-action/
Bundle-Category: example, library
Bundle-Vendor: OSGi in Action
Bundle-ContactAddress: 1234 Main Street, USA
Bundle-Copyright: OSGi in Action

这些属性都比较直观，而且这些信息是直接被OSGi框架忽略的，所以你在定义这些属性的时候具有比较大的自由度。

 

2.5.2 bundle识别

Bundle-SymbolicName被OSGi框架用来帮助唯一标识一个bundle，它的值采用跟java的package类似的，用点分开的一些字段，推荐使用的你的域名的倒写以防止名字冲突。有了Bundle-SymbolicName还不够，因为一旦你修改了你的代码，你需要一个属性来表明你的代码的版本，并且这种版本信息能被OSGi框架所识别。一般情况下，Bundle-SymbolicName+Bundle-Version可以唯一确定一个bundle。不过由于在OSGi 4的规范的时候，Bundle-SymbolicName才被确定为是必须的属性，所以为了兼容之前的bundle，OSGi添加了一个属性Bundle-ManifestVersion，而且这个属性目前只有一个值2。所有有这个Bundle-ManifestVersion属性的bundle必须有唯一标识这个bundle的属性（Bundle-SymbolicName+Bundle-Version）.

书中有个小贴士，详细描述了版本的写法。

 

2.5.3 代码的可见性

描述代码可用性的元数据主要包含下面这些信息：

1. 内部bundle的类路径 - 这是组成这个bundle的代码

2. 对外公开的代码 - 这些事明确对外暴露的代码

3. 引入的外部代码 - 这些是内部代码依赖的外部代码

 

标准的jar文件的代码可见性和类路径

一般情况下，我们把类编译后打包成jar包。如果jar包里面的manifest文件有指定Main-Class属性的话，我们就可以这样运行你的jar包：

java -jar app.jar

如果你没指定，我们可以把加到类路径然后这样运行：

java -cp app.jar org.foo.Main

java会去查找main函数并运行。当你的程序运行的时候，所有需要的类都会通过类路径去查找。类路径包括那些jar包和标准的jre类。这里有两个问题：

1. 在jar包里面，如何查找你需要的类？

2. 怎样把内部的类暴露给外部访问？

对于第一个问题，Java会从jar包的根目录进行查找，并且把点分开的package的字段作为文件目录来查找。对于第二个问题，默认的，所有jar包的从根目录开始的所有类都是对外公开的。类路径定义了哪些外部类是对我们的jar包里的内部类是可访问的，而且所有在类路径上的类对我们的应用的类都是可见的，即使他们不是必要的。

 

内部bundle的类路径

不像普通的jar包，所有的类都是默认可见的。在bundle中，你必须在bundle类路径中指出哪些类是对jar包内的其他类是可见的。

bundle-classpath的定义：一个有序的，用逗号隔开的，用来查找类和资源的jar包内的相对路径的列表

比如这个例子：

Bundle-ClassPath: .,other-classes/,embedded.jar

这样的话，OSGi框架会这样在bundle内部查找一个类：首先它会在bundle的根目录查找这个类，如果没有，它会在叫other-classes的文件夹里查找，然后会在embedded.jar里查找。如果你不定义，bundle的类路径的默认值是.，也就是根目录。需要注意的是，当你没有赋任何值给Bundle-Classpath的时候，它会有一个默认值.。一旦你赋了值，如果你想把.加入到类路径里去，你必须显示的加入。.这个值不是默认的加入到bundle的类路径的。

 

导出内部代码

标准的jar包会把所有的类公开给外部使用，而bundle的话，你必须显示标明你的哪些类是给外部访问的。

输出包的定义：一组用逗号隔开的给外部访问的内部包

在OSGi里，模块之间的类的共享是在package这个级别的。这是个例子：

Export-Package: org.foo.shape,org.foo.other

由于很可能不同的bundle会输出同样的package，所以我们可以给bundle加一些属性，譬如：

Export-Package: org.foo.shape; vendor="Manning", org.foo.other;vendor="Manning"

OSGi除了支持bundle的版本外，还支持给package加版本号。譬如：

Export-Package: org.foo.shape; org.foo.other; version="2.0.0"

package的默认版本号是0.0.0。

 

导入外部代码

你必须使用Import-Package显示导入你所需要的外部代码，不过所有在java.*包里的类是个例外，OSGi框架会自动把它们设置为可见。

Import-Package vs. import关键字

import关键字只是作为名字空间的管理，让你不用输出一个类的完整包名而已。所以你完全可以不用import关键字。而Import-Package对于OSGi框架及其重要，因为它让OSGi框架知道你的bundle需要哪些类。

import-package的定义：一组逗号分隔的内部bundle代码所需要的来自外部bundle的package的列表。例如：

Import-Package: org.foo.shape,org.foo.shape.other

你可以给你的导入包指定一些属性。譬如：

Import-Package: org.foo.shape; vendor="Manning"

这个额外的属性就像是一个过滤器。

当OSGi框架在解析依赖的时候，它会比较从外部导入的包的vendor的属性是否跟这个相同。不过对于版本的话，默认情况下只要提供的版本比所需要的版本新或者一样就是可接受的。当然，你也可以更精确的指定可接受的版本的范围。

不过bundle之间的类共享采用package而不是直接用bundle在业界也是一直有争论的，书中给了个小贴士来讨论这个问题。给我印象比较深的就是它这样的阐述：bundle级别的依赖就像是依赖某个人，而package级别的依赖就像是依赖某个东西。如果另外一个人也提供相同的东西的话，你没有理由还是顽固的依赖原来那个人。而且当你的bundle增长的足够大的时候，你可能希望重构你的bundle，那样的话，原来依赖这个bundle的bundles都需要做更改。而且很多时候，一个bundle可能只依赖另一个bundle中的某几个package而不是所有的package。

 

2.5.4 类查找顺序

当一个bundle运行的时候需要某个类，框架查找的顺序如下：

1. 如果那个类是来自某个包名以java.开头的话，父类加载器会去加载这个类。如果找到了这个类，就使用这个类；如果没找到，查找结束并抛出异常。

2. 如果这个类是来自一个导入的包，那么框架会去导出包里去查找这个类。如果找到了，就使用这个类；如果没找到，查找结束并抛出异常。

3. 查找bundle类路径。如果找到了，就使用这个类；如果没找到，查找结束并抛出异常。

 

小品文：bundle是个jar包 或者 jar包是个bundle?

jar包是不是个bundle？的确，jar包是bundle，但由于它没有提供任何的模块的元数据，它没有向外界提供任何可用的类，所以它一点用都没有。

只有bundle的类路径仅包含.的bundle可以作为普通的jar包使用。

 

2.6 结束我们的绘图程序的设计

这个绘图程序设计了三个bundle，一个是shape API，是个接口，一个是shape impl，就是接口实现，还有一个是窗口程序使用图形。

 

2.6.1 改进我们的绘图程序的模块化

这里也就是把各个图形的实现分成了独立的bundle

 

2.6.2 启动新的绘图程序

这里使用了一个通用的OSGi bundle启动器来启动我们的绘图程序：

java -jar launcher.jar bundles/

这个启动器会创建一个OSGi框架的实例，然后部署bundles文件夹里的所有bundle。具体的有关启动器的实现将在后续章节详细讨论。

 

2.7 OSGi 依赖解析

这块主要介绍OSGi如何解析bundle的package依赖以及如何确保bundles间的package一致性。

 

2.7.1 自动解析依赖

OSGi框架完成的一个重要任务是自动化依赖管理，也叫bundle依赖解析。一个bundle的依赖必须首先被框架解析才能被使用。

解析的定义：以统一的方式把一个bundle的导入包匹配到导出包，使得每个bundle的依赖包只有版本的过程。

解析一个包会导致其他的包被解析，如果你所依赖的导出包没有被解析的话。所有传递依赖的包被一次解析，直到所有的包都被解析。如果其中有个依赖不能被满足，那么解析将会失败。那么你最开始解析的那个包就不能被使用直到它所有的依赖都被满足。

有三个问题：

1. 框架什么时候会去解析一个bundle的依赖？

2. 在刚开始的时候，框架是怎么访问bundle并开始解析的？

3. 把导入bundle连到导出bundle是什么意思？

第一个问题，当有其他的bundle要试图访问某个bundle的时候，框架就会自动解析这个bundle。

第二个问题，只有当一个bundle被安装进框架的时候，框架才会去解析。

第三个问题，在执行的时候，每个OSGi的bundle都相应的有一个类加载器相连，这也是每个bundle如何来访问它需要访问的类的。当一个导入bundle连到一个导出bundle的时候，导入bundle的类加载器就得到了一个指向导出bundle的类加载器的引用，然后如果导入bundle需要访问导出bundle的类的话，导入bundle的类加载器就可以把这个请求委托给导出bundle的类加载器。

简单的例子

依赖解析其实相当直观，框架只需要把导出匹配到导入。

小贴士：系统类路径的代理

 JRE中所提供的类一般是默认可以访问的

 

如果导入中指定了属性，依赖解析还要匹配属性。还有版本信息也可以作为限制条件加到导入中。

 

多供应商的情况

 之前的例子比较简单，因为导入bundle需要的package只有某一个bundle提供。当有多个匹配的导出bundle的话，框架将如何解析呢？如果有多个版本的package可供连接，框架会选择版本最高的。那如果版本一样呢？框架会选择最先安装的。还有一个情况是，框架会优先选择已经解析过的包。所以稍微总结下依赖解析选择的优先级：

1. 已经被解析的包有最高的优先级，如果都已经被解析了，那就按照版本和安装先后

2. 没有被解析的包安装版本和安装先后排序

 

2.7.2 确保使用限制的一致性

对于一个bundle而言，所有它可见的包被称为它的类空间。所以一个bundle的类空间就是它导入的包加它的bundle的类路径。所有bundle的类空间必须是一致的。如果我用了某个版本的A类，这个框架内安装的其他bundle如果要使用A类，那它必须是同一个版本的。书中给出了一个例子。说某个HTTP Service需要2.3版本的Servlet，而框架中也正好有2.3版本的Servlet。而HTTP Client需要2.4版本的Servlet，而HTTPClient中调用了HTTP Service的方法，那么这个方法中的Servlet应该是哪个版本呢？如果这两个bundle是同时安装的，那么比较简单，框架会选择比较新的版本2.4。如果HTTP Service指明只能是2.3，而HTTP Client指明只能是2.4版本呢。

使用指令：附着在导出包的逗号分开的包的列表

例子如下：

Export-Package: org.osgi.service.http;
uses:="javax.servlet"; version="2.3.0"
Import-Package: javax.servlet; version="2.3.0"

这样的话，所有使用这个bundle的bundle也必须使用Servlet 2.3了。

 

使用USES

 

2.8 回顾模块化的绘图程序的优点

逻辑边界的强化

重用性的提高

配置的验证

版本的验证

配置的灵活性

 

2.9 总结

模块性提供了一种形式的关注分隔，这提供了逻辑的和物理的类封装

模块性是需要的，因为它允许我们把我们的应用拆分成逻辑上独立的块，这些块可以被各自的修改

bundle就是模块在OSGi中的叫法，其实就是一个包含代码，资源文件和模块元数据的jar包

模块元数据包含了人工可读的信息，bundle识别信息和代码的可见性的信息

bundle代码可见性包含内部类路径，导出包和导入包

OSGi框架在bundle可用之前使用导入包和导出包的元数据来自动解析bundle依赖并确保类型的一致性

导入包和到处包包含了包之间的package依赖，而“uses”约束包含了bundle内部的package的依赖来确保完整的类型一致。