e4 技术白皮书

一、概述

      Eclipse 平台的初衷是构建一个可扩展的IDE组件框架,但它现在已经发展成为一个构建可扩展的任何软件的通用平台。目前，Eclipse应用出现在了各种部署环境中，比如Web服务器、Web浏览器、嵌入式客户端,以及传统的富桌面应用。

      E4平台的设计是为了简化软件组件以及基于组件的应用的开发,以满足当前不断变化的计算场景的需求。本文主要介绍e4的架构和编程模型。

  

二、什么是E4

      E4是一组相关技术的集合,这些技术主要用于构建可扩展的、基于组件的应用。E4将一组新的技术融入现有的Eclpse平台，而不是对Eclipse平台的大规模替换，目的是使Eclipse组件更易于编写、配置性更高，并易于在不同的运行环境中复用。

      第一代Eclipse平台(1.0到2.1)主要是一个集成平台,其主要的功能是将不同的作者开发的插件集成成为一个通用应用，并是最终用户有一个一致、内聚的体验。

      第二代Eclipse平台他(3.x)开始构建在OSGI上，这使Eclipse成为一个更加强大、通用的基于组件的应用框架。第二代平台可用于很小的嵌入式应用、RCP应用以及Web服务器。然而，每个组件(插件)通常难以在特定环境(组件的设计和测试环境)以外服用。为系统添加和删除组件很容易，但很难将一个为某应用或运行环境设计的组件复用到一个完全不同的应用和环境中。

      E4的愿景是使开发的在多种应用和环境中都可服用和可定制的组件变得更加容易。有两种途径可以达到这个目的:减少组件的外部依赖；增加可无缝集成到Eclipse运行时的语言和技术。

      这两种技术都被Eclipse采用了：

1. 面向服务的编程模型，基于OSGI把软件组件更好的从外围环境中分离。
2. GUI被描述成统一的模型，此模型可以被查询、操作、工具化、扩展，还可以在很少甚至无需编码的情况下快速的设计和定制用户界面。
3. 使用CSS可以无需修改应用代码，可以任意修改UI展现 。
4. 把Eclipse运行时技术融入到JavaScript世界，允许JavaScript写的软件可以在Eclipse上运行 。
5. 声明式定义SWT应用的设计和结构，摒除了重复的公式化的SWT代码，这降低了开发成本，提高了UI一致性，并且允许定制应用发布 。
6. SWT的移植，称为“浏览器版本”，允许现有的SWT应用像ActionScript/Flash一样在Web上运行。
7. 在开发工具方面，更灵活的资源模型为复杂的工程结构提供了更好的支持。

      接下来我们将更详细的介绍这些新技术。

 

三、编程模型

       E4编程模型遵循现有的Eclipse编程原则：

1. 模块化：应用由插件或Bundle松耦合的组件组成。Bundle可用Java或者其他语言编写，包括文档和源代码等资源。
2. Bundle可以通过扩展点声明可被定制和扩展的地方，也可以通过定义扩展定制扩展其他Bundle
3. 一次可以安装大量Bundle,但只有实例用到的Bundle才会被加载,未加载插件不会消耗系统资源。

      E4区别于传统Eclipse编程模型的地方在于,Bundle在扩展注册表机制之外的彼此交互。Bundle经常不以Eclipse扩展注册表的方式为其他Bundle提供数据和服务。比如Bundle通过直接引用API中定义的方法和常量来与其他Bundle通信。

     为了获得服务的单实例，Bundle一般会定义入口点(比如Platform、IDE、ResourcesPlugin、JavaCore等类)。这种用法会导致Bundle之间存在紧密耦合，结果导致bundle难以在不同的环境中重新装配或服用。

     服务编程模型定义了三个不同的参与者:服务提供者、服务消费者和代理容器(绑定服务提供者到消费者)。此编程模型的基本实现,比如OSGI服务API或Eclipse扩展注册表，出色的将服务提供者与服务消费者解耦，但需要服务提供者和服务消费者能显示的知道特定容器和服务代理。

