OSGi Pure Plugin Architecture Introduction

阅读更多

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。

OpenCore在该层的服务模型下实现了非常灵活的分级IoC容器,支持插件级、应用程序级、网络级的IoC功能。

你可能感兴趣的:(OSGI,IOC,企业应用,网络应用,嵌入式)