OSGI框架学习

OSGI框架三个重要概念

OSGi框架是根据OSGi规范中定义的三个概念层设计的：模块、模块生命周期、服务。

模块层定义了OSGi模块的概念（bundle，即包含一个元数据MANIFEST.MF的JAR文件）。

bundle比标准JAR文件更强大，它可以声明哪些包对外可见（Export-Package）；所以说它扩展了Java的访问修饰符。

bundle还可以明确声明依赖哪些外部包（Import-Package），这样就可以自动地管理和验证依赖包的一致性（这个过程称为bundle解析），确保了bundle版本和其他方面约束的一致性。

基于已有的JAR文件构建OSGi bundle是一个非侵入式的过程，只需要添加MANIFEST.MF。

生命周期层定义了在OSGi框架中是如何动态安装和管理模块的。在应用程序外部，生命周期层精确地定义了bundle生命周期的操作（安装、更新、启动、停止、卸载），使得你可以用一种明确的方式动态地提供、管理、改进你的应用程序，意味着可以安全滴在框架中安装和卸载bundle，而不用重启应用程序。在应用程序内部，生命周期层定义了bundle如何访问它的执行环境。

服务层支持和促成了一个灵活的应用编程模型。涉及面向服务的发布、查找和绑定的交互模式：服务提供者将服务发布到服务注册中心，服务客户端搜索服务注册中心，查找可供使用的服务。

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

来源： http://kb.cnblogs.com/page/76131/

来自为知笔记(Wiz)