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开发平台，MicrosoftActiveX控件以及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）拥有提供服务所必要资源。这些资源可以是javaclass文献，或者是其她数据如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懒激活是很重要优势由于插件类只有在需要时候才会被加载。OSGibundle生命周期也能实现这种方式。当你启动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提供服务。提供服务bundle和使用服务bundle之间依赖关系由框架来进行管理。例如，当停止一种bundle后，这个bundle在框架中注册服务必要要自动取消注册。框架将服务映射到框架下服务对象，并且，框架提供了一种简朴而强大查询机制，通过使用这种机制，bundle 就可以祈求它需要服务。框架也提供了一种事件机制，这样，bundle就可以接受到服务注册、更改和取消注册消息。服务层涉及内容有：服务事件、过期引用、过滤器、服务工厂、服务释放、取消注册服务、多版本导出、安全等。四、Eclipse 插件机制（一）与插件有关概念 扩展点（extension point）：具备命名特性信息收集点，也就是为插件提供接口。每一种插件都是在已有扩展点上开发，同步可自定义扩展点，以便在这个插件上继续开发。正是由引入了扩展点，插件不但可以安装在 Eclipse平台上，还可以安装到其她插件上。 扩展（extension）：对扩展点实现。每个插件至少实现了一种扩展点。 （二）插件间通信插件之间通信是通过扩展点来实现。一方面插件 A 声明了扩展点 P 及其实现规则接口 I。插件 B 如果要扩展插件 A扩展点 P，则生成一种实现接口 I 类 C，从而实现对 P 扩展。在实际运营时，插件 A 找到类 C 并实例化，然后调用其实现了接口 I 中办法。 图 2 插件通信机制 当需要与实现某扩展点插件通信时，依照实现扩展插件清单 plugin.xml 中 extension 标签声明中“class”属性查找并装入类，再依照实现扩展类规则来调该类中办法，从而实现了扩展。五、第一种PDE插件开发实例演示