OSGi学习笔记

[b]1. OSGi的作用[/b]
在java中是没有模块概念的，我们可以逻辑上定义一些功能为一个模块，但是模块之间不是物理隔绝的，这样的定义很容易被忽略，从而导致某些内部类被外部系统使用，当内部类改变时引起使用内部类的外部系统产生错误。如果我们可以通过配置文件指定某些类只能在模块内部使用，某些类作为服务可以被外部使用，那么就可以实现模块化了，而java中影响物理隔离的主要因素是jvm的类加载机制（全局的classpath），OSGi基于JVM ClassLoader 形成模块隔离 ClassLoader的机制，同时也增强了ClassLoader按版本加载、属性过滤等多种功能。基于此，OSGi使用java中的jar包组织形式，通过在MANIFEST.MF中加入了类隔离等信息形成了以Jar内部ClassLoader和外部ClassLoader组成的模块，OSGi中称其为Bundle。当然这只是其基本原理，OSGi中的模块还有一些其他属性和机制，感兴趣的童鞋可以根据参考文献深入学习。

[b]2.bundle的协作机制[/b]
那么在OSGi框架中Bundle 之间是怎么协作的呢，在OSGi框架中对于每个Bundle 可以定义输出的包以及引用的包，这样在Bundle 间就可以共享包中的类了，尽管这样也可以直接实现简单的Bundle 的协作，但在OSGi框架中更加推荐的是采用Service的方式， Service-Oriented 的概念(例如SOA)，每个Bundle 可以通过BundleContext注册对外提供的服务，同时也可以通过BundleContext来获得需要引用的服务，采用Service-Oriented 的方式可以使得对外提供的服务能够更加的封闭，不需要为了使用别的Bundle 提供的Service 而做环境依赖等的设置，同时，Bundle 还可以采用Require-Bundle的方式来直接引用其他的Bundle(相当于引用其他Bundle 的工程或jar)，资源类依赖推荐用Require-Bundle，java类依赖推荐通过引入和输出包或者Service方式引用。

[b]3. Service及实现机制[/b]
在OSGi框架中，Service是个实际的概念，只有通过 BundleContext注册成 Service 才能使得一个POJO 作为Service在OSGi框架中被使用，同时也只有通过BundleContext来获取发布到框架中的Service，通过 Service 的方式来实现 Bundle 之间实例级的依赖，和Import-Package 、Require-Bundle不同的地方在于通过 Service 获取的是其他 Bundle中类的实例。Import-Package 、Require-Bundle中需要自己new出实例。
在OSGi框架中注册Service方法是这样的：
context.registerService(服务标识名,服务实例,服务实例属性);
方法返回的是ServiceRegistration，可以通过返回的这个ServiceRegistration来卸载这个Service，在stop方法中通过这样的方法来卸载注册的这个Service：
serviceRegistration.unregister();通过这样两个方法后就完成了Service 的注册和卸载。
在OSGi框架中获取Service方法是这样的：
ServiceReference serviceRef = context.getServiceReference (服务标识名);
Object service = context.getService (serviceRef);

[b]4.类加载机制[/b]

[img]http://dl.iteye.com/upload/attachment/0080/5908/e789729a-2032-378f-b3b9-cc712ef29208.png[/img]

图1 OSGi Class loading流程图
如图所示，OSGI框架在加载Bundle 中的类时按照这样的步骤进行：
[list]
[*] 1.如需要加载的为java.*的类，则直接委派给Parent Classloader，如在parent Classloader中找到了相应的类，则直接返回，如未找到，则抛出NoClassDefFoundException。
[*] 2.如加载的不是java.*的类，则进入这一步。判断加载的类是否属于boot delegation中配置的范围，如不属于则进入下一步，如属于则继续委派给Parent Classloader。可在配置文件中编写org.OSGi.framework.bootdelegation的属性来决定boot delegation的范围，示例：org.OSGi.framework.bootdelegation = sun.* ,com.sun . *。
[*] 3. 如属于Bundle Import package中的类，则交给export package的Bundle 的classloader 进行加载，如加载失败，则直接抛出NoClassDefFoundException，如加载成功则直接返回。
[*] 4.如不属于Bundle Import package中的类，则搜索是否属于Require Bundles中export 的package的类，如属于则交由export package的Bundle的Classloader进行加载，加载成功则直接返回，加载失败则进入下一步。
[*] 5.在Bundle classpath(就是在Bundle-Classpath所配置的路径)中搜索需要加载的类，如加载成功，则直接返回，如加载失败则继续进入下一步。
[*] 6.搜索Fragment Bundle的classpath，加载成功则直接返回，加载失败则继续进入下一步。
[*] 7.判断是否属于export 的package，属于则直接抛出NoClassDefFoundException，不属于则进入下一步。
[*] 8.判断是否属于 Dynamic-Import 的package，不属于则直接抛出
[/list]NoClassDefFoundException，属于则使用 export package 的Bundle 的ClassLoader进行加载，加载成功则直接返回，加载失败则抛出NoClassDefFoundException。

