OSGi概念入门

关注

最新推荐文章于 2026-02-20 00:48:54 发布 107 阅读 AI 写同款· GEO 优化 ›

OSGi 是什么， OSGi 是一种服务运行平台。通过实现能够提供服务的符合 OSGi 规范的组件，用户可以将其组件发布到 OSGi 运行平台，供用户和其他组件使用。 OSGi 组件提供的服务具有两个层面的含义：系统层面，即一个组件为其他组件提供服务，这些服务体现为 Java 接口的实现；业务层面，即一个组件为外部系统或用户提供某种业务服务实现。

OSGi是什么

OSGi是什么，OSGi是一种服务运行平台。通过实现能够提供服务的符合OSGi规范的组件，用户可以将其组件发布到OSGi运行平台，供用户和其他组件使用。OSGi组件提供的服务具有两个层面的含义：系统层面，即一个组件为其他组件提供服务，这些服务体现为Java接口的实现；业务层面，即一个组件为外部系统或用户提供某种业务服务实现。

OSGi提供的功能

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使用该接口实现提供的功能。这一切看上去是不是解决的非常完美呢？！

OSGi的实现机制

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

OSGi的组成

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

u OSGi的安全层（Security Layer）是一个可选的实现，该层基于Java2 安全架构，位于OSGi服务平台的底层对OSGi环境中应用的部署和管理提供更好的安全控制。

u OSGi的模块层（Module Layer）为基于Java的应用、组件的打包，部署和校验提供了一个通用的标准化的解决方案。其他类似的解决方案如JBoss、NetBeans。

u 生命周期层（Life Cycle Layer）为Bundle组件的安全和生命周期操作提供了API定义，该层位于安全层和模块层之上。

u 服务层（Service Layer）定义了一个与生命周期层紧密结合的组件动态交互模型。OSGi中的服务是实现了一个或多个Java接口的Java对象，通过将这些对象依据其实现的接口注册到服务注册表中，Bundle组件可以发布自己的服务，查找使用服务，注册监听处理服务的状态变更等。

u 实际的服务（Actual Services）是OSGi定义的一些标准的服务接口如日志服务（Log Service），包管理服务（Package Admin Service）、启动级别服务（Start Level Service）、HTTP服务（Http Service）、配置服务（Config Admin Service）、用户管理服务(User Admin Service)等等，详细的服务定义参考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查找使用。