Eclipse平台架构技术分析.doc

Eclipse 平台架构技术分析目 录一、Eclipse概述1二、Eclipse体系结构2三、Eclipse平台运行时与OSGi2（一）平台运行时（Platform Runtime）：21) 运行时的功能22) 运行时工作原理2（二）OSGi体系结构31）OSGi概述32）OSGi框架3各层及其关系简介4a.安全层4b.模块层4c.生命周期层6d.服务层7四、Eclipse 的插件机制7（一）与插件相关的概念7（二）插件间的通信8五、第一个PDE插件开发实例演示8Eclipse 平台架构技术分析一、Eclipse概述1.在Eclipse以前比较常用的是分层式体系结构，比如Linus、TCP/IP。然而现在软件的生命周期越来越短、对软件功能的要求越来越强、需求变化也越来越快，一个软件的可扩展性，将很大程度决定了该软件的生命力。因此随着时间的推移，具有可扩展性的插件体系结构也开始慢慢成熟起来，Eclipse就是采用了插件体系结构的设计。2.插件是一种遵循统一的预定义接口规范编写出来的程序，应用程序在运行时通过接口规范对插件进行调用，以扩展应用程序的功能。在英文中插件通常称为plug-in、plugin 或者plug in。插件最典型的例子是Eclipse开发平台，Microsoft的ActiveX控件以及Photoshop的滤镜（Filter）也是一种比较常见的插件，还有就是Mozilla Firefox，Foobar等等也遵循着插件机制。 插件的本质在于不修改程序主体（或者程序运行平台）的情况下对软件功能进行扩展与加强，当插件的接口公开后，任何公司或个人都可以制作自己的插件来解决一些操作上的不便或增加新的功能，也就是实现真正意义上的“即插即用”软件开发。使用“插件软件结构”进行软件设计会给所开发软件增加新的生命力。3.特点：a、定义了插件必须符合的结构以及应该具有的信息 b、查找、装入、注销插 c、管理着一个插件的注册表，并记录各插件的配置信息，以备调入插件时使用二、Eclipse体系结构Eclipse类似于“软总线”的体系结构，Eclipse的核心部分(Platform Runtime)类似于一条“即插即用”的“总线”，它提供了许多的“插槽”(扩展点：extension point)。其余的部分都可看成类似于外部设备的“插件”（Plug-in），可随时加载和卸载。更为灵活的是每个插件又提供了“插槽”可继续安装其他的插件。Eclipse分为Eclipse平台、JDT、PDE、其他的插件几个部分。其中Eclipse平台是整个系统的基础，Eclipse的核心。JDT是提供了用于编辑、查看、编译、调试和运行Java代码的专门插件。PDE构建于Eclipse平台和JDT之上，提供了专门开发插件的工具。Eclipse平台是在其上创建插件扩展的核心框架和服务的名称，是一个通用的基础架构。平台由平台运行时、工作空间、工作台、帮助、小组、调试构成。平台在结构上大致可分为核心（core）和用户界面（UI）两层。核心是与用户界面无关的基础结构，包含平台运行时和插件管理、工作空间和资源管理以及版本和配置管理。其中平台运行时又是Eclipse平台的核心。三、Eclipse平台运行时与OSGi（一）平台运行时（Platform Runtime）： 运行时相当于一个微内核，是插件的核心引擎。它位于平台核心中最低级别的部分，由 org.eclipse.osgi 和org.eclipse.core.runtime 两个插件组成，其他所有的插件都依赖于这两个插件。 1) 运行时的功能a 定义插件的结构以及它们包含的实现详细信息（bundle 和类载入器）。 b 查找和执行主要的 Eclipse应用程序以及维护插件的注册表、扩展和扩展点。 c 提供实用程序（例如，记录、调试跟踪选项、适配器、首选项库和并发性基础结构）。 2) 运行时工作原理 运行时管理着一个插件注册表（所有插件的标识），当Eclipse 启动时，运行时内核先是定位 JRE 的位置，然后启动startup.jar 扫描 plugins 和 features 目录下的插件配置文件,对插件进行初始化注册到 OSGi 中，并保存配置文件中的信息。然后查找清单文件中声明的 extension point 和 extension，将二者匹配，保存插件的依赖关系。最后启动应用。 运行时对插件实行“lazy load“，只有当需要使用插件时才将其调入内存。不需要时选择适当的时机清除出内存。（二）OSGi体系结构1）OSGi概述OSGi联盟成立于1999年3月，致力于为网络和本地设备建立开放的网络管理服务规范，是一个开放的一般性架构，主要为供应商如服务提供商、开发者、软件提供商、网关运营商和设备提供商等开发、部署和管理服务提供一种一致的协作环境。OSGi技术是一些规范的集合，这些规范形成了一个基于java的动态组件系统。由此形成了一个开发模式，在这个模式上应用可以由许多不同的可复用组件组成。Eclipse 体系架构就是参照 OSGi 实现的。（核心插件org.eclipse.osgi 就是 OSGi 的实现。)OSGi（Open Service Gateway Initiative）是一个为家用硬件设备的远程互访建立的一个开放的规范。它包括构建开放的可交付网络服务的各方面。OSGi 中的应用称为 bundle，每个 bundle 可提供一定数量的服务（Services）。每一个安装在 OSGi 服务平台的 bundle 都有一个与之关联的 bundle 对象（object），它负责管理 bundle的生命周期。bundle 有诸如安装、停止、活动等多种状态。2）OSGi框架OSGi按功能分层如下图所示 OSGi框架功能分层示意图OSGi服务平台标准的核心是提供一个通用、安全并且可管理的Java框架，该框架支持可扩展部署和下载的应用程序(称之为bundle)。OSGi设备可以下载和安装bundle，并且可以在不需要的时候将其移除，在一个OSGi环境中，bundle的安装、更新由框架统一动态管理，为此，需要框架对服务和bundle之间的依赖细节进行管理。由于Java平台的独立性和动态代码加载能力，bundle的开发者可以很容易的开发出在嵌入设备上也能大规模部署的程序。表：OSGi分层模型相关概念模型概念名称模型概念描述Bundles开发者开发出来的OSGi组件Services服务层为普通Java对象提供一种“发布-寻找-绑定”的模式，动态连接bundles Life-Cycle建立启动停止，更新和卸载bundles过程的接口Modules定义了bundle如何导入和导出代码Security安全控制Execution Environment定义了指定平台上可以运行的方法和类框架从功能上分为下面几个层次：安全层（Security）、模块层（Modules）、生命周期层（Life Cycle）、服务层（Services）。各层及其关系简介安全层基于Java2的安全机制，但是增加了一些限制，并且弥补了Java标准的一些不足。模块层定义了一个模块化的Java模型，它针对Java部署模式的一些缺点进行了改进，对bundle或者隐藏包与其他bundle之间共享包有严格规定，模块层独立于生命周期层和服务层，使用时可以不需要生命周期层和服务层。生命周期层提供了对模块层的bundle进行管理的API，而服务层提供了bundle之间的通信模型。生命周期层为bundle提供了生命周期管理的API，为bundle提供了一个运行时的模型，定义了一个bundle如何启动、停止、安装、卸载等，另外，生命周期层也提供全面的事件机制API，允许管理bundle去控制和操作服务平台。服务层为Java bundle开发者提供了一个灵活、简单并且一致的编程模型，简化服务bundle的开发和部署，并以非耦合的服务标准（Java接口）来实现。这个模型允许bundle开发者使用他们自己的接口规范来绑定服务。这样就可以在运行时根据具体情况或需求选择接口的不同的实现。一致的编程模型可以帮助bundle开发者应对扩充的问题，因为在很多情况下，框架需要运行在各种各样的硬件设备上，一致的接口可以确保软件稳定的运行。在框架中，bundle可以在运行时通过框架服务注册中心选择一个可用的实现，bundle可以注册新服务、接受关于服务状态的通知或者查找适合当前设备的服务等。框架可以支持动态安装新的bundle，支持对一个已经部署后的Bundle进行更改、更新而不需要重新启动系统。a.安全层OSGi安全层是OSGi服务框架的一个可选的层。它基于Java 2 安全体系结构，提供了对精密控制环境下的应用部署和管理的基础架构。安全层有三个要点：一是精密控制(fine grained)，在OSGi框架下的应用控制必须达到精细粒度的控制。二是可管理性，安全层本身没有定义API来控制应用，对安全层的管理交由生命周期层。三是可选性，安全层是可选的。安全层的框架安全模型基于Java 2 规范。如果运行安全检查，那么需要遵循Java 2 安全架构规范。安全层涉及的内容有：代码验证、数字签名JAR文件等。b.模块层模块性，简单来说，就是做尽可能少的假设，使事物保持本地性,使得事物之间不共享。 模块性是OSGi规范的核心，并且被应用到bundle 的概念中。用Java的术语来说，bundle就是一个JAR文件。OSGi隐藏了所有的JAR中的细节。Bundle如果想使用其他JAR，必须明确指出它需要引入的部分。默认情况下，bundle之间没有共享。Java平台只提供了对打包、部署和对Java应用和组件检验的最小支持。因此，很多基于java的项目，如JBoss、NetBeans，常常借助于专用的类加载器来创建用户模块层，以实现打包、部署和对Java应用和组件检验。OSGi框架提供了对java模型化的一般和标准的解决方案。框架定义了模型化单元，称之为一个bundle。一个bundle由java的类和其他资源组成，可以为终端用户提供功能。通过良好定义的方式，Bundle 可以和导入(importer)及导出(exporter) Bundle之间共享Java包。在OSGi服务框架中，bundle是仅有的需要部署的Java应用实体。Bundle以JAR文件的方式进行部署。JAR文件使用ZIP的格式存储应用程序以及所需的资源。一个bundle是一个如下的JAR文件：（1）拥有提供服务所必须的资源。这些资源可以是java的class文件，或者是其他的数据如HTML文件，帮助文件，图标文件等。一个bundle JAR文件也可以嵌入其他JAR文件作为资源，但是不支持多层嵌套的JAR。（2）有一个manifest文件描述JAR文件内容和bundle的信息。该文件处于JAR的头部，提供框架需要的安装和激活bundle所需的信息。例如，它对其他资源如JAR文件的依赖这种状态信息必须在bundle运行之前加载。（3）可以在OSGI-OPT文件夹提供可选的文档信息，该文件夹可以位于JAR文件根目录或者它的子文件夹中。OSGI-OPT文件夹中的内容都是可选的。例如，可以在其中保存bundle的源代码。管理系统可以删除该文件夹内容，以便于节约OSGi服务平台的存储空间。当一个bundle开始运行，通过OSGi服务平台，它开始对安装在平台内的其他bundle提供功能和服务。 模块层涉及的内容有：运行环境、类加载机制、元数据处理、约束处理、解析过程、运行时类加载、本地代码加载、本地化、bundle有效性、可选项、bundle的需求、bundle片段、bundle的扩展、安全等。c.生命周期层生命周期层提供了bundle的生命周期管理和安全控制的API。本层是建立在在模型和安全层之上。生命周期层有四个要点：一是完整性，生命周期层必须提供包括bundle安装、启动、停止、更新、卸载和管理的所有状态的API。二是深入性，API必须要提供深入到框架实际状态的视点。三是安全，通过使用小粒度的权限来实现的安全环境下，API必须可以在这样的环境下使用。但是安全必须要是可选的。四是可管理性，必须可以对远程平台的服务进行管理。在OSGi框架中，bundle表现为JAR文件的形式。在模块层中说明了类加载这方面的含义。但是，模块层没有定义bundle是如何安装、更新和卸载的，而生命周期操作对这些进行了定义。对于OSGi 框架中安装的每一个bundle，都有一个关联的bundle 对象。这个对象就用于bundle的生命周期管理。通常是由一个管理代理（Agent，也是一个bundle）来完成。通过使用BundleContext对象来实现框架和安装的bundle之间的关系。一个BundleContext对象描述了OSGi服务平台中一个bundle的执行上下文环境，作为框架之下的一个代理。与普通bundle相比，框架本身也是一个bundle。这些bundle称之为系统bundle。通过系统bundle，框架可以注册供其他bundle使用的服务。例如包管理和权限管理服务。生命周期层涉及的内容有：bundle实体、bundle上下文环境、系统bundle、事件、框架的启动和关闭、安全等。OSGi是一个动态的框架，它支持bundle的安装、启动、停止和卸载。正如前面提到的，Eclipse的懒激活是很重要的优势因为插件的类只有在需要的时候才会被加载。OSGi的bundle生命周期也能实现这种方式。当你启动OSGi应用，bundle处于已安装状态。如果依赖条件满足，bundle会变为已处理的状态（resolved state）。一旦处于已处理状态，这个bundle中的类就能够加载并执行了。启动中状态意味着bundle按照其激活策略正在被激活。一旦被激活后，bundle处于活跃状态（active state），它此时能够获取需要的资源并与其它bundle交互。当bundle执行启动器（activator）的stop方法来清理在活跃状态中开启的资源时，bundle处于正在停止状态（stopping state）。最后，bundle可以被卸载，这意味着它不可用了。d.服务层OSGi服务层定义了一个和生命周期层紧密结合的动态协作模型。服务模型包括发布、查找和绑定模型。一个服务（service）就是一个通过服务登记来注册到一个或者多个Java接口下的Java对象。Bundle可以注册服务，查找服务和监听服务。任意数量的bundles可以注册同一类型的服务，任意数量的bundles可以得到同样的服务。如下图所示服务示意图服务层有六个要点：一是协作性，服务层必须为bundle提供一种机制来发布、查找和绑定bundle之间的服务，而无需事先知道bundle的信息。二是动态性，服务层机制必须能够处理外界或者是子结构的变化。三是安全，必须能够限定对服务的访问。四是深入性，对服务层的内部状态可以进行完全控制。五是版本控制，提供对bundle以及对它们服务更新的控制。六是持久性，在框架重启过程中提供方法来跟踪服务。在OSGi服务平台下，bundle建立在一系列的相互协作的可用服务之上，这些服务共享一个服务注册中心。这样一个OSGi服务在语义上通过它的服务接口来定义，并实现为一个服务对象。在服务接口中应该尽可能少的指定实现细节。OSGi规定了很多常用的服务接口，以后还会增加。服务对象是属于bundle的，而且在bundle之内运行。bundle必须要将服务对象注册到框架的服务注册中心，这样，才可以在框架的控制下来为其他bundle提