Equinox动态化深入分析

   OSGi最吸引人的特性除了模块化之外,就是动态化了,在我之前写的OSGi实战以及进阶两篇Opendoc中,都有相关的示例,但不知道大家有没有注意,在两篇Opendoc中都未提及到bundle本身的更新,而基本都是以新增服务实现的bundle以及停止服务时限的bundle为例,并且相对而言是个比较简单的例子,动态化在java界更明确的词也许是hot deployment,而hot deployment的实现并不容易,同样,即使你采用OSGi,但也不代表你的应用就具备了hot deployment的能力,在hot deployment上,完美的结果就是当更新完成后,新的执行请求就在新的代码逻辑上正确的执行,就像没发生过更新这回事样,但实际要做到这样的效果,远没这么容易,即使是基于OSGi也同样如此,No magic & no silver bullet,在本篇blog中我们就来具体的看看。

    OSGiBundle为粒度来实现动态化,也就是说,如果要更新一个类,需要做的是更新整个Bundle,虽然比直接部署一个类麻烦了点,但也还算是不错的了,更新的方法有两种,一种是直接updatebundle(在MANIFEST.MF中增加Bundle-UpdateLocation来指定Bundle更新时所使用的文件);另外一种是先uninstall旧的bundle,然后再安装并启动新的bundle,无论是哪种方法,对于OSGi的应用而言,问题就在于package的类的改变以及bundleOSGi服务实现的改变。

    Equinox中,当update一个Bundle时,如果这个Bundle中有对外暴露的package,如果这个Bundlesingleton模式,在update后仍然保留了同样的Bundle SymbolicName的话,其实是无法update成功的,会报出一个已经有相同的SingletonBundle存在,因此update这种方法仅适用于没有对外暴露packagebundle,如bundle没有对外暴露的packageEquinox则可正常的完成update过程,通常来讲,不对外暴露packagebundle都是一些对外暴露OSGi服务或者使用OSGi服务的类,对于对于暴露OSGi服务的类而言,在update过程中将会把依赖了此OSGi服务的OSGi组件的实例销毁(递归),等当前bundle更新并启动完毕后,会重新实例化该OSGi组件,同时将新的服务实现对象设置进去,对于仅使用其他Bundle提供的OSGi服务的类而言则很简单了,在启动此bundle时自然会设置进来,同时也不会影响外部bundle

    从上可见,通过update方式来完成Bundle的更新受到了很大的限制,毕竟大部分时候Bundle都是singleton的,并且在更新的时候也是不会去改变其Bundle SymbolicName

    因此,在Equinox中要实现Bundle的更新,通常都使用另外一种方法,就是uninstall,然后再installstart更新后的bundle

    uninstall时,如果此bundle有对外暴露的package,并且有使用这些packagebundle,那么Equinox会保留此Bundleclassloader,也就是说原来使用了这些packagebundle仍将使用之前bundle的类,这也是为什么一个Bundle uninstall了之后,其他Bundle仍然可使用该Bundleexport的类,要想让Bundle对外exportpackage的引用也失效并且切换到新的bundleexportpackage,必须执行refresh动作,refreshequinox将会找到之前uninstall没完全成功的bundle,并递归找到使用了这个bundlepackagebundle,将这些bundle的状态也置为unresolve,并解除对之前uninstall没完全成功的bundleclassloader的引用,这样被uninstallbundleclass就能被GC卸载了,在此之后,Equinox会尝试再次去resolve之前设置为unresolvebundle,如果resolve不了则会调用这些bundlestop方法,卸载其对外提供的OSGi服务以及引用的OSGi服务,同时将其状态置为INSTALLED;但在uninstall时,对OSGi服务的处理方法则不太一样,此Bundle中所引用的OSGi服务会被释放,对外提供的OSGi服务也会注销,这会造成引用了这些OSGi服务的BundleOSGi组件(递归)的实例会被销毁。

    完成了以上的动作后,可以安装新的bundle,安装新bundle时,其实就是做了些解析bundle的事情,直到start bundle时,才开始resolve过程,所谓resolve就是找到bundle对外提供的package、需要引用的package等,同时创建bundleclassloader,在这个过程,equinox也会对系统中所有unresolvedbundle进行resolve,如能够resolve则将其状态转化为resolved,最后调用BundleContextstart来完成bundle的启动,这个过程仅仅是在配置了BundleActivator的情况下才有意义,DS则完成此bundle中引用的OSGi服务或对外提供OSGi服务的组件的条件的检测,以判断这些组件是否可实例化,如有新的OSGi服务可对外提供,那么DS会检测此时其他Bundle中的OSGi组件是否需要被激活,或者是否需要调用其他BundleOSGi组件的set方法。

    根据以上这样的描述,可以看出,在OSGi中如果要更新没有对外提供packageBundle是比较容易的,update以及uninstallàstart都是可选的方法,而对于对外提供了packageBundle而言,则相对复杂很多,只能选择uninstallàrefreshàstart来完成。

    从两个纬度来看OSGi的动态化,对于有export-package Bundle的更新,OSGi将会重建更新的bundle以及引用了此bundlepackageClassLoader,而对于OSGi服务组件的更新,OSGi则会重新创建引用了此OSGi服务的组件的实例,并通过unset这样的方法通知原来的组件释放对OSGi服务的引用,同时通过set方法来给新创建的实例注入更新后的OSGi服务组件实例,其实这也是hot deployment中常见的对于引用变更的处理方法。

    但从上面也可以看出,OSGi并没有提供对象状态保留的处理,这也就意味着,基本上在一次更新后,此次更新的Bundle以及相关的bundle因为classloader的重建,其对象的状态数据都丢失了,不过对于更新的仅为提供或引用OSGi服务的Bundle而言,则稍微好点,毕竟只是影响到了递归的引用了OSGi服务的组件,组件由于重建实例,而导致状态数据丢失,这个倒是可以通过将服务的引用数量设置为cardinality=”0..1”cardinality=”0..n”来解决,设置成这样的条件后,即使引用了需要更新的Bundle中提供的OSGi服务,其OSGi服务组件实例也不会被重建,这对于需要将OSGi服务引用提供给外部使用的系统而言,无疑非常有帮助。

    根据以上所述,可以看到,即使是基于OSGi,要实现hot deployment还是比较麻烦的,No magic and no silver bulletJ,尤其是要注意classloader的重建以及OSGi服务组件实例的重建,否则很有可能会造成在更新后系统的异常,在基于OSGi实现hot deployment时,要合理的规划系统,常见的一些较好的实践方法有:

