OSGi体系结构 - 学习笔记

 

OSGi体系结构

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

 

 

注 写道

学习osgi缘起于RCP,接触时发现RCP就是在一个运行器上加载工程代码,但还不知道这个运行器的体系结构 所以才找到了OSGI,貌似同类型的其他运行器也是有的,当初自己写代码时运行器设计的很简单也缺乏可移植性,现在有了新的思路

 

 

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隔离、依赖与协作。

 

 

注 写道

bundle原意是捆,这里就像是把每个单独的插件打成捆,互相分离的堆在一起,用bundle class loader 动态加载,每个插件 就彼此完全分离,其中环境变量之类的参数 全部采用工程配置文件的方式管理

 

 

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

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

注 写道

这部分介绍了 bundle间的依赖或者说调用关系,不是必须完全隔离的

 

插件的类加载过程：

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。

 

注 写道

这就是之前发现问题——意图修改工程注册服务的ID标识却不可的得——的所在,却没有实在的配置文件支持(没有用到直接的IoC)

 

 

 

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