图一：简单服务架构

 

     E4编程模型通过减少或消除服务提供者与消费者对特定服务代理技术的依赖,进一步将这些参与者解耦。这种灵活性将在下面的介绍中详细解释。

    1)  上下文(context):服务代理(the service broker)

      E4引入“上下文”的概念作为存储查找服务并将这些服务提供给消费者的通用机制。从这个基本功能来说，E4上下文看起来很像存储键值对的Java Map，客户可以向此Map里存值或取值。但客户请求上下文值时,可懒(动态)计算这些值的上下文函数。当客户请求了一个上下文中不存在的值时，请求将被委托给父上下文处理。同时允许服务和数据存储在一个中心位置,被多个客户消费。

     上下文还有一个可拔插的查找策略，允许外部参与者告诉上下文怎样获取特定种类的值，此查找策略使E4上下文和其他服务代理(如OSGI服务注册表)间的互操作性成为可能。

     这种灵活性意味着各种不同的服务查找方法和代理系统都可以集成到E4的上下文机制中。创建上下文层次结构以及插入服务查找策略的能力，可使上下文适用于从非常简单的类似map的服务注册与查找到高度复杂的动态服务仲裁机制。

  

   2) 注入(Injection): 服务消费者(service consumers)

     目前服务编程模型的最佳实践是消费者通过依赖注入来得到依赖的内容。这从理论上可使应用代码完全消除对特定容器技术的依赖，从而 保证更大的复用。E4直接使用并鼓励把依赖注入作为向客户端提供服务的手段，支持构造函数注入、方法注入、以及字段注入。在客户端代码中标识注入方式,可以采用命令规范或者Java注解，如果不习惯IOC,可以直接使用E4上下文(service locator设计模式)。

 

    3) 服务提供者

    Bundle提供的服务和数据多种多样。有些服务很轻量，可被使用或丢弃成千上万次,然而其他一些重量级服务可能要存活很长一段时间，这些服务的声明周期也各不相同,有些依赖于特定UI组件的存在而存在,而有些可能贯穿于某bundle的整个生命周期。正是由于这些多样性,所以没有哪种服务发布方法可以适用于所有的服务提供者。

    通常,E4中发布的服务使用OSGI服务机制,服务的注册和删除,不仅可以通过代码,还可以通过OSGI的声明式服务。声明式服务允许服务直到被请求时才被实例化。当然,有很多中辅助框架可用于发布OSGI服务，比如Spring DM、IPOJO、Peaberry等等。这些模型使用OSGI服务作为服务发布的基础,可以和E4无缝集成。

    虽然大多数客户端代码将使用的服务,创建上下文的框架可以直接简单的向上下文中添加服务。比如一个关联到某组件的服务，可能要注册到组件构造方法的上下文,并在组件销毁是撤销服务。手工注册可使服务仅在特定上下文中才变得可用,而通过OSGI服务,可使服务一直可用。最后要提到的是,上下文支持通过字段或访问方法注出(outinjection,反注入)服务回至上下文。

     最终,我们有了一个完整的模型:服务消费者不知道谁提供服务,也不知道用什么代理获取服务。通过分离服务配置数据和服务实现，服务提供者可与服务代理大大解耦。也可以使用声明式机制,比如DS、注出,或者简单的从服务实现中分离框架相关的注册代码,下图说明了这个模型。

图2 e4服务架构

       4) Eclipse 应用服务

       为支持这种解耦的服务编程模型,Eclipse API 要变成可用的服务,而不是以前那种当实例访问器模型(Platform、ResourcesPlugin等)。然而,多年来Eclipse平台以及积累了大量的API,当很多组件仅使用这些API中的一小部分。仅这些API的广度就使基于Eclipse进行应用开发成为一个挑战,陡峭的学习曲线增加了学习成本,障碍了新手的开发。

        E4将通过定义一组核心服务获取大量有用的平台功能来解决这些问题,目的是让开发人员可以仅使用这些核心bundle就能很好的构建完整的E4 Bundle。

       这些核心服务还为把其他语言集成到Eclipse平台定义了好的起点,后面有关javascript集成相关章节将进一步讨论这个话题。

 

