OSGI

学着学着classloader，一不小心变了个道，到osgi的行车道上来了，呵呵。

 

首先，什么是OSGI？为什么会有这个东西，存在的意义和价值是什么？

• 因“模块化”而生；
• 其可将应用程序劈分为多个模块单元，这样就可以更容易地管理这些模块单元之间的交叉依赖关系，做个性化定制等；
• OSGI，可理解为容器/环境/框架/规范；
• 例如，可以这么理解，一种服务运行平台。通过实现能够提供服务的符合OSGi规范的组件，用户可以将其组件发布到OSGI运行平台，供用户和其他组件使用。OSGI组件提供的服务具有两个层面的含义：系统层面，即一个组件为其他组件提供服务，这些服务体现为Java接口的实现；业务层面，即一个组件为外部系统或用户提供某种业务服务实现。

 

OSGI提供的功能：

我们将OSGi运行平台与常用的Web应用服务服务器做一个比较，来看OSGi提供的功能。首先，以tomcat为例，在tomcat容器中可以运行多个Web应用，假设存在两个Web应用A和Web应用B，一般说来，Web应用A和B具有各自的运行空间，两者之间不存在任何关联，A和B具有自己独立的生命周期，如部署、启动、停止和卸载等。

那么，是如何做到这一点的呢？很明显，这是通过JVM的类加载机制决定的。当tomcat运行并启动Web应用A和B时，tomcat为Web应用A和B各自构建了一个类空间，也可以看作是一个类域（Class Domain），Web应用A的类域包括JRE中的类，tomcat启动类路径上的类和Web应用A中WEB-INF目录下classes目录下的类和lib中的jar包；同样，Web应用B也有自己独立的类域，其范围除了JRE中的类，tomcat启动类路径上的类之外就是自己内部WEB-INF目录下classes目录下的类和lib中的jar包。现在提出一个问题，如果Web应用A需要使用Web应用B提供的Java类，怎么办？实现方式有多种，一种是将B提供的类打包，放置到应用A的WEB-INF/classes或WEB-INF/lib中；也可以将B提供的类放置到tomcat的类路径上，甚至是JRE的扩展目录下，但这样做在实际使用中或多或少存在一些问题。能不能在运行时Web应用A可以直接使用Web应用B提供的类呢？在运行时Web应用B能不能提供一个接口的实现，即类实例，由Web应用A使用呢？能不能提供一个应用C为应用A和应用B提供服务呢？显然，这些对于Web容器是不行的。

带着上述问题我们回到OSGi运行平台。可以将OSGi看作是Web容器的泛化，是更高级别的抽象。运行在OSGi环境中的类似于Web容器中的Web应用的组件即Bundle，不再仅仅局限于一个业务应用的概念，它的粒度更加精细，即可以看作是一个Jar包，为其他Bundle提供帮助类；也可以是一个HTTP服务组件，为其他Bundle提供http服务；还可以是一个Web容器，为其他Bundle提供Web应用服务。

那么，能不能解决上述提到的问题呢？我们假设在OSGi运行平台中包含了3个Bundle：A、B和C。对于问题一：Bundle A需要使用Bundle B中的某些实现类，如何实现？可以将Bundle B中的这些类通过Bundle B的元数据描述信息公开（Export）出去，使得这些类对OSGi平台中的所有Bundle可见，这些类资源仍然位于Bundle B中。Bundle A在其元数据描述信息中将Bundle B公开的类引入（Import）进来。在运行时，Bundle A就可以使用Bundle B提供的这些类，而不是需要将这些类拷贝到Bundle A中或其他位置。对于问题二：Bundle A可不可以直接使用Bundle B在运行时构建了类实例？Bundle B在运行时可以将Bundle A需要的类实例注册到OSGi运行平台的服务注册表中，类实例实现的接口可以通过上述问题一的方式使得Bundle A可见，那么，在运行时，Bundle A就可以通过该接口到OSGi平台服务注册表中查找Bundle B中提供的接口实现类实例，并调用该接口上的方法。现在来看问题三：Bundle C能不能为Bundle A和Bundle B共享呢？可以将上述问题二的解决方案中的Bundle B提供的接口定义提取到Bundle C中，并在Bundle C的元数据中公开，通过在Bundle A和Bundle B中同时引入Bundle C中发布的接口，Bundle B提供该接口的实现，Bundle A使用该接口实现提供的功能。这一切看上去是不是解决的非常完美呢？！

 

模块化（bundle的概念）

bundle，和普通的jar文件没有什么区别，只是多了一个MANIFEST.MF原数据文件来描述bundle的一些信息、依赖、行为等。

 

OSGI实现机制

从本质上说，OSGi是充分使用了Java的类加载机制，对模块和应用进行了更加精细粒度的控制，然后在类域上建立一系列松耦合应用。OSGi为每一个Bundle组件定义了一些元数据信息，通过这些元数据，OSGi在运行时为每一个Bundle构建了一个独立的类域（即类空间）。

 

OSGi中的重要元素就是Bundle 和Service，Bundle提供了一种静态资源边界，类似于Web容器中的Web应用的概念。

