OSGI与Plugin Architecture

大家都知道Eclipse是一个典型的插件系统,而从3.0起其插件体系架构就重构为基于OSGI规范来实现的,从这也可以看出osgi必然与Plugin Architecture是有很多的关联性的,在这里就来说说自己对Osgi R3与Plugin Architecture的关联。
首先还是来说说作为一个Plugin Architecture应该提供哪些功能:
1、插件的定义。
2、插件的加载。(文件、URL等形式)
3、插件的生命周期管理。(安装、卸载、启动、停止、更新)
4、插件间的交互机制。
5、插件的扩展。
从非功能性角度来讲,作为Plugin Architecture应该对原有的非Plugin Architecture的系统的改造不能造成过大的侵入性,还有就是Plugin的管理以及易开发,其次作为Plugin Architecture,其最大的优点莫过于可以保证系统构成了一个平稳的结构体系,所有的交互、扩展都通过Plugin来进行,并同时保证各个Plugin的独立性,使得系统基于一种拼装式的结构(松耦合),每个Plugin对于外部而言都是一个黑盒,那么就要相应的告诉外部这个黑盒所能提供的功能,调用的方式等。
现在来说说OSGI,Osgi规范于1999年开始制定,目前版本是R4,OSGI之前主要用于网络设备的服务架构体系,那是一个典型的松耦合的服务架构体系,在被eclipse引入作为其插件体系架构后OSGI也被业界所关注,R4更是吸取了Eclipse的很多优点修订而成,相对于上面的功能点来说说OSGI对应的规范点:
1、插件的定义。
       OSGI规范中将插件称为Bundle,Bundle作为整个插件的生命周期管理对象,负责插件的启动和停止动作,通过Meta-inf/mainfest.mf来描述Bundle,主要描述Bundle的名称、厂商、版本、对外暴露的包、对外暴露的服务、依赖的插件、引用的包、动态引用的包等,具体可参考OSGI R4中Framework Specification Chapter,插件可通过Bundle对象获取插件的定义信息。
2、插件的加载。(文件、URL等形式)
      OSGI规范中定义通过BundleContext来完成Bundle的加载工作,每个Bundle拥有独立的classloader以及BundleContext。
3、插件的生命周期管理。
      OSGI规范中定义通过BundleContext对Bundle进行生命周期的管理,或通过Bundle本身对象来进行。
4、插件间的交互机制。
      OSGI规范中定义通过插件的定义中定义所需依赖的插件以及所需引用的包来实现插件的交互机制。
5、插件的开发。
      OSGI规范中定义一个新的插件的开发需要的是构成其BundleActivator对象以及完成插件定义的描述。
6、插件所暴露的功能。
      OSGI规范中定义通过在插件定义文件中描述插件所暴露对外的服务来说明插件对外所暴露的功能以及允许外部对此插件引用的包。

对于插件如何扩展OSGI规范中提及的是在修改插件后插件的自动更新以及热加载来实现,而不是象Eclipse的扩展点机制。

根据上面我们可以看出OSGI规范确实非常适用于Plugin Architecture,对应点基本都存在,不过上面只是简单的描述,具体的大家可参看OSGI R4,除了对于Framework的定义,OSGI R4中还定义了一些常用的服务的规范(如log、configuration、security等),而且有Eclipse作为其R4的RI,Eclipse则使得插件的管理、 扩展以及易开发得到了保证,在管理上Eclipse上提供了管理的平台,在扩展上eclipse上提供了扩展点机制,在易开发上eclipse提供了ide,使得插件的代码开发、定义描述、调试甚至部署都变得非常的简单,而且eclipse会根据插件定义文件中需引用的包以及依赖的插件而自动的构造相应的classloader而无需去引用那些lib,这保证了插件的独立性(设计时),呵呵,但大家是不是有发现什么不足点呢?
个人觉得OSGI规范中的不足点是插件的管理机制的定义,插件的管理机制上我觉得可以参考JMX增加一个Connector or Protocol layer plugin,^_^
插件的扩展机制由eclipse弥补了,其他的还真想不出什么不足点了。