四、基于模型的UI

      上一代Eclipse平台UI(称为workbench)复杂而且难以维护,虽然多年来它已经变得稍微灵活,但它仍然坚持着workbench严格硬编码结构和布局模型:一个workbench包含多个workbench window,一个workbench window包含一个或多个workbench page,每个page又包含一个editor area、一组view stack以及一些硬编码的修建元素(透视图切换按钮、进度指示器等)。应用程序设计者在定制Eclipse应用的结构时有一些严格的限制。

      E4 workbench为应用设计者大大提高了灵活性,因为它提供了一个正式的workbench组件元素的模型,应用可以重新装配或扩展这个模型来实现各种不同的应用展现,而无需编码.将workbench结构标准化为一个定义明确的模型有个额外的好处,就是使workbench代码更加简单,而且更少的潜在错误。最重要的是,这使一些非常不同的workbench UI布局成为可能,比如视图或者编辑器可以脱离透视图,对话框中放视图或编辑器,以及其他一些老Eclipse平台不允许的设计。

      有了模型,还可以为应用设计者提供更加高级的工具,比如可视化设计工具。可以在运行时操作E4 workbench模型,模型将立即反应到UI上.

      这开创了脚本式操作workbench结构和状态的先河,就像JavaScript操作web浏览器中dom一样，下图3中，我们可以看到定制正在运行的应用的模型编辑器，这个例子中,正在改变传统Eclipse问题视图的name和tootip。

图3 e4 模型编辑器

     E4 workbench模型被翻译成小部件。workbench自带一个默认的翻译器,可以将模型翻译成SWT小部件,也支持扩展翻译器为模型元素提供不同的翻译。这可用于为某部件提供细微变化,甚至翻译成完全不同的部件库或类似web浏览器的运行时环境。

     翻译器是在单个模型元素级别提供的,而不是为整个应用提供一个翻译器。单个翻译器可以为一个或多个模型元素提供翻译,多个翻译器也可以为单个模型元素提供翻译,这种精细的可扩展性运行用户用他们自己的元素扩展workbench模型,然后提供自定义的翻译器来以一种特别的方式翻译这些元素。

   

五、声明式样式

      workbench模型到小部件的基本翻译是由翻译器完成的,可拔插的样式引擎则可以用于定制部件的字体、颜色以及其他方面。我们知道web展现技术中分离文档结构(html)和样式(CSS)，保证了多个文档可以有一致的用户体验,而且也很容易在单个地方变化样式。

      基于模型的UI对E4样式引擎是透明的,事实上这个引擎可以完全独立的运行在早期的Eclipse中,具体部件和样式数据作为引擎的输入,将样式应用与部件实例上就生成了样式结果。下图4显示了一个完成流程:模型通过一个或多个翻译器变成了部件.然后通过样式引擎和声明式样式数据(CSS文件)产生了最终结果。

     图4 翻译器和样式数据流

    E4中声明式样式是基于标准CSS语法的,支持HTML CSS中大部分属性名和类型格式,比如字体、边距、颜色等,此外,E4还有自定义的属性以及Eclipse部件特有的伪选择器(pseudo selectors).CSS你可以使用类型选择器,E4中你可以使用部件类名作为选择器.E4还支持CSS class选择器和ID,所以同一个部件可以有不同样式。同样,E4用CSS伪类(pseudo-classes)来基于部件状态选择样式规则,这让你可以为被选的tab设置不同的字体样式。比如,下面片段为普通的tabFolder指定一种样式,为被选择的编辑器指定了一个不同颜色：

CTabFolder {

background-color: rgb(241, 240, 245);

font: normal;

}

