OSGI简介

OSGI简介

        OSGi(Open Service Gateway Initiative)技术是面向Java的动态模型系统。OSGi服务平台向Java提供服务，这些服务使Java成为软件集成和软件开发的首选环境。Java提供在多个平台支持产品的可移植性。OSGi技术提供允许应用程序使用精炼、可重用和可协作的组件构建的标准化原语。这些组件能够组装进一个应用和部署中。 

        由于OSGI的诸多优秀特性（可动态改变系统行为，热插拔的插件体系结构，高可复用性，高效性等等），它被应用于许多PC 上的应用开发，因此逐步为开发者所知和钟爱。现在人们对OSGI的理解已经远远不是它字面和初衷所能解释的了，称其为一个轻巧的、松耦合的、面向服务的应用程序开发框架更为确切一些。

        OSGI发展到今天已经得到了众多企业、厂商、开源组织的支持，主流的Java 应用服务器（Oracle 的Weblogic、IBM的Websphere 及Sun 的Glassfish等)都已经采用了OSGI。OSGi 作为Java 模块化标准已成为事实。

OSGI著名案例

        Eclipse作为Java业界成功的IDEproject，在3.0以前的版本它采用的是自己设计的一套插件体系结构，而Eclipse的插件体系结构在整个业界都是非常知名的，也是被认为非常成功的一种设计，但Eclipse在3.0版本时却做了一个重大决度，就是推翻它自己以前的插件体系结构，采用OSGI作为其插件体系结构。Eclipse之所以要抛弃自己那套已经比较成熟的插件体系结构而转而采用OSGI，就是因为OSGI的规范性以及OSGI对于插件体系结构更为完整的定义，Eclipse采用OSGI作为其插件体系结构的成功是很明显的，在Eclipse 3.1版本以后大家可以明显的感觉到启动速度的提升，同时也使得可以在运行时对插件进行管理，更明显的提升是插件的开发更加的规范，从而可以使用很多已有的OSGI插件。 

       BMW汽车的应用控制系统采用OSGI作为其底层架构，很多人都认为基于java的系统低效，不可能用于汽车这样的应用控制系统上。这套系统主要用来控制汽车上的音箱、灯光等等设备，总共由1000多个Bundle构成，但BMW汽车的应用控制系统启动时间却只需要3.5秒，这也从很大程度上反应了采用OSGI的系统的效率并不会低。

OSGI优点


      1、基于OSGI 的应用程序可动态更改运行状态和行为。在OSGI框架中，每一个Bundle 实际上都是可热插拔的，因此，对一个特定的Bundle进行修改不会影响到容器中的所有应用，运行的大部分应用还是可以照常工作。当你将修改后的Bundle再部署上去的时候，容器从来没有重新启过。这种可动态更改状态的特性在一些及时性很强的系统中尤其重要。

      2、它是一个稳定高效的系统。OSGI是一个微核的系统，所谓微核是指其核心只有为数不多的几个jar包。基于OSGI框架的系统可分可合，其结构的优势性导致具体的Bundle 不至于影响到全局，不会因为局部的错误导致全局系统的崩溃。

      3、可复用性强。OSGI框架本身可复用性极强，很容易构建真正面向接口的程序架构，每一个Bundle 都是一个独立可复用的单元。 


OSGI缺点

       1、管理端不够强大，目前OSGI框架提供的管理端不够强大，现在的管理端中仅提供了基本的Bundle状态管理、日志查看等功能，像动态修改系统级别的配置(config.ini)、动态修改Bundle的配置(Manifest.mf)、启动级别等功能都尚未提供，而这些在实际的项目或产品中都是非常有必要的。 

       2、采用OSGI作为规范的模块开发、部署方式自然给现有开发人员提出了新的要求，需要学习新的基于OSGI的开发方式

Bundle的概念

        在OSGI框架中是采用Bundle的方式来组织和部署系统。 

        Bundle其实就是一个jar文件，这个jar文件和普通的jar文件唯一不同的地方就是Meta-inf目录下的MANIFEST.MF文件的内容，关于Bundle的所有信息都在MANIFEST.MF中进行描述，可以称它为bundle的元数据，这些信息中包含有象Bundle的名称、描述、开发商、classpath、需要导入的包以及输出的包等等。 

        Bundle是个独立的概念，在OSGI框架中对于每个Bundle采用的是独立的classloader机制，这也就意味着不能采用传统的如引用其他Bundle的工程来实现Bundle间的协作了，那么在OSGI框架中Bundle之间是怎么协作的呢，在OSGI框架中对于每个Bundle可以定义输出的包以及引用的包，这样在Bundle间就可以共享包中的类了，尽管这样也可以直接实现简单的Bundle的协作，但在OSGI框架中更加推荐的是采用Service的方式，Service-Oriented的概念(例如SOA)大家都接触多了，OSGI框架也同样是如此的，每个Bundle可以通过BundleContext注册对外提供的服务，同时也可以通过BundleContext来获得需要引用的服务，采用Service-Oriented的方式可以使得对外提供的服务能够更加的封闭，不需要为了使用别的Bundle提供的Service而做环境依赖等的设置，同时，Bundle还可以采用Require-Bundle的方式来直接引用其他的Bundle(相当于引用其他Bundle的工程或jar)。 

主要的开源OSGI框架

Equinox
        最知名，也是更新最频繁的，由于Eclipse 基金的支持，其功能越来越完善，实现了OSGi R4 规范，并提供很多平台性质的服务，包括：常用功能模块、日志模块、Web服务器模块、Servlet 模块、JSP解析模块等等。由于其与Eclipse 的天然联系，使得开发基于Equinox的应用程序变得很简单。Eclipse 3.1 之后的版本，Eclipse 本身就已经包含了Equinox。

       遵循EPL (The Eclipse Public License)，任何扩展自Eclipse源码的代码也必须是开源的,商业软件可以使用，也可以修改代码，但要承担代码产生的侵权责任。

Knopflerfish

       很早的，也很优秀的一个OSGI框架，也实现了OSGI R4 标准。该项目的宗旨在于创建一个易于开发的OSGI平台，与Equinox 不同之处在于它本身提供一些小应用实例，包括一个可视化控制台等，也提供基于Eclipse 的插件。
       遵循Knopflerfish License (BSD-esque) http://www.knopflerfish.org/license.html
       商业软件可以使用，也可以修改使用BSD协议的代码。

Felix
       很新的一个OSGi 框架，社区很活跃，更新频率高，是Apache 的开源项目。该项目2007年8月才出1.0 版，也实现了OSGiR4 规范，也提供相关的基础服务和扩展服务功能。
       Felix也有了Eclipse集成支持，开发者可以在Eclipse IDE里运行Felix。
       Felix组件按照Apache软件许可证2.0（Apache Software License Version 2.0）来发布许可。
       Apache Licence也是对商业应用友好的许可。使用者也可以在需要的时候修改代码来满足需要并作为开源或商业产品发布/销售。商业软件可以使用，也可以修改使用Apache协议的代码。


与流行框架的结合

       Spring-DM 指的是Spring Dynamic Modules。Spring-DM 的主要目的是能够方便地将Spring 框架和OSGi 框架结合在一起，使得使用Spring 的应用程序可以方便简单地部署在OSGi 环境中，利用OSGi框架提供的服务， 将应用变得更加模块化。