OSGi与Spring的整合 - 发现之旅

        对于我这个文字水平不佳的人来说，能坐下来写博而不是下棋，应该算是一种不容易的选择。权当平时学习的笔记。
        前不久学习 JPF（Java Plugin Framework）时，发现其功能实现不是太理想而且在和Spring整合时有不少问题要解决，无意中搜索到 OSGi（ Open Services Gateway Initiative），简单了解之后发现OSGi的强大与美妙之处。于是决定抛弃JPF，改用OSGi。
        Spring就不多费口舌了，这里简单介绍一下JPF和OSGi。谈起这二者，不得不提及大名鼎鼎的Eclipse，因为它们都与Eclipse有些渊源。
        Eclipse作为一个功能强大、操作方便的IDE，估计大家都不陌生。早期版本的Eclipse被设计为插件集合，采用自己的插件系统来启动和管理插件 间交互。但是，随着其IDE功能的加强，原有框架渐渐有些力不从心，采用一个更强壮的解决方案迫在眉睫。此时OSGi框架已经逐步发展起来，经过大量研究 之后，Eclipse创建者决定通过实现OSGi框架规范来替换原有的插件框架。现在的3.x版本的Eclipse就采用了OSGi框架。另外 Eclipse实现并扩展了OSGi的R4规范，作为一个单独的项目供我辈中人使用，它就是 Equinox。
        说完了Eclipse，该表一表JPF了。JPF借鉴了Eclipse早期的插件框架思想。它提供一个运行时引擎，可以动态发现并运行插件，从而为项目提 供一个标准的插件基础设施。JPF通过一个注册表来注册插件并管理其功能，插件之间可以通过继承来扩展原有插件功能，这一点和Eclipse是一致的。但 总体感觉JPF框架提供的功能有些简单。
        下面亮相的就是我们的主角 —— OSGi，这是一位命运多桀的英雄。OSGi是一个1999年成立的有关Java和机顶盒的标准化协议组织。它最初定位于嵌入式系统开发，但由于当时嵌入 式JVM还不成熟，所以它并没有被广泛应用。在这几年的漫长岁月中它从默默无闻到逐渐涉足移动和汽车应用，乃至现在的中间件领域。随着Java技术的成 熟，OSGi也得到了越来越广阔的发展。是不是从OSGi看到了当年Java的影子？！
        OSGi是一种服务运行平台，通过部署和扩展符合其规范的插件来提供所需功能，从而搭建起一个高效、稳定、安全、灵活的应用系统。插件在OSGi中称为 Bundle，它是一个独立的jar包，包含了其所需要的所有资源，包括但不限于所需的类、API文档、图片和国际化消息资源。由于可以动态的安装、卸 载、运行和停止组件，OSGi实现了可拔插的软件系统，并为系统在运行期提供了足够的灵活性、扩展性和高效性。另外基于OSGi的系统由于采用的是微内核 机制，所以保证了系统的稳定性。
        Bundle使用元数据文件描述（MANIFEST.MF）来声明其导入、导出的类包以及和其他Bundle之间的依赖关系。每一个Bundle都有自己 独立的类加载器（Fragment Bundle除外），从而保证了其安全性和独立性。这也是OSGi之所以成功的很重要的因素。
        关于这几种技术先聊这么多，更多的资料可以到OSGi的官方网站获取。目前OSGi的最新规范是R4版本，参考实现有Equinox、 Knopflerfish，另外还有基于R3的实现 Oscar。