CTabFolder.editors:selected {

background-color: rgb(255, 255, 255) rgb(255, 247, 229);

}

      CSS类和伪类的使用,使workbench部件(视图、编辑器）以及特定状态部件的样式高度可定制。比如正在运行后台任务的视图可以标记为忙，样式则可以描述怎样展现这个状态:不同的字体、改变的边距,如甚至没有样式,最终将使应用更容易被用户理解和使用。

 

6、Web 到 桌面

        过去的几年中,浏览器应用和桌面应用的界限已经变得模糊，应用中的浏览器、部件和语言框架的复杂性也在接近桌面系统。与此同时,桌面应用正变得web化,也在采用一些web应用的用户交互方式和样式标记。一段时间内,桌面应用和浏览器应用的需求都将存在,而且是软件组件能同时运行在两种环境中的需求越来越多。在面向组件的软件(如Eclpse)中,我们不再选择目标平台,然后从头到尾的构建整个软件。我们基于大量的可用组件,然后将它们组织一起构建一个符合我们需求的应用。如果我们能在多个运行环境中服用同一组件,将大大减少开发和维护成本。

        E4正在以多种方式探索在多个目标平台和技术间复用组件。其中一种是用JavaScript写Eclipse插件。作为客户端浏览器编程语言的事实标准,JavaScript对于那些寻求编写可在多种运行时环境中运行的组件的人，这将是一个非常好的选择。

        为此,E4正在研究将Eclipse的优势(模块化、可拓展性、开发工具)带入到JavaScript世界中,并将JavaScript组件融入到Eclipse桌面环境中,虽然E4的焦点在JavaScript上,但这项工作的意图更加广泛:让多种不同语言编写Eclipse插件变得更加简单。

       虽然JavaScript被长期用于浏览器脚本语言,但很少用于构建类似与我们在Java世界中看到的大型应用。它的一个缺点是缺少模块化机制。没有定义和访问命名空间以及表示JavaScript代码段依赖的机制，也没有以一种可扩展的方式查询和消费其他组件定义的服务机制。在Java和Eclipse中,我们有强大和成熟的OSGI模块化系统,可以满足这些需求。

       为了解决这些限制,E4在OSGI基础上引入一个模块化框架,用于JavaScript应用.它允许创建模块,创建大规模纯JavaScript应用,甚至把JavaScript Bundle集成到传统的基于Java的OSGI运行时中。图5说明了E4 JavaScript框架架构，以及它和纯JavaScript Bundle、标准JavaScript Bundle、标准Java Bundle之间的关系。

图5 e4 JavaScript框架

    

   E4 JavaScript框架是用Java写的，运行为一个纯OSGI Bundle。它负责解析JavaScript Bundle的描述文件(manifests),并分析JavaScript Bundle之间的依赖。JavaScript Bundle以及它们的依赖关系对OSGI框架是透明的:JavaScript框架本质上完全是一个OSGI实例中嵌套的框架。JavaScript Bundle间的依赖关系可表示在bundle级别(就像OSGI信息头中的Require-Bundle)，或者在单个脚本文件级别(类似OSGI信息头的Import-Package)，这些依赖表示在JavaScript manifest中(一个JSON文件).下面是一个简单JavaScript bundle manifest例子：

{      "Bundle-SymbolicName":"sample.jsbundle",      "Bundle-Version":"1.0",      "Bundle-ScriptPath":"script.js",      "Import-Package":"a.resource;version=[1.0.0,2.0.0)",      "Export-Package":"sample.resource;version=1.0.0",      "Require-Bundle:"some.other.bundle",     }     JavaScript Bundle 可用编程的方式定义或安装到框架中，还可在标准OSGI Bundle中,用额外的manifest header声明JavaScript bundle的存在：

JavaScript-Bundle:scripts/manifest.json

虽然JavaScript bundle和Java Bundle可通过直接调用来交互,但推荐的方式是通过OSGI服务注册表或是使用扩展点。比如JavaScript Bundle可以声明为一个标准的OSGI Bundle,然后编程式的使用类似OSIG DS的声明机制向OSGI服务注册表贡献服务。标准的OSGI Bundle就可以消费这些服务,而根本不知道这些服务的实现是用JavaScript编写的。

同样,E4 JavaScript框架提供Eclipse扩展工厂来实例化纯JavaScript写的Eclipse扩展。JavaScript bundle可以简单声明一个plugin.xml文件来记录向扩展点注册表中的扩展,而不需要写一行Java代码。Java写的Bundle就可以消费这些扩展是用另外一种语言写的。相反,JavaScript Bundle可以用一些相应的Java API声明一个扩展点,这些API可被Java Bundle实现,然后加载并用JavaScript代码向这个扩展点提供扩展。

 这些JavaScript Bundle和Java Bundle间的交互在图5可以看到。

 E4 JavaScript框架本身用Java和JavaScript定义API，这样纯Java Bundle可以查询或操作JavaScript框架(比如安装一个新的JavaScript Bundle),JavaScript写的Bundle可以通过框架的JavaScript API与框架交互。图5中E4 JavaScript框架同时扩展Java和JavaScript说明了这一点。

 E4 编程模型还简化了集成其他语言实现的组件。通过组件间基于服务的交互、依赖注入，组件不必知道服务用哪种语言实现,也不必知道用什么语言消费它们暴露的服务。类似的,消减后的Eclipse应用服务可以暴露为其他语言的API，所以Eclipse平台的大量功能可被其他语言实现的Bundle实现。

  用于与这些核心E4服务交互的少量JavaScript API现在已经可用,它们定义在org.eclipse.e4.ui.web.bundle中，作为概念的怎么,e4包含了一个用纯JavaScript实现的PDE update site编辑器（见图6)，这个编辑器可在web浏览器中运行,还可以无缝集成到Eclipse平台UI中。

图6 e4 JavaScript site编辑器

   

7、桌面到Web

         我们已经展示了web组件怎样集成到Eclpse平台中，然而,用传统Java语言实现的桌面应用也可以移植到web平台，E4有两个研究方向与此有关：新的SWT移植平台、Eclipse Rich  Ajax Platform(RAP).

         Eclipse SWT为桌面图像应用(可跨多个操作系统)提供了通用API，它允许开发者只写一次即可得到多个目标平台的高性能、具有本地化外观的应用。同样,web浏览器编程有多种语言和部件工具包。

         web技术变化迅速，由于担心过时,应用开发者都不愿只掌握一门技术，E4中SWT的新移植版本(称为SWT浏览器版本,SWT/BE)旨在为web ui 编程提供一个通用平台,就像它已经为桌面应用编程所做的那样。这潜在的运行已有的SWT应用运行在Web上，并运行开发者构建web ui应用而不必锁定在某个web技术中。

         SWT/BE现在支持ActionScript/Flex作为此技术的原型样例，但移植到其他web平台，比如JavaScript/Dojo、Sliverlight、JavaFX等，也是可能的。图7显示了运行在Adobe Flex上的SWT组件样例，它包括所有SWT主要部件。

      图7 Flex上的SWT 控件样例

 

     Eclipse Rich Ajax Platform(RAP)提供了运行在Web上的SWT、JFace、Workbench UI实现。类似SWT/BE，RAP为同一个应用运行即运行在桌面又运行在web上提供了可能。然而，原始的RAP实现需要一些Eclipse平台代码来支持web目标环境。特别的，web应用通常必须支持在一个应用实例中存在多个并发的用户会话，由于大量使用单例，Eclipse workbench 通常不支持这个。

     图8 RAP构架

 

     E4编程模型由于它面向服务注入的编程方式，使得它更适用于多并发会话。早期实现中在RAP运行时上运行的E4应用已经预示,workbench仅需要较少的变化即可运行在RAP上，RAP集成工作为E4的目标(支持多种运行时环境是可以实现的)提供了验证。在类似RAP的目标平台上运行E4应用的工作，有助于保证E4架构和编程模型的持续灵活性和开放性。

 

八、声明式组件

       基于模型的E4 workbench 为workbench本身提供了一个抽象的展现:windows、pages、perspectives、view等。此模型用翻译器可以翻译成SWT，可用声明式引擎进行定制。然而,在单个workbench视图内，UI仍然用普通的SWT插件。这些SWT代码通常重复，而且样式被硬编码。为了解决这些问题，E4正在探索将模型/翻译器概念应用于SWT的所有方面。目前这个探索有两个方向：基于XML的小部件(XWT)和基于模型的小部件。

       1)、 XWT：基于XML的声明式组件

        XML Window Toolkit,XML  UI for SWT是一个框架，可将SWT小部件声明在xml中，应用所有结构、小部件的层次、小部件到特定底层应用模型的绑定，以及小部件到实现小部件行为的Java回调的绑定都是声明式的。

        XWT以声明式的UI数据作为输入，与应用模型一起生成小部件。XWT包含一个符合javabean规范(简单数据访问器和setter方法)的类的简单模型。其他方法可以通过扩展点向SWT扩展。

        XWT UI 生成器组合声明式UI数据和模型定义，生成运行时SWT/JFace空间。图9展示了XWT的架构。

