OSGi模块化框架详解

OSGi模块化框架是很早就出来的一个插件化框架，最早Eclipse用它而出名，但这些年也没有大热虽然OSGi已经发布了版本1到版本5。现在用的最多的，也是本文讲述基于的是Equinox的OSGi实现，同时也是Eclipse核心，Spring Dynamic Module也是基于Equinox。OSGi框架为java系统提供了一个通用的容器，该系统中的 bundle，无需停止系统，即可实现 bundle 的安装、卸载。OSGi是Java中目前唯一的一个模块化、动态化的规范。在模块化方面OSGi联盟已经研究了很多年了，因此OSGi规范对于模块的物理隔离、模块的交互、多版本这些方面都有了非常完善的机制，并且也得到了现在几乎所有的App Server厂商或开源社区的认可，但至今没有被JAVA纳入语言级（有待观察）。OSGi的突出特点有：

• 可以动态加载、更新和卸载模块而不用停止服务
• 实现系统的模块化、版本化，允许多版本bundule同时服务
• Service model允许模块/插件相互依赖但松耦合，分享服务更简单

OSGi运行在JVM之上，其架构图如下图所示：

OSGi适用场景

很多人错误的使用了OSGi, 套用了OSGi架构把系统复杂化。在我看来，OSGi的用处在于“模块化”和“热插拔”。模块化包括模块化、版本化和面向服务的设计。热插拔也就是说模块/bundle的热插拔，它可以实现更新和升级模块/bundle（即系统的一部分）而无需重启整个系统。

如果你的系统套用了OSGi架构，bundle的相互依赖关系复杂，又没有bundle动态加载、动态更新、动态卸载和动态监听的机制，都是静态启动所有bundle，那就是为了OSGi架构而OSGi架构，把问题复杂化了。其代价也是很大的，因为原来你的jar包用maven来处理依赖关系和自动更新也很方便，而由于整个系统建立在OSGi规范上，你的应用所依赖的其他组件也“不得不”迁移到OSGI上来，再加上OSGI独特的ClassLoader设计，使bundle间的类互相访问受到一定的约束，一切都需要迁移到OSGi的约束上来。

举个例子来说，就像Eclipse提供了动态加载、更新和删除插件的机制，因为它里面有一个插件注册和反注册的接口和插件加载、更新和删除的监听线程，这样允许你动态加载、更新和删除Eclipse插件而无需重启Eclipse。当然，如果你当前进程调用了某插件，比如js语法高亮，而某插件更新了，那么当前的js实例还是需要重新打开的。但整个Eclispe无需重启。

Java模块化的难点

OSGi的一个重要特性就是模块化，OSGi提供了一套模块化的体系，这其中则会有明确的模块之间接口暴露以及依赖的定义，因此能够更好的实现高内聚和低耦合。那么，Java模块化难点在哪？模块的实现和传统的编程方法确实有一些差别，主要体现在模块之间类访问的隔离、版本选择这两个方面。如希望更好的设计模块化的系统，开发者需要掌握ClassLoader机制、模块之间类的交互方法（这包括了模块怎么样对外提供可访问的package、怎么样访问其他模块提供的package、如何选择适合版本的package等）。如果不懂以上这些，贸然套用OSGi框架会误入歧途。

重要概念：Bundle

Bundle — A bundle is a JAR file with special OSGi entries in its manifest and containing classes, resources, and other JARs。Bundle，可以将其理解为自描述的 JAR 文件。Bundle在OSGi中是部署的最小单位，因此，可以把它理解为模块。在 bundle 的 manifest 文件中，会有对本 bundle 的标识、提供的功能 (Export-package) 及依赖性 (Import-Package/Require-Bundle) 的定义。每个 bundle 在运行时自己的类加载器 (Class Loader)，这样可以做到一方面把不同的 bundle 里面的类区别开来，当 bundle 被卸载时，只有这个 bundle 的类加载器中的信息会丢失；另一方面，可以在自己的 bundle 内部充分利用 Java 的成员访问控制机制。

Bundle通过MANIFEST.MF进行自描述，下面是一个例子：

1 2 3 4 5 6 7 8 9 10

Manifest-Version: 1.0 Bundle-ManifestVersion: 2 Bundle-Name: Popup Plug-in Bundle-SymbolicName: com.example.myosgi; singleton:=true Bundle-Version: 1.0.0 Bundle-Activator: com.example.myosgi.Activator Require-Bundle: org.eclipse.ui,  org.eclipse.core.runtime Bundle-ActivationPolicy: lazy Bundle-RequiredExecutionEnvironment: JavaSE-1.6

Bundle类隔离机制

每个Bundle均为独立的ClassLoader，是java动态化实现的基础。默认情况下有Boostrap classLoader (jre/lib/classes)、Extension classloader (jre/lib/ext)、 System classloader (classpath指定)，应用可以自行实现classloader及动态的加载类，或加载特定目录下的类。

 

Bundle的生命周期

Lifecycle — A lifecycle is the sequence of states a bundle goes through: uninstalled, installed, resolved, starting, stopping, active. 生命周期图如下所示：

