深入Java技术,关注分布式数据交换,关注企业应用集成,关注OSGi、JBI、SCA、SOA、EAI、ESB、JXTA、JINI.. ... 关注EQUINOX/RCP/RAP/ECF/DTP/STP/GEF/EMF......
OSGi是什么,OSGi是一种松散耦合的组件管理和服务运行平台规范。简单的说,用户只需要修改通用的Java类库打包档案JAR文件中META- INF下的元数据文件MANIFEST.MF,添加必要的标签信息,放置到OSGi框架的Bundle Repository中,用户的类库就成了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 B中的这些类通过Bundle B的元数据描述信息公开(Export)出去,使得这些类对OSGi平台中的所有Bundle可见,这些类资源仍然位于Bundle B中。Bundle A在其元数据描述信息中将Bundle B公开的类引入(Import)进来。在运行时,Bundle A就可以使用Bundle B提供的这些类,而不是需要将这些类拷贝到Bundle A中或其他位置。
Bundle B在运行时可以将Bundle A需要的类实例注册到OSGi运行平台的服务注册表中,类实例实现的接口可以通过上述问题一的方式使得Bundle A可见,那么,在运行时,Bundle A就可以通过该接口到OSGi平台服务注册表中查找Bundle B中提供的接口实现类实例,并调用该接口上的方法。
可以将上述问题二的解决方案中的Bundle B提供的接口定义提取到Bundle C中,并在Bundle C的元数据中公开,通过在Bundle A和Bundle B中同时引入Bundle C中发布的接口,Bundle B提供该接口的实现,Bundle A使用该接口实现提供的功能。这一切看上去是不是解决的非常完美呢?!
OSGi是如何实现的呢?从本质上说,OSGi是充分使用了Java的类加载机制,对模块和应用进行了更加精细粒度的控制,然后在类域上建立一系列松耦合应用。OSGi为每一个Bundle组件定义了一些元数据信息,通过这些元数据,OSGi在运行时为每一个Bundle构建了一个独立的类域(即类空间),详细描述参考OSGi之Bundle小节。
OSGi在R4种将功能分为几层,包括:安全层、模块层、生命周期层、服务层和实际的服务。OSGi的核心实现即为OSGi框架,它本身也是一个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查找使用。
Knopflerfish:http://www.knopflerfish.org
Oscar:http://oscar.objectweb.org
Equinox:http://www.eclipse.org/equinox
Felix:http://felix.apache.org