每一个Bundle通过一个元数据文件（MANIFEST.MF）描述。OSGi框架（即SystemBundle）通过解析这个元数据文件对该Bundle进行加载和管理。Bundle通过元数据中的"Export-Package"属性将内部的类包发布给OSGi系统中其他Bundle使用，通过"Import-Package"，"Requie-Bundle"属性引用OSGi系统中其他Bundle发布的类包。

每一个Bundle有自己独立的类加载器（Fragment Bundle例外，其资源通过其Host Bundle加载），Bundle内部的资源（类，文件等）通过该类加载器查找和加载。Bundle的类加载器能够控制的类加载边界包括：启动类路径上的类资源，OSGi框架即SystemBundle上的类资源和Bundle内部的类资源。该类资源边界即形成该Bundle的类域。

每一个Bundle在OSGi框架中具有自己的生命周期，其生命周期内的状态包括：INSTALLED、RESOLVED、STARTING、ACTIVE、STOPPING和UNINSTALLED。

• INSTALLED状态是Bundle的初始状态，当该Bundle部署到OSGi系统的Bundle Repository中时，Bundle的状态标记为INSTALLED。
• Bundle内部的资源在加载之前，首先由OSGi框架对其进行解析（Resolve），解析的过程就是分析Bundle的元数据的过程，详细过程参考OSGi规范。解析后的Bundle进入RESOLVED状态，解析失败时，仍然处于INSTALLED状态。

Bundle内的资源被其它Bundle使用时，该Bundle被启动，也可以通过设定让OSGi框架在加载该Bundle时直接启动。

Bundle内的资源通过BundleContext与其他Bundle进行交互。元数据中的"Bundle-Activator"属性指定了实现BundleActivator接口的实现类，Bundle通过该类得到BundleContext，通过BundleContext可以查找其他的Bundle，查找注册在OSGi中的服务（Service）与OSGi环境进行交互等等。Bundle可以在其提供的BundleActivator实现类中进行初始化的工作，也可以注册服务到OSGi的服务注册表中，供其他Bundle查找使用。

 

OSGI核心架构

 

包括四个部分：服务注册、生命周期管理，models和运行环境。

• 最中间的就是bundles运行所需的最小运行环境。
• Life Cycle负责bundles的生命周期管理，如bundle的动态安装、启动、停止、更新和卸载等。
• ServiceRegistry则是bundle的服务注册。
• Modules则提供了强大的ClassLoader机制，在java中一般是由一个ClassLoader来加载所有的类和资源，而在OSGI中则是为每一个bundle提供单独的ClassLoader，OSGI的ClassLoader机制还提供了根据属性、版本等过滤的功能。

OSGI中bunlder间的通信方式有两种：1.export/import 2.服务注册方式。

OSGI可以使项目完全松偶合，一种很好的架构，以framework为核心，可挂接很多bundle，bundle间还能共享资源，这样项目不管在开发，调试，找错，架构上来说都相当的清晰.

 

OSGi在R4种将功能分为几层，包括：安全层、模块层、生命周期层、服务层和实际的服务。OSGi的核心实现即为OSGi框架，它本身也是一个OSGi Bundle。

• 安全层（Security Layer）是一个可选的实现，该层基于Java2 安全架构，位于OSGi服务平台的底层对OSGi环境中应用的部署和管理提供更好的安全控制。
• 模块层（Module Layer）为基于Java的应用、组件的打包，部署和校验提供了一个通用的标准化的解决方案。其他类似的解决方案如JBoss、NetBeans。
• 生命周期层（Life Cycle Layer）为Bundle组件的安全和生命周期操作提供了API定义，该层位于安全层和模块层之上。
• 服务层（Service Layer）定义了一个与生命周期层紧密结合的组件动态交互模型。OSGi中的服务是实现了一个或多个Java接口的Java对象，通过将这些对象依据其实现的接口注册到服务注册表中，Bundle组件可以发布自己的服务，查找使用服务，注册监听处理服务的状态变更等。
• 实际的服务（Actual Services）是OSGi定义的一些标准的服务接口如日志服务（Log Service），包管理服务（Package Admin Service）、启动级别服务（Start Level Service）、HTTP服务（Http Service）、配置服务（Config Admin Service）、用户管理服务(User Admin Service)等等，详细的服务定义参考OSGi规范

 

如何使用？

OSGi规范定义了两个东东，一是容器对外提供的服务，另一个是容器和您的应用程序之间必须遵守的契约。其中，服务对象是容器要实现的。如果想要在OSGi平台上进行开发，首先，必须要使用OSGi API来创建您的应用，然后将之部署到OSGi容器中。从开发者的角度看，OSGi具有以下优点：

a) 您可以在不重启容器的情况下，动态地安装、卸载、启动和停止您的应用程序中的不同模块；

b) 对于您应用程序中的某一特定模块，容器可以同时运行该模块的多个版本；

 

 

 

开源的OSGI实现：

Knopflerfish

http://www.knopflerfish.org

Oscar

http://oscar.objectweb.org

Equinox

http://www.eclipse.org/equinox

Flex

http://incubator.apache.org/flex