要注意的是：bundle状态变为Resolved并不表示能提供服务，所以启动所有的bundle不表示类都已经加载到内存了。Resolve bundle做以下的几件事情：寻找bundle依赖的包是否存在以及被resolve，寻找匹配的import package，required bundle，如寻找则进入检查，检查没有冲突就形成绑定关系，以便加载类的时候能直接加载（但仅仅Resolved，不代表类被加载了）。如果你的BundleActivationPolicy是LAZY惰性加载，bundle.loadClass()调用才会到达Active状态。如果你的bundle的MANIFEST.MF中配置的Bundle-activator存在，那就调用其start方法，从starting进入active状态。

1 2 3 4 5

osgi> ss   "Framework is launched."   id      State       Bundle   15      STARTING    com.example.serviceconsumer_1.0.0.X   16      RESOLVED    com.example.serviceprovider_1.0.0.X

下面的图更详细的解释了这一点：

 

OSGi Service

Service — A service is an object instance exposed under the one or more interfaces that it implements and a map of properties. 简单来说，Service model允许每个bundle对外分享一组服务，其它的bundle都可以调用这些接口的服务。这也就是OSGi bundle之间调用的方式。Service可以用来：

• Export functionality from a bundle to other bundles
• Import functionality from other bundles
• Register listeners for events from other bundles
• Expose external devices, such as UPnP devices or even hardware, to other OSGi bundles. See the Device and UPnP APIs
• Expose java code running in OSGI to an external network, e.g. via the UPnP or SOAP protocols.
• Bundle configuration, using the Configuration Manager

实际做法来看，通常会把接口和实现分开。接口放到一个bundle里面。实现（service)放到另外一个bundle里面，类似下面的图示中，bundle A和B是Service，其interface放到Bundle C：

也可以是提供一个jar包，里面定义了扩展接口，然后规定新的扩展bundle必须实现该jar包里面定义的interface。实现示意图如下所示（OsgiCommand接口定义在扩展点jar包里面，新的bundle必须包含）：

Bundle的Service之间交换方式和注册方式：

• 通过bundleContext.registerService注册服务，然后通过bundleContext.getServiceReference获取服务（不推荐）
• 使用监听器 listeners 
  ServiceListener 和ServiceTracker 提供bundle和service的动态监听，ServiceTracker可以动态监听未来的bundle和service（OSGi Release 2提供的ServiceTracker ，一般推荐）
• 通过Declarative Service (OSGi DS，或者Spring Dynamic Module (DM))的方式（OSGi Release 4开始，重点推荐！）

第二种通过ServiceTracker 来查询或侦听服务注册和注销的例子代码：

+ View Code

 

OSGi简单起步

从Eclipse创建OSGi的bundle是非常简单的，简单起步可以参考这几篇文章：<Creating a new OSGi Bundle using Eclispe>，以前这篇。

Slideshare: OSGi理论与实战

OSGi动态加载删除bundle

• 使用监听器 listeners 
  ServiceListener 和ServiceTracker 提供bundle和service的动态监听，ServiceTracker可以动态监听未来的bundle和service（OSGi Release 2提供的ServiceTracker ，一般推荐）
• 通过Declarative Service (OSGi DS，或者Spring Dynamic Module (DM))的方式（OSGi Release 4开始，重点推荐！）

  具体实现：

  • 对于DS，<Define a declarative OSGi Service>, <IBM: Declaring your services to OSGi Declarative Services>，<java OSGI Declarative Services Component bundles Example>。
  • 对于Spring DM，<OSGI and Spring Dynamic Modules – Simple Hello World>, <Hello, OSGi, Part 2: Introduction to Spring Dynamic Modules>

分布式OSGi（Distributed OSGi）

OSGi容器可以包含几千个bundlue没有问题，但如何应对几十万个的情况？如何像EJB3一样具有分布式部署和便携性呢？有一个OSGi的子项目:分布式OSGi（Distributed OSGi）。

 

上图是一个demo演示，两个分布式OSGi Container，都部署了Greeter接口bundle，都基于分布式OSGi实现，能实现分布式调用OSGi Service。分布式OSGi（Distributed OSGi）还可以与RESTful Service (JAX-RS / JSR-339)整合。分布式OSGi有几十万个bundle怎么管理，这是个麻烦，而且如何启动停止，启动顺序怎么样？可管理性是个麻烦，ACE项目试图解决这个事情。

DOSGi的原理（由Distribution provider来给OSGi Service创建Endpoint，使这些Service在OSGi Container外部可访问，另外一端则创建代理；此外，有监听器来侦听OSGi Service的创建和启停等）：

分布式OSGi与ZooKeeper

ZooKeeper是Hadoop的一个子项目，它是一个针对大型分布式系统的可靠协调系统，提供的功能包括：配置维护、名字服务、分布式同步、组服务等。ZooKeeper的目标就是封装好复杂易出错的关键服务，将简单易用的接口和性能高效、功能稳定的系统提供给用户。

分布式OSGi（Distributed OSGi）在Discovery这一块使用了ZooKeeper。所谓Discovery模块就是用来发现和侦听分布式的远端的可用的Endpoints。Discovery Ditributed with Zookeeper的架构图：

参考：DOSGi使用ZooKeeper server的安装和Demo。