Eclipse平台架构技术分析Word格式文档下载.docx
《Eclipse平台架构技术分析Word格式文档下载.docx》由会员分享，可在线阅读，更多相关《Eclipse平台架构技术分析Word格式文档下载.docx（9页珍藏版）》请在冰豆网上搜索。
a.安全层4
b.模块层4
c.生命周期层6
d.服务层7
四、Eclipse的插件机制7
（一）与插件相关的概念7
（二）插件间的通信8
五、第一个PDE插件开发实例演示8
一、Eclipse概述
1.在Eclipse以前比较常用的是分层式体系结构，比如Linus、TCP/IP。
然而现在软件的生命周期越来越短、对软件功能的要求越来越强、需求变化也越来越快，一个软件的可扩展性，将很大程度决定了该软件的生命力。
因此随着时间的推移，具有可扩展性的插件体系结构也开始慢慢成熟起来，Eclipse就是采用了插件体系结构的设计。
2.插件是一种遵循统一的预定义接口规范编写出来的程序，应用程序在运行时通过接口规范对插件进行调用，以扩展应用程序的功能。
在英文中插件通常称为plug-in、plugin或者plugin。
插件最典型的例子是Eclipse开发平台，Microsoft的ActiveX控件以及Photoshop的滤镜（Filter）也是一种比较常见的插件，还有就是MozillaFirefox，Foobar等等也遵循着插件机制。
插件的本质在于不修改程序主体（或者程序运行平台）的情况下对软件功能进行扩展与加强，当插件的接口公开后，任何公司或个人都可以制作自己的插件来解决一些操作上的不便或增加新的功能，也就是实现真正意义上的“即插即用”软件开发。
使用“插件软件结构”进行软件设计会给所开发软件增加新的生命力。
3.特点：
a、定义了插件必须符合的结构以及应该具有的信息b、查找、装入、注销插c、管理着一个插件的注册表，并记录各插件的配置信息，以备调入插件时使用
二、Eclipse体系结构
Eclipse类似于“软总线”的体系结构，Eclipse的核心部分（PlatformRuntime）类似于一条“即插即用”的“总线”，它提供了许多的“插槽”（扩展点：
extensionpoint）。
其余的部分都可看成类似于外部设备的“插件”（Plug-in），可随时加载和卸载。
更为灵活的是每个插件又提供了“插槽”可继续安装其他的插件。
Eclipse分为Eclipse平台、JDT、PDE、其他的插件几个部分。
其中Eclipse平台是整个系统的基础，Eclipse的核心。
JDT是提供了用于编辑、查看、编译、调试和运行Java代码的专门插件。
PDE构建于Eclipse平台和JDT之上，提供了专门开发插件的工具。
Eclipse平台是在其上创建插件扩展的核心框架和服务的名称，是一个通用的基础架构。
平台由平台运行时、工作空间、工作台、帮助、小组、调试构成。
平台在结构上大致可分为核心（core）和用户界面（UI）两层。
核心是与用户界面无关的基础结构，包含平台运行时和插件管理、工作空间和资源管理以及版本和配置管理。
其中平台运行时又是Eclipse平台的核心。
三、Eclipse平台运行时与OSGi
运行时相当于一个微内核，是插件的核心引擎。
它位于平台核心中最低级别的部分，由org.eclipse.osgi和org.eclipse.core.runtime两个插件组成，其他所有的插件都依赖于这两个插件。
1）运行时的功能
a．定义插件的结构以及它们包含的实现详细信息（bundle和类载入器）。
b．查找和执行主要的Eclipse应用程序以及维护插件的注册表、扩展和扩展点。
c．提供实用程序（例如，记录、调试跟踪选项、适配器、首选项库和并发性基础结构）。
2）运行时工作原理
运行时管理着一个插件注册表（所有插件的标识），当Eclipse启动时，运行时内核先是定位JRE的位置，然后启动startup.jar扫描plugins和features目录下的插件配置文件,对插件进行初始化注册到OSGi中，并保存配置文件中的信息。
然后查找清单文件中声明的extensionpoint和extension，将二者匹配，保存插件的依赖关系。
最后启动应用。
运行时对插件实行“lazyload“，只有当需要使用插件时才将其调入内存。
不需要时选择适当的时机清除出内存。
（二）OSGi体系结构
1）OSGi概述
OSGi™联盟成立于1999年3月，致力于为网络和本地设备建立开放的网络管理服务规范，是一个开放的一般性架构，主要为供应商如服务提供商、开发者、软件提供商、网关运营商和设备提供商等开发、部署和管理服务提供一种一致的协作环境。
OSGi技术是一些规范的集合，这些规范形成了一个基于java的动态组件系统。
由此形成了一个开发模式，在这个模式上应用可以由许多不同的可复用组件组成。
Eclipse体系架构就是参照OSGi实现的。
（核心插件org.eclipse.osgi就是OSGi的实现。
）
OSGi（OpenServiceGatewayInitiative）是一个为家用硬件设备的远程互访建立的一个开放的规范。
它包括构建开放的可交付网络服务的各方面。
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
安全控制
ExecutionEnvironment
定义了指定平台上可以运行的方法和类
框架从功能上分为下面几个层次：
安全层（Security）、模块层（Modules）、生命周期层（LifeCycle）、服务层（Services）。
各层及其关系简介
安全层基于Java2的安全机制，但是增加了一些限制，并且弥补了Java标准的一些不足。
模块层定义了一个模块化的Java模型，它针对Java部署模式的一些缺点进行了改进，对bundle或者隐藏包与其他bundle之间共享包有严格规定，模块层独立于生命周期层和服务层，使用时可以不需要生命周期层和服务层。
生命周期层提供了对模块层的bundle进行管理的API，而服务层提供了bundle之间的通信模型。
生命周期层为bundle提供了生命周期管理的API，为bundle提供了一个运行时的模型，定义了一个bundle如何启动、停止、安装、卸载等，另外，生命周期层也提供全面的事件机制API，允许管理bundle去控制和操作服务平台。
服务层为Javabundle开发者提供了一个灵活、简单并且一致的编程模型，简化服务bundle的开发和部署，并以非耦合的服务标准（Java接口）来实现。
这个模型允许bundle开发者使用他们自己的接口规范来绑定服务。
这样就可以在运行时根据具体情况或需求选择接口的不同的实现。
一致的编程模型可以帮助bundle开发者应对扩充的问题，因为在很多情况下，框架需要运行在各种各样的硬件设备上，一致的接口可以确保软件稳定的运行。
在框架中，bundle可以在运行时通过框架服务注册中心选择一个可用的实现，bundle可以注册新服务、接受关于服务状态的通知或者查找适合当前设备的服务等。
框架可以支持动态安装新的bundle，支持对一个已经部署后的Bundle进行更改、更新而不需要重新启动系统。
a.安全层
OSGi安全层是OSGi服务框架的一个可选的层。
它基于Java2安全体系结构，提供了对精密控制环境下的应用部署和管理的基础架构。
安全层有三个要点：
一是精密控制（finegrained），在OSGi框架下的应用控制必须达到精细粒度的控制。
二是可管理性，安全层本身没有定义API来控制应用，对安全层的管理交由生命周期层。
三是可选性，安全层是可选的。
安全层的框架安全模型基于Java2规范。
如果运行安全检查，那么需要遵循Java2安全架构规范。
安全层涉及的内容有：
代码验证、数字签名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文件，帮助文件，图标文件等。
一个bundleJAR文件也可以嵌入其他JAR文件作为资源，但是不支持多层嵌套的JAR。
（2）有一个manifest文件描述JAR文件内容和bundle的信息。
该文件处于JAR的头部，提供框架需要的安装和激活bundle所需的信息。
例如，它对其他资源如JAR文件的依赖这种状态信息必须在bundle运行之前加载。
（3）可以在OSGI-OPT文件夹提供可选的文档信息，该文件夹可以位于JAR文件根目录或者它的子文件夹中。
OSGI-OPT文件夹中的内容都是可选的。
例如，可以在其中保存
bundle的源代码。
管理系统可以删除该文件夹内容，以便于节约OSGi服务平台的存储空间。
当一个bundle开始运行，通过OSGi服务平台，它开始对安装在平台内的其他bundle提供功能和服务。
模块层涉及的内容有
升级会员 