什么是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框架，提供了绝大多数标准功能，但是无论在人气上，开发进度上，文档完善上都不如其他的三者。