OSGi体系结构

OSGi体系结构

OSGi 的初衷是面向嵌入式系统的应用，支持在一个Java虚拟机上加载和启动多个Java应用程序。随着OSGi在Eclipse3.0上的应用成功，其逐渐成为构建纯插件结构的企业级应用软件系统的首选平台。

OSGi 是一个纯插件的体系结构，OSGi 框架实现是一个最为核心的插件，逻辑实现分层见下面两张图：

             

L0层Java执行环境

OSGi最初规范定位到嵌入式系统，例如家电、汽车、手机等执行环境，所以插件要配置适合的运行环境与Policy。当OSGi框架加载插件时会对插件要求的执行环境做校验。例如，Eclipse中可以配置下图中的执行环境：

L1模块层(组件或插件层)

L1模块层(插件层 或 组件层)定义插件的ClassLoading策略(Policy)，这也是OSGi最为出色和吸引人的地方。我们知道，任何一个Java平台的插件体系结 构，首先要解决的是ClassLoading的问题。OSGi在Java动态ClassLoading基础之上，提供了完美的插件 ClassLoading解决方案。传统J2SE程序，有单一的Classpath包含所有的classes与resources，L1插件层为每个 OSGi插件提供了私有的Classpath和独立的Classloader，有效的控制了插件间的Class隔离、依赖与协作。

插件间的Class依赖关系见下图(版权归www.osgi.org)：

插件的类空间(Class Space)见下图(版权归www.osgi.org)：

插件的类加载过程：

L2插件生命周期管理层

L2层负责运行时动态安装(Install)、启动(Start)、停止(Stop)、更新(Update)或卸载(Uninstall)插件。

插件的生命周期见下图(版权归www.osgi.org)：

L3服务注册层

L3提供了一个动态的服务注册模型，插件可以注册(register)、发现(lookup)、使用(reference)服务。

该层的服务注册采用ServiceLocator模式，见下面图示：

该层的实现由于没有直接的IoC容器支持，被很多过分相信IoC作用的人所批评。Martin Fowler曾经说过，“说一个系统是基于IoC的，就好像说一个汽车有四个轮子”，IoC只不过是一种模式和设计原则，任何一个设计得比较好的面向对象 系统都或多或少的具备这样的特征，这与存不存在一个独立的IoC容器关系不大，尽管IoC容器在开发上带来很大的便利与优势。另外一个方面，IoC容器本 质上还是一个Service Registry，只不过增加依赖装配功能，所以在OSGi的服务注册模型上，可以很容易的支持IoC。

 

http://www.javaeye.com/wiki/OSGi/556-OSGi%20Pure%20Plugin%20Architecture%20Introduction