突然开始觉得osgi比jmx+ioc实现的plugin architecture更为的好,以前觉得osgi没有jmx+ioc好的原因在于osgi对于插件的独立性保持的不够,意思就是在插件对于外部或其他插件作为黑盒而言,没有明确插件功能的描述以及调用方式的描述,这个怪自己之前对osgi规范看的不够仔细,其实就是service,而在独立性方面以前是想着在代码中如果要直接调用其他插件的service,那岂不是要引用那个插件的包,而这个问题在eclipse ide中是解决了的,只需要在定义文件中定义所依赖的插件即可,而不需要引用那个包,那么这样独立性的问题自然也解决了,还有一个是管理性,在这方面仍然是jmx更为强,不过完全可以在osgi中增加一个admin plugin的实现,吸取jmx在这方面的优点,呵呵,而相比之下现在变成了jmx+ioc并没有一个规范式的体系架构,实现起来只能是各按各的想法,而osgi的话毕竟是个规范,加上已经有eclipse这个现成的,何必再去发明轮子呢,^_^,也许某一天plugin architecture也会被列入jsr规范之中的。

posted on 2005-11-06 20:19 BlueDavy 阅读(4252) 评论(5)  编辑  收藏 所属分类: Plugin Architecture

评论

# re: OSGI与Plugin Architecture 2005-11-10 14:32 勤劳的蜜蜂

非常好的总结和对比,受益匪浅啊!

osgi正在成为jsr(我姑且认为您指的plugin architecture是osgi),看看jsr232和jsr249,尤其jsr249,决定了jsr232的生死。
jsr249好象在年底就要投票,如果jsr232被jsr249纳入,那么osgi的前途是非常光明的......  回复  更多评论   

# re: OSGI与Plugin Architecture 2005-11-10 17:48 Programmer's Life

哦?
呵呵,那肯定是要去看看的,个人觉得osgi要成为plugin architecture的jsr还是有差距的。
以前有个jsr 277..  回复  更多评论   

# re: OSGI与Plugin Architecture 2005-11-10 20:22 勤劳的蜜蜂

是的,jsr277也非常值得关注,好象是java的比较大的变动。277主要是对j2se&j2ee的。象232和249都是对j2me上cdc的jsr,那里被认为是osgi将来大施拳脚的地方,尤其249就是大名鼎鼎的MSA,所以它的最终scope将是java在下一代嵌入式和移动平台上的规范(个人理解,不对请纠正)

说到277还有一个有趣的事情,据说这个jsr是sun抄袭OSGi的想法,可以看看Peter Kriens(他应该是OSGi的spec leader,r4的主要writer)的blog,http://www.aqute.biz,那里讲述了OSGi和几个相关JSR的关系,还有他个人因为jsr277与jcp产生的过节,虽然比较“八卦”,但是让我们看到了技术以外的一些东西。
  回复  更多评论   

# re: OSGI与Plugin Architecture 2005-11-10 23:10 Programmer's Life

哦?呵呵,去关注关注

jsr277好像也是发展N久了.......^_^,jsr 277必然是需要抄袭osgi的
呵呵,原来232和249是j2me上的,那肯定是osgi最擅长的地方了  回复  更多评论   

# re: OSGI与Plugin Architecture 2005-12-01 16:51 Oliver

jsr277应该是刚刚开始。。。主要是SUN拿来compete OSGi的,他们拒绝提起OSGi,是因为SUN想装作“发明”一些东西,而不会象jsr232那样直接拿OSGi来用,否则太没面子了。另外,SUN已经打算把Modularity加入Java language了,这招比较狠。  回复  更多评论   


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


网站导航:
 

公告

 









feedsky
抓虾
google reader
鲜果

导航

<2005年11月>
303112345
6789101112
13141516171819
20212223242526
27282930123
45678910

统计

随笔分类

随笔档案

文章档案

Blogger's

搜索

最新评论

阅读排行榜

评论排行榜