OSGi: Eclipse的根基

 OSGi为网络服务提供了一套标准的, 面向组件的规范. 而网络服务又是SOA(Service Oriented Architecture)的基础. 使用OSGI平台, 就可以很轻松的管理软件组件的生命周期, 这组件是可以位于网络中的任何设备上, 而且组件可以动态的安装, 加载, 升级和卸载, 而不用终止和重启设备. 这里的组件是指程序库或者是应用程序, 它们又可以动态的使用别的库和程序。

        其实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