OSGI(1)_入门

OSGI是一种规范

CE整个是在 Equinox （Eclipse 的 OSGi 实现）上打造出来的。

先来学习下OSGI。

学习内容：

http://osgi.com.cn/article/7289520

1. OSGI不是一个应用层面的框架，而是设计层面的规范
2. OSGI的目的是模块化，就是为了将一个大的应用分解成较小的模块，这些模块物理上就是一个个的jar包，也就是OSGI bundle。OSGI规范就是指导怎么令这些bundle能更好的有高内聚性、有松藕性，能更好地被复用。至于被神化的“动态性”、“热插拔”的特性，则是OSGI规范带来的一种可能，并不是一定会有的。这些特性是需要配合好的设计才能达到。

是一种形而上的设计规范。

生命周期：

隔离

和普通的java应用不同，普通的应用，我们不用关心jar包的相互依赖关系，仅仅是将这些jar包一起部署，就可以用jar包里的java类了。也就是说，在运行时，一堆的jar包并不需要我们去特意去分辨它们之间的关系，部署好后，该用到谁就自然能用上谁，整个应用就是一体的，jar包的依赖关系并不清晰。

而在OSGI规范下，bundle是被“有计划地”依赖着，你得显式地说明模块之间的依赖关系。OSGI是利用JVM的classloader和它的父委托模型（PDM:Parent Delegation Mode）来实现这点的。

classloader就是加载java类的加载器，一个classloader加载的类，就只能被这个classloader及其子classloader加载的其它类访问到。也就是说，如果两个不是父子关系的classloader加载的类是互相不可见的。

而OSGI对每一个bundle都分别用一个classloader来加载里面的类，所以不同bundle之间的类，在默认情况下，是互不可见的。

如果没有额外处理，一个bundle里的类要访问另一个bundle里的类时，通常会出现 ClassNotFound的异常，可以说这个异常将是OSGI初学者最常见到的异常。

耦合

上面说了，加载器不一样，隔离性很好，但是只有多个bundle结合在一起才能更好的工作。

为了能引用别的bundle的类，osgi通过import/export package的机制来控制bundle间有限地藕合。

在bundle的设计时，我们将需要给其它bundle“访问”的类放在若干个package内，然后export这些package，就可以让其它bundle通过import package的方式“访问”到这些package里的类，而没被Export的package里的类则被“保护”起来。

和sofa一样， Export/Import package是通过bundle里的META-INF/manifest.mf文件里指定的。

osgi service是osgi规范中定义的一种本地服务的机制，“本地”意味着它只是在osgi framework内有效，不可跨osgi framework调用，更不可跨JVM调用。osgi service可以认为是一种“微服务”，可以在bundle之间引用。

osgi framework有一个service registry,bundle可以把一个实现某种接口的bean实例作为osgi service注册（register）到service registry上，其它bundle就可以从service registry上发现并引用它，所以，本质上osgi service就是一个bean。

通常，我们会把接口定义在一个bundle A里，接口的实现则在另一个bundle B里，并将接口实现实例化后注册成osgi service，而第三个bundle C则引用这个osgi service。

这也是我们现在把接口放在integration层，然后在其他bundle中来实现这个接口。

因为bundle B和C都需要用到bundle A的接口定义，所以bundle A需export接口定义所在的package，而bundle B和C则需import这个package。这样bundle B和C之间就不需用export/import package来藕合了，实现B和C之间的解藕。

其他

OSGI规范还提供了Event、配置管理（ConfigAdmin）、声明式服务（Delarative Service）、Service Tracker、Blueprint等等运行时机制，方便我们构建模块化的应用系统，