初探 OSGi

初次接触OSGI还是在去年刚进公司的时候，那时候第一次听到了OSGI的框架，去看了下感觉挺好玩的，不过就看了一阵也就放下了，我记得当时主管还说了我一次，因为有点不务正业，感觉那时候还没怎么用得上这个技术。过了小半年，到了现在OSGI已经成为我们这边的一个比较红火的词汇，可能是因为上次在B2B那边的技术分享上提到了一种分布式解决方案中提到了，感觉也是一个流行趋势，所以就开始重视起来了。

      什么是OSGI呢？OSGI —— Open Service Gateway Initiacive 字面上的意思是一个公共的服务平台。1999年OSGI联盟成立，它是一个非盈利的国际组织，旨在建立一个开放的服务规范，为通过网络向设备提供服务建立开发的标准，是开放网关的发起者。早期的OSGI的设计是针对嵌入式应用的如机顶盒、手机、汽车等都是其应用的环境。后来，由于OSGi 的诸多优秀特性（可动态改变系统行为，热插拔的插件体系结构，高可复用性，高效性等等），它被应用于许多PC 上的应用开发，因此逐步为开发者所知和钟爱。现在人们对OSGi 的理解已经远远不是它字面和初衷所能解释的了，称其为一个轻巧的、松耦合的、面向服务的应用程序开发框架还是更为确切一些。

          OSGI框架图如下：
          

  其中OS 层和JVM 层可以不用详细介绍了，重点需要关注的是应用程序Bundles 层。框架本身提供的类加载，生命周期管理，服务注册和规范服务也都是针对Bundles 的。每一个在OSGI框架中运行的逻辑单元称为Bundle，Bundle实际上是一个符合特定格式的jar文件。每一个Bundle的功能可以是抽象也可以是具体的，所谓抽象，就是它不是一个具体的应用，没有完成一些业务功能，而只暴露了一些接口或者功能给其他的Bundle 使用；所谓具体，就是该Bundle 可以独立的完成一个功能，例如连接数据库，获取数据等等。

     Bundle具有6种状态，分别是：

        installed——Bundle 正在被启动

        resolved——依赖关系满足，即该Bundle 要么是准备好运行了，要么是已经被停止了

        starting——Bundle 正在被启动

        stopping——Bundle 正在被停止

        active——Bundle 被激活，正在运行中

        uninstalled——Bundle 被卸载了

  OSGI有他自身的类加载机制，从而控制这些加载的Bundles之间的依赖关系，而生命周期管理也是OSGi 的一大亮点，由于可动态的对这些加载的Bundles 进行安装、卸载、启动、停止等操作，所以可以动态的改变应用程序的运行状态。当一系列的Bundles 存在于服务器中的时候，那么它们之间必然会存在通信协作的部分，比如说一个通过网页捕获用户输入的Bundle 执行的时候，它必须首先需要一个Web 服务器服务的支持，那么这个时候服务注册器就会从整个OSGi容器中寻找这个服务，如果能完成服务的匹配，那么相应的功能就会很自然的实现了。OSGi 规范还规定了一组预设的服务，包括日志、服务管理等等，这些服务在主流的开源框架中都有实现。OSGi 框架中还包括一个安全层，OSGi 的安全层扩展了Java 的安全机制，增并加了一些新的约束以填补了Java安全机制中的遗漏。