OSGi框架-初章-概念

1.OSGI组织架构图：

 

2.OSGI架构解决的问题：

 

1.模块分离：（模块之间相互独立）

     在传统的 Java 中有一个“classpath”（类路径），这是一个巨大的类列表，当多个类碰巧使用相同的名称时，总是使用第一个类，而第二个和其他所有的同名类将被忽略。除了这个问题主要还有一个问题就是，整个大的项目为一个整体导致不好维护。一旦一个小的点出现问题，整个项目都需要重新发布，这在时间人力上是极大的浪费。

     正式出于粒度上的考虑，我们不能只是依赖传统的classpath，这样会导致一个大的项目不可分割。为达到模块划分的目的，为每一个模块创建一个类加载器（class loader）。类加载器能够做到仅加载它能够直接识别的类，以及此类识别到的类，需要依赖的一些类。

2.模块之间的依赖及依赖粒度：

     如同一中所述，模块之间相互独立是有必要的，但是只是一味的独立。也存在很大的问题，如，功能的重用性问题，以及在保持模块独立的同时有保持模块的粒度，还有整个系统的功能强大，这个很难做到。所以，模块之间如果没有依赖也是不行的，不依赖和依赖程度过大会走向两个极端。

     对于一个模块而言，有四种依赖粒度：方法级别，类级别，包级别，模块级别。由于模块之间的依赖，会导致出现很长的依赖链（扇出），增加了系统模块间的耦合度。而方法之间的依赖和类之间的依赖太多，不易于管理。从各个角度进行权衡，OSGI最终选择了包之间的依赖，作为模块之间的主要依赖关系，当然模块之间也允许依赖（模块之间不依赖，模块之间的包也无法相互依赖了）。

 

 

3.OSGI架构

1.模块：

      OSGI框架将为这些模块构造实际的运行时实例。它将负责安装模块以及构造类加载器（这些类加载器知道相应模块的内容）。

2.模块之间的依赖：

      OSGI框架中定义两个依赖关系，模块之间的依赖和包之间的依赖，包之间的依赖建立在模块之间的依赖之上。也就是说只有模块之间存在依赖才有包之间的依赖关系。在模块中，会定义需要依赖的模块，需要依赖的包，以及可以被别的模块依赖的包。如果一个模块需要依赖另一个模块的包，必须满足同时依赖这个模块以及这个模块的这个包是公开的。

3.版本控制：

     在一个项目中，除了类可能会重名以外，包和模块都可能重名（一般都是由于版本的问题）。在OSGI中，通过对依赖规则进行版本控制，就是在依赖的时候会加上你所需要依赖的模块和包的版本。当然也可以通过制定版本范围的方式，扩大依赖的版本范围。

4.模块和元数据：

如同上面我们所描述的依赖关系，都需要在模块中得以体现，通过设置一些元数据来对其进行描述，然后通过MANIFEST.MF文件进行存储。模块以jar包方式发布。

5.扩展点功能：

      个人感觉这是OSGI最拉风的技能，其实模块划分和依赖什么的概念早就出现，OSGI只是对其合理实现。而扩展点功能，使得模块化架构能够真正的动态发布。

扩展点功能的原理大致是这样的，某个模块需要某个功能，但是这个功能从职责上由不应该由它自己去实现。另外，这个功能本身具有多态性，例如连接数据库，我们需要连接的数据是可变的，这样的话如果直接依赖某一个特定的连接数据库的功能模块，将变的不合理。

这个时候，此模块定义一个接口，这个接口定义一个虚拟的功能，这个功能就被命名为一个扩展点。其他的模块可以对这个虚拟的功能进行真实的实现，然后当模块需要用到此功能的时候，OSGI会在整个项目中去遍历实现了次扩展点的模块，找到合适的并加载它。