图9 XWT 架构

 

      2) TM：基于EMF的声明式组件

         Toolkit Model(TM)是UI元素的抽象EMF模型。在应用运行时，此模型被绑定到一组具体的小部件(比如SWT)上，TM构建器在这个模型与小部件间双向传播变化，以保持他们的同步。应用在运行时通常与TM而不是具体的小部件交互，这让应用开发者面对一个更简单的抽象来工作。

        这个更高级的部件抽象使改变具体部件实现成为可能，可以以更精细的方式改变，也可以是根本的改变，比如与运行在不同进程或者不同物理机上的小部件实例进行交互。举例来说，一个运行在web服务器上的应用可以操作此服务器上的toolkit模型，并且TM运行时可以透明的用运行在不同机器上的小部件实现这个模型，比如一个web浏览器客户端。

         Toolkit模型中事件由JavaScript实现的事件处理器处理，也可以用Jaa实现。JavaScript与Toolkit模型交互的方式与JavaScript与操作Html DOM类似。由于有图形工具可用于构建或操作EMF模型，这种EMF和JavaScript的组合可以进行应用的快速原型设计。

         图9展示了TM架构。构建器负责创建小组件并把它们绑定到模型上，这是通过为每一种创建的小部件找到一个合适的绑定器实现的。绑定器创建具体的小部件，并在创建后管理小部件和模型元素间的同步。每种小部件有一个绑定器，而不是每个部件实例一个绑定器。JavaScript代码为模型提供动态行为，包括部件事件的回调和其他应用行为。

