您的位置:知识库 » 软件设计

4大 Java OSGi 框架比较 (Knopflerfish, Apache Felix, Equinox, Spring DM)

作者: 浪客Dandy  来源: 博客园  发布时间: 2010-10-01 00:10  阅读: 11683 次  推荐: 0   原文链接   [收藏]  
摘要:OSGi正在成为一种趋势,越来越多的项目采用了OSGi,越来越多的中间件都开始采取了OSGi的标准,它致力于提供给Java项目一个模块化的底层环境,以及一系列通用的服务(Service)。

      OSGi正在成为一种趋势,越来越多的项目采用了OSGi,越来越多的中间件都开始采取了OSGi的标准。身为一名Java开发人员,如果你还对OSGi结构一无所知,那你真的有点Out了。

      什么是OSGi

      OSGi的名称来源于其开源组织的名称Open Services Gateway initiative,OSGi是一个标准,它致力于提供给Java项目一个模块化的底层环境,以及一系列通用的服务(Service)。和普通的JVM程序相比,OSGi的程序天生拥有动态模块的特点,不同的模块(OSGi里称之为Bundle)有着独立的生命周期,可以独立进行安装、启动、停止、卸载的操作,模块间的依赖性管理也由OSGi提供。你可以看出,OSGi非常适合需要进行Plugin管理的项目,一个典型的成功案例就是Eclipse和它众多的Plugin。OSGi标准还规范了一系列我们常间的操作,日志、配置文件、事件队列、Web开发、JPA&JDBC等等,大部分部署OSGi标准的框架都提供了这些服务,这样一方面规范了我们代码的结构,一方面节约了我们开发的时间。

      目前基于OSGi的框架大概有4个:Knopflerfish, Apache Felix, Equinox, Spring DM。因为都是基于OSGi标准的,他们的大致用法和核心功能是一致的。一般来说一个OSGi的组件(Bundle)可以轻易的从一个框架迁移到另一个框架。框架的不同主要是体现在他们本身的设计和额外的服务上。根据我的一些经验,对这4个框架进行了一下比较,希望对刚接触OSGi或是由于如何选择OSGi框架的人有所帮助。

      Apache Felix 最全面的框架

      Apache Felix是Apache旗下的一个OSGi框架,项目本身非常成熟,已经被用到了很多其他的项目中,例如Apache Servicemix。它本身提供的服务也是最全的,几乎涵盖了全部的OSGi 4.2的标准。除此之外还提供了一些非标准的功能,例如iPOJO。框架本身非常紧凑,你只需要3个包加一个shell就可以运行了,无论是开发还是Debug都非常简便。除了Felix,还有两个项目是和OSGi相关的。一个是Apache Felix Karaf,它本身是Felix的一个子项目,但他其实是封装了Felix提供更高一层的Runtime,例如提供了JAAS。另一个是Apache Aries,目前还处于起步阶段,它作为Felix的补充,提供OSGi企业级规范,包括JPA、JDBC、JTA、JNDI等等。

     总的来说,Apache Felix是我个人推荐的最佳OSGi框架,它简单的结构也更适合出学OSGi的开发人员。

     Equinox 与Eclipse完美结合

     Equinox是Eclipse旗下的OSGi框架,本身也被Eclipse采用,是Eclipse注明的PDE开发环境的底层。Equinox本身也是相当的全面的框架,提供的功能不比Felix少多少。但是它功能的分类就稍显混乱,文档和Sample也组织的不是很好。事实上相当Equinox还是被当做开发Eclipse Plugin的应用较多,如果你要开发一个Web程序,你就会感到它本身的功能和文档不够全面。Equinox最大的优势在于它和Eclipse结合紧密,只要你安装了PDE,你就已经有了Equinox,可以方便的在Eclipse里设置你开发的Bundle,启动、部署等操作也异常简单,而且有专门的Debug界面,你还能要求什么呢?

      如果你想基于Eclipse开发,Equinox无疑是好选择。但对于新手而言,有时候会搞混Eclipse Plugin与OSGi的关系。

      Spring DM 畸形的需求产物

      Spring DM是Spring旗下的OSGi框架,Spring我想大家都知道了,Spring DM的最大特点就是结合了Spring框架。我之所以说特点还不是优势,是因为我认为这个需求本身就是错误的。Spring和核心就是一个IoC,当然后来它的外延扩大了,提供了越来越多乱七八糟的功能。OSGi规范本身就制定了一系列IoC的功能标准,尤其是其中的BluePrint其实相当多的借鉴了Spring,因此完全没有必要再引入Spring充当新的IoC了。Spring本身无论是ClassLoader还是配置文件上都与OSGi格格不入,之所以有这种需求是因为现在有大量基于Spring的项目想要过渡到OSGi上。Spring还发布了一个App Server叫Spring DM Server,是一个基于Spring DM的App Server,你会发现你需要加载80+的包来完成一个hello world操作,这种恐怖的依赖性正是Spring所带来的。

      意识到这个问题的显然不只是我一个人,传闻Spring DM和Spring DM Server都将会移交给Eclipse。就目前来说除非你有基于Spring项目的移植需求,我不推荐其他任何情况下使用Spring DM。

      Knopflerfish 孤独孤傲

      Knopflerfish其实是OSGi的先行者,但是由于没有强力的靠山,再后来的竞争中显然不如前三者有人气。它本身是一个相当标准OSGi框架,提供了绝大多数标准功能,但是无论在人气上,开发进度上,文档完善上都不如其他的三者。

      既生瑜,何生亮阿~

0
0
标签:OSGi Java

软件设计热门文章

    软件设计最新文章

      最新新闻

        热门新闻