[b]5.资源文件加载机制[/b]
对于Bundle 中的资源文件，可使用bundle.getResource、bundle.getEntry 或bundle.findEntries 来获取，返回的为一个可被转变为 java.net.URL 的对象，通过URL就可加载到相应的资源文件，如果要获取到其他Bundle的资源文件则需通过设置Require-Bundle的方式才可获取，Require-Bundle也可视为实现资源文件共享的一种方式，不过Require-Bundle 并不是被推崇的一种方式，在OSGI规范中，认为Require-Bundle会造成 split packages。
注意：split packages是指相同的包同时存在于不同的Bundle中。例如A、B两个Bundle同时输出了com.glodon.utils包，但是里面内容不同，这样对于引用这个包的就只能引用一部分，不能全部引用包中的所有类。使用Require-Bundle方式能够将分布于不同bundle中的同名包合并，因此可以解决split packages，但是同名包存在于多个bundle中是不被建议使用的，因此上文中说在OSGI规范中，认为Require-Bundle会造成 split packages。

[b]6.Bundle的生命周期[/b]
[img]http://dl.iteye.com/upload/attachment/0080/5906/65464127-9d7d-3931-be67-878959df6706.png[/img]

(1)安装Bundle
通过BundleContext的install Bundle 方法来安装Bundle，在安装前首先需要对Bundle进行校验，如校验通过，OSGI框架中将安装Bundle 到系统中，此时OSGI框架会分配一个高于现在系统中所有的Bundle的ID给新的Bundle，安装完毕后Bundle的状态就变为INSTALLED了，同时会返回bundle对象。

(2)解析Bundle
Bundle安装完毕后，OSGI框架将对Bundle进行解析，以检测Bundle中的类依赖等是否正确，如有错误则仍然处于INSTALLED 状态，如成功Bundle的状态则转变为RESOLVED。

(3)启动Bundle
在启动Bundle 前需检测Bundle的状态:
[list]
[*] a) 如Bundle状态不为RESOLVED，那么需要先解析Bundle；
[*] b) 如启动一个解析失败的Bundle，则会抛出BundleException，但此时Bundle的状态仍然会被设置为ACTIVE；
[*] c) 如Bundle的状态已经是ACTIVE，那么启动Bundle对它不会产生任何影响。
[/list]
通过BundleContext的getBundle方法可获取指定Bundle ID的Bundle对象，在获取到Bundle对象后可使用Bundle对象的start方法来启动Bundle，此时会调用MANIFEST.MF中的Bundle-Activator属性(如果存在的话)对应的BundleActivator类的start方法，在start方法执行的过程中Bundle的状态为STARTING，当start方法执行完毕后Bundle的状态转变为 ACTIVE，如start方法执行失败，Bundle的状态转变为RESOLVED。
BundleActivator类不是必须的，建议不要在BundleActivator中初始化过多的东西，这样会使得系统的启动速度会变得很慢，同时也会消耗大量的内存，而且OSGI对于动态性的良好支持使得尽可以在需要的时候才去获取所需的资源。

(4)停止Bundle
通过BundleContext的getBundle方法可获取指定Bundle ID的Bundle对象，在获取到Bundle 对象后可使用Bundle对象的stop 方法来停止Bundle，此时会调用MANIFEST.MF中的Bundle-Activator属性(如果存在的话)对应的BundleActivator 类的stop方法，在stop方法执行的过程中Bundle的状态为STOPPING，当stop方法执行完毕后Bundle的状态转变为RESOLVED，如stop方法执行失败，Bundle的状态则继续保留原状态。即使Bundle 已经停止，其export 的package 仍然是可以使用的，这也就意味着可以执行RESOLVED状态的Bundle 中export package的类。

(5)卸载Bundle
通过调用Bundle对象的uninstall方法可完成Bundle的卸载，此时Bundle的状态转变为UNINSTALLED。即使Bundle 已卸载，其export的package对于已经在使用的Bundle而言仍然是可用的，但对于新增的Bundle则不可使用已卸载的Bundle export的package。在管理Bundle的状态时，OSGI主要是通过Bundle、BundleContext这两个对象来实现，Bundle对象中除了对于Bundle的生命周期管理的方法之外，还提供了象getHeaders、loadClass、getResource 这些方法，getHeaders方法可用于获取MANIFEST.MF 中的属性值，loadClass可用于加载bundle中的类，getResource可用于获取Bundle中的资源文件。

[b]7.Bundle Space && Class space[/b]
Bundle Space包含了与这个Bundle 有关的所有的jar 文件。
Class space 是指通过一个给定的Bundle的Classloader 可以获取的类，对于一个Bundle 而言，它的 ClassLoader能加载的类包括：
[list]
[*] 1) Parent Classloader加载的类。在OSGI的实现中Bundle ClassLoader的Parent ClassLoader通常都是Boot ClassLoader，这里能加载的类通常是java.*；
[*] 2)当前Bundle Imported的packages；
[*] 3)当前Bundle Required的Bundles的类；
[*] 4)Bundle 自己的 Classpath 中的类；
[*] 5)附加的其他的Bundle。(例如：lib包中的)
[/list]

[b]参考文献：[/b]
[list]
[*]1.[url]http://wiki.osgi.org/wiki/Split_Packages[/url]
[*]2. OSGI实战
[/list]