其实OSGi原本是为了解决家庭网络或者嵌入式设备由于本身的限制(CPU, 内存, 带宽等)而出的一个解决方案, 是一个轻量级的框架. 但现在OSGi已经远远的超过了它的原来的的功能. OSGi已经应用于移动通讯, 汽车, 电信, 嵌入设备, PC桌面和服务器等众多领域. 由于它的开放和简单的风格, 吸引越来越多的著名公司加入, 使OSGi也愈加强大和开放。
我不了解OSGi在其他领域的应用, 只是由于要使用Eclipse, 所以也只对OSGi在PC桌面方面的应用做了些熟悉和了解. 和OSGi一样, Eclipse也是个开放的平台, 它的基础就是OSGi服务平台(Services Platform), 架构在OSGi上的Eclipse具有融合其他应用和组件的能力, 使不同的组件能够运行在一个JVM(Java Virtual Machine)上, 使它们之间能够协同工作, 占用较少得内存和CPU时间, 而且能够由平台管理组件的全生命周期的活动, 可以说一切都在控制之中。
在OSGi中, 每个具体的组件都要继承于Bundle, Bundle是个接口, 定义了安装, 升级, 卸载, 启动, 停止等操作. 其实, 在Eclipse中, 插件(即上面所说的组件)并不是从Bundle继承的, 而是从另外一个重要接口BundleActivator继承的. 后者只有两个接口函数-Start和Stop. 从它的名称就可以看出, 它其实是一个控制Bundle的类. 在Eclipse中有大量这样的应用, 一个类负责提供接口满足不同的需要, 而有另外一个类负责操作这个类. 比如IWorkbench和WorkbenchAdvisor, IWorkbenchWindow和WorkbenchWindowAdvisor等, 这样可以避免客户直接和核心类打交道, 也减轻了客户的负担。
在Eclipse中, 组件都是以Plugin形式存在的, 几乎每个组件都要有一个类实现(继承)Plugin类(也有例外), 一般都是由Plugin来控制服务的加载和卸载, 因为Plugin继承于BundleActivor. 除了Bundle, BundleActivor外, OSGi也提供了BundleEvent, BundleListner等接口. 这些比较简单。
另外一个重要的接口是BundleContext, 该接口提供了一个Bundle所需要的上下文环境, 一个Bundle对应一个BundleContext, 当Bundle停止(Stop)时, 它也就销毁了. BundleContext提供注册服务工厂(ServiceFactory)的接口, Bundle可以注册一些服务工厂接口, 这样其他的Bundle就可以通过实现这些接口达到扩展的目的. 在Eclipse中对应的概念是”扩展点(IExtensionPoint)”和”扩展(IExtension)”. Bundle之间的交互是非常重要的, 利用这种技术, 就可以将很大的项目分成多个Bundle, 然后搭积木就可以了。
eclipse 3.0并没有用OSGI替换掉原来的PlugIn机制。它只是做了与标准兼容的工作：给用户提供了一系列的API来访问，在这个过程中，就必须要做一些改变(比如plugin registry和loading机制)来同OSGI标准完全兼容。最初的Plugin核心只支持静态的扩展，就是说，如果要改变一个已经存在的Plug就必须重启core,也就是要退出Eclipse并重启。
有很多人问Eclipse为什么要兼容OSGI规范而不是其他的规范呢?
在Eclipse被捐赠出来以前，Eclipse由OTI来开发，其目标是开发一个嵌入式Java软件的开发平台。互联网上现在仍然由很多的连接指向 Visual Age Micro Edition (VAME). 这也是SWT被构思的一个原因，他们想将SWT使用在嵌入式设备中的用户界面。这种渊源关系解释了当时为什么选择OSGI规范。
另外一个原因是除了OSGI没有其他的规范。OSGI规范在轻量级服务架构应用方面被广泛的支持。而且OSGI被好多电信业的知名公司和一些其他行业的知名公司所支持。他们需要使用OSGI来同Sun的J2ME来抗衡。
Trackback: http://tb.blog.csdn.net/TrackBack.aspx?PostId=1579933
BBS讨论
用户评论