l  接口和实现分离

避免因为实现逻辑要更新,而造成其他引用了此Bundle export出去接口所在的package而导致classloader的重建。

l  对于需要保留状态数据的OSGi服务尽量避免引用其他bundle export-package中的类

这也是为了避免这些类所在的bundleclassloader重建,毕竟OSGi服务组件类可以通过设置cardinality来保持组件实例的不变。

l  服务组件采用cardinality=”0..1”cardinality=”0..n”来设置对OSGi服务的引用

避免服务组件实例的重建,毕竟这是个递归过程,影响还是很大的,而且谁也不敢肯定这么多的服务组件实例的重建是不是会造成系统的异常现象。

在这种情况下,尤其要注意unset中的处理以及当没有可用服务情况下的处理,避免出现NPE

l  尽量采用OSGi服务组件服务方式,而不是直接的类方式

由于类方式的更新成本实在是比较的高,毕竟那需要classloader的重建,但是有些类确实是没办法的,对于这些类要尽量的保证稳态。

l  严格的版本控制

毕竟接口的更新影响是很大的,因为所有实现接口的类都得改变,因此需要严格的制定版本规范,并在引用package时按照版本规范指定相应的版本范围。

 

广告时间:在我和一位同事的新书《OSGi原理与最佳实践》中会更加详细的分析equinoxfelixOSGi框架在模块化、动态化方面的实现方法,并会给大家推荐一些比较好的实践。

posted on 2009-04-29 21:00 BlueDavy 阅读(6739) 评论(10)  编辑  收藏 所属分类: OSGi、SOA、SCA

评论

# re: OSGi动态化深入分析 2009-04-30 15:46 Hugo

如果按先Install新的,start后再Uinstall老的会不会有问题?  回复  更多评论   

# re: OSGi动态化深入分析 2009-04-30 15:49 BlueDavy

@Hugo
start不了新的,详细原因在文中已经讲了。  回复  更多评论   

# re: OSGi动态化深入分析 2009-04-30 16:37 Hugo

我用Felix可以同时start两个相同的SymbolicName的Bundle,只要Bundle-Version不同就可以了。  回复  更多评论   

# re: OSGi动态化深入分析 2009-04-30 17:12 cROSSaGE

新书合时会出?
很感兴趣,必买.  回复  更多评论   

# re: OSGi动态化深入分析 2009-04-30 17:49 BlueDavy

@Hugo
恩,那看来felix这点的实现上比equinox好,我这篇blog是针对equinox说的,不过理论上来讲,同时启动两个同样symblicName的singleton的bundle是有点问题的。  回复  更多评论   

# re: OSGi动态化深入分析 2009-04-30 20:51 YuLimin

在install & uninstall这空中的缝隙时间内的业务处理是根据什么样的策略来实现的?是直接抛错?还是等待?还是。。。?  回复  更多评论   

# re: OSGi动态化深入分析 2009-05-01 08:40 yuping322@gmail.com

所有的替换都强制规定以bundle为最小单位,要替换时,先加实现接口的新的bundle进去,启动该bundle,该接口实现的类有两个,停止原来的那个,新的自然会补充上。

这样行不?  回复  更多评论   

# re: OSGi动态化深入分析 2009-05-01 14:05 BlueDavy

@YuLimin
在升级的过程中只能是抛错了。

@yuping322@gmail.com
已经说过了,如果是bundle是singleton的话,在equinox中是没法在不uninstall之前的bundle情况下安装的,不过据之前hugo的说法,在felix中应该可以。
  回复  更多评论   

# re: Equinox动态化深入分析 2009-06-08 15:44 luguo

《OSGi原理与最佳实践》啥时候出版?  回复  更多评论   

# re: Equinox动态化深入分析 2009-06-08 16:55 BlueDavy

@luguo
预计在9月中下旬上市。  回复  更多评论   


只有注册用户登录后才能发表评论。


网站导航:
 

公告

 









feedsky
抓虾
google reader
鲜果

导航

<2009年4月>
2930311234
567891011
12131415161718
19202122232425
262728293012
3456789

统计

随笔分类

随笔档案

文章档案

Blogger's

搜索

最新评论

阅读排行榜

评论排行榜