图10 TM构架

 

        3) 灵活的资源模型

         开发工具仍在Eclipse生态系统中保持着重要角色。许多IDE开发者都希望以前版本的Eclipse支持更复杂的工程结构。由于Eclipse严格 的资源模型限制，一些开发工具的用户很难把已经规划好的源码及其他资源的结构应用在基于Eclipse的IDE中。E4引入了新的增强的资源模型，以更好的支持在workspace导入和管理更复杂的工程结构。这些增强包括：

1. 可以在工程级别定义路径变量，并创建相对于这些变量的廉洁资源。这使得移动那些包含复杂链接结构工程时，不会破坏链接
2. 称为组的新的虚拟文件夹。组不存在于文件系统中，但他们可用于创建任意复杂的、包含资源链接的虚拟工程数。
3. 支持工程和文件夹过滤，可从eclipse workspace树中排除特定资源或符合某模式的资源。过滤器运行Eclipse工程包含持有大量元素的文件夹，但仅有一小部分元素在工程中，排除的资源将不占用内存。
4. 通过拖拽来创建和管理链接资源。从Eclipse外拖拽一个文件夹树时，你可以把这个树作为包含链接和组的虚拟树放到Eclipse workbench中，而不是作为一个具体的文件系统树。
5. 运行编辑已有链接资源的位置，或把链接在绝对路径和相对变量的路径之间来回转换。

   

       这些增强综合起来可以让用户在workspace中快速搭建复杂的工程结构，并与其他用户共享这些工程，而虚拟工程结构保持完好。

 

十、结论

       E4工程引入了很多新技术使Eclipse平台的架构和设计原则更加现代。这些变化使平台更加开放，支持更多的编程语言和目标运行时环境，从而使Eclipse平台的未来更加美好。E4组件将更容易定制、配置并在不同的应用中复用，而无需修改。从应用逻辑中分离样式和展现逻辑，可使Eclipse应用以一致的方式方便 的更换皮肤。遵守E4设计原则的开发者，在构建组件和应用时，将与底层操作系统和web浏览器技术变得更加隔离。

 

 

  感谢：

John Arthorne, IBM Canada Inc.

Last modified July 29, 2009

译者： 天马