MDA方法在网格计算平台Gbuilder开发中的研究与实现

摘　要:利用网格基础中间件GT3 (Globus Toolkit 3. x)进行网格服务设计时代码工作量大,且调试过程不清晰,而在所有的网格服务或同一类型的服务中都有着一些共同的实现模块和操作步骤,对这些部分用模型和模板来实现将减少重复的工作量。所以文中在开放源码的开发工具Eclip se平台上实现了基于GT3开发网格服务的流程,该实现的最大目标就是代码自动化生成,达到终极编程的目的。采用的思想是MDA,并给出了GBuilder平台下用MDA方法实现网格服务工作流的设计框架。

引　言

随着现代高科技的发展,以网络为基础的科学活动环境已经成为当前国内外研究的热点和前沿领域,已经引起各国政府、科研部门和业界的极大关注。当前网格计算的研究内容主要围绕以下几个方面展开: (1) 底层支撑软件的研究,目前有代表性的有Globus Toolkit; (2) 利用底层支撑软件的大规模应用; (3) 利于网格快速开发应用和部署的辅助软件,例如IBM网格计算工具包; (4) 其他研究性的辅助软件:网格计算的仿真工具如GridSim等。但是有利于网格快速开发应用和部署的辅助软件目前可见的成果并不多,各个研究者在开发网格应用的时候不得不花费大量的时间在安装、配置、调试等方面,甚至利用像Globus Toolkit这种工具搭建一个小型的网格计算实验环境都不是一件容易的事情,所以成为构建Gbuilder平台的初衷, 其概念模型如图1 所示。Gbuilder就是一种网格计算辅助开发和部署的软件,其主要目标是利用先进的软件技术开发一个适合于各种网格计算工具箱的、提供网格应用建模、调试、部署和测试功能的通用的辅助的软件平台。该平台的目的有以下几点: (1) 最大化的降低开发网格应用的难度; (2) 通过模型和配置使新应用从示范和典型应用中获利; (3) 通过软件组件接口技术上层应用对工具箱的依赖,例如可以平滑的用新的Toolkit代替原来的Globus Toolkit,从而保护现有的投资。



MDA方法的工作原理和实现

MDA的概念和原理

模型驱动体系结构MDA是OMG (对象管理组织)于2001年7月发布的一种基于模型的体系结构,可以说MDA的初衷是为了解决软件互操作、可移植性和可重用性等问题。MDA中的基本概念有模型、抽象、求精、视图、缩放和平台。(1) 模型是对系统的一部分结构、功能或行为的描述; ( 2) 抽象:在一个客观系统中可以挖掘出无穷多的细节,一个系统的任何规约都只是从一个特定的角度描述了这个系统的某个层面,都是对这个客观系统的某种程度上的抽象; (3) 视图:这种特定的角度(或者说抽象程度)就是视图; (4) 求精就是现实化; (5) 缩/放:从抽象模型中的一个对象(关系)到求精模型中的多个对象(关系)的过程称为放,反之称为缩; (6) 平台:独立于软硬件环境的一种新型开发环境,该平台将模型分成平台独立模型(PIM)和平台相关模型( PSM) ,实现了系统的功能描述和系统在特定平台上的实现分离开。PIM是对系统的功能和结构的抽象描述,PSM是在特定的目标平台上对系统的功能求精过程,但不是等同于具体与平台相关的计算机语言,而是生成模型语言。

OMG规定了4种PIM和PSM之间的映射,(1) P IM→P IM:要求进一步对P IM模型的功能增强、求精和过滤,将分析模型映射成设计模型P IM;(2) P IM→PSM:将平台无关的设计模型映射到平台相关的实现模型; ( 3) PSM→PSM:同( 1)一样是对PSM模型的求精; (4) PSM→P IM是(2)的逆变换,从不同的PSM中提取与平台无关的模型或关联模型。开发平台目前有很多,所以模型驱动的企业计算也很多,它们如何实现和体现MDA思想,最主要考虑的是PIM和PSM之间的映射,如图2所示。从图2中可见,MDA一方面能够创建出机器可读的PSM和高度抽象的P IM,这些模型独立于任何具体的实际开发技术,以OMG提供的标准化方式来编写和储存对应的模型,这些标准具体是基于UML、MOF、XM I、CWM和CORBA等标准框架;另一方面,由P IM到PSM的一对多映射关系可知这些模型可以被重复访问,并被自动转化为纲要( Schema) 、代码框架(Code Skeleton) 、测试工具、集成化代码以及各种平台的部署描述形式。



　　MDA建模和模型映射技术是MDA的核心,支持这两个技术的对象模型有元对象设施(MetaObject Facility,MOF)的M₀ - M₃ 等4 层元模型元素、统一建模语言(UnifiedModeling Language,UML)元素和公共仓库元模型(Common Warehouse Metamodel, CWM) 。(1) MOF:M₀ - M₃ 表示的抽象层次是越来越高,M0 为运行时实例模型,M1 为用户模型,M₂ 为UML 模型和M₃ 为MOF自述模型; ( 2)UML:与其它元模型相比,它具有以下3个方面的优点,模型不仅可以用图形化的方式表达,也可以用文本方式表达;模型的语义表达能力十分突出,尤其是在表达行为和用法的约束方面比其他元模型要丰富得多; UML 对P IM 和PSM 都有良好的建模能力;(3) CWM:是一组元模型,目的是为了在数据仓库工具、数据仓库平台和数据仓库存储之间建立一个商务智能元数据的交换机制。

MDA的特点
MDA的软件开发是首先采用一组元模型为系统建模,然后利用模型映射技术完成软件的逐步求精过程,并保证了这个过程的可逆性,最后利用模型编译器将生成的可执行模型转化成相应的软件平台,即代码自动生成过程。这种开发模式与传统的面向过程和面向对象软件开发模式之间存在以下7个方面有所改进。(1) 异构系统协作; (2) 空间失配问题; (3)专用的元模型和模型映射技术; (4) 元模型和模型映射技术共享; (5) 模型重用; (6) 流水线式开发; (7)从模型到元模型。从软件技术发展的历程上来看,过程求精编程技术的解空间(或目标代码)处于数据层,面向对象技术把解空间提升到了模型层,而MDA则把解空间提升到了元模型层。具体可以从表1看出这3种不同开发模式之间的异同。



　　MDA方法除了以上4方面的区别外,还具有以下6点优点。(1) 完善的文档:因为模型本身就是文档,而且模型驱动的开发方式是以模型为起点,所以项目一开始就有完善的文档; (2) 准确:由于代码是生成的,所以要比手写的来的准确,能准确地表达设计意图; (3) 效率高:由模型描述出的类,多而且繁杂,手写很费时间,生成就省事多了,也不容易出错; ( 4) 提高了抽象水平; ( 5) 提高了软件质量;(6) 减少了项目的开发和维护周期。

MDA的实现及存在的问题
MDA目前还处于萌芽阶段,在基于MDA的软件开发技术真正实用化之前,还有许多技术领域有待研究,它们大致包括:
( 1) 元模型和模型映射方法论研究:MDA的完善相当程度上是元模型和模型映射技术的完善,如何建立元模型和相应的模型映射技术都需要方法论的指导;
( 2) 领域元模型的建立:针对各种不同的应用领域,要建立大量的基于MOF的元模型。这些元模型要包含应用领域的特殊规则和语义,既要严格没有歧义,又要容易为非计算机专业的领域专家所掌握;
( 3) 组件平台元模型的建立:针对各种组件平台,要建立专门的平台元模型,以支持平台相关模型的建立和代码生成;
(4) 模型映射技术的开发:在大量的元模型之间,都需要模型映射技术来辅助开发人员进行高效的模型映射。有了高效的模型映射技术, 才能真正走向实用;
(5) MDA中间元模型研究:两个元模型如果异构程度太高的话,针对这两种元模型的模型映射工具会难以开发,或者映射效率低,需要大量的人工干预。这样就要考虑在这两个元模型中间建立一个中间元模型,以这个中间元模型作为桥梁进行模型映射。在什么情况下需要构建以及如何构建中间元模型,都是有待研究的问题;
(6) 元模型和模型映射的评价理论研究:在特定的应用环境下,什么样的元模型才是高效的,什么样的模型映射工具才是高效的,都需要评价理论来指导。这样开发人员才能在众多相互竞争的元模型和模型映射工具种选择最适合自己的一种。这些有待改进的地方,诸多也是MDA 目前所表现出来的不足,对此缺点本文就不叙述了。

以上不足只是针对MDA在所有企业计算中可能存在并要解决的问题,这些对于网格计算平台Gbuilder的实现道路上同样起到制约作用。为了研究的方便,在开发过程中采用IBM公司提供的开放源码开发平台Eclip se3. 1 (中文版) , 该平台下的EMF插件和GEF插件为实现和体现MDA思想提供了诸多的方便,在网格计算平台Gbuilder中实现由模型到自动生成代码的过程:生成P IM模型→映射成PSM模型→自动生成代码,具体设计思想和实现中用到的技术如图3所示。



MDA在Gbuilder平台中的应用与实现

网格计算平台Gbu ilder的体系结构
Gbuilder的体系结构是一个层次化的体系结构,最上层提供面向用户的接口,中间部分负责逻辑处理,底层适配器负责调用和封装网格计算中间件软件如Globus工具箱等。Gbuilder组成部分的具体功能包括以下几个方面: (1) 命令控制器; (2) 解释器;(3) 模型驱动器; (4) 创建工厂; (5) 插件管理器;(6) 适配工厂/适配器; (7) 图形用户接口; (8) 策略集、模型库、配置集。这里仅就当前项目的实现状况来详述用户界面、代码生成和网格适配3个方面。

用户界面UI
良好的用户接口是开发符合用户需求的软件的一个很重要的方面,通过增加图形用户接口的数量和质量可以大大提供最终用户的体验。我们的图形用户接口将基于Eclip se的JFace /VE等来开发,其基本面是基于SWT的。目前项目该模块能生成新建一个空白网格服务向导和根据已有的网格实例来熟悉生成过程,如图4所示。图4中文本框中要输入的内容是创建一个网格服务必须的一些信息。

图4　基于Eclipse的Gbu ilder平台项目向导

　　该部分已经将代码生成模块结合起来,即可以将现有的网格服务实例或新建的网格服务项目相关的接口定义、接口实现、网格服务部署、网格服务容器发布和客户端请求程序结合起来,生成对应的代码和完成客户端的网格服务需求,这里以已有的网格服务math为向导,点击“完成”按钮后,如图5所示。同时能借助Eclip se提供的平台开发环境PDE这一功能模块,进行代码编译、解释和执行。随着项目的进展,我们将建立自己的一套更符合网格计算的词法分析和语法分析,这样会提高建立一个网格服务的时间,当前由图4提供的网格服务从新建到发布需要等待的时间将长,不过这比起在命令控制台下一步步的定义和执行命令快了不知多少倍;而且也不容易出错,减少了控制台下输入所带来的手误;同时在项目中嵌入了Tomcat容器,这样减少了设置端口会带来的冲突问题。



代码自动生成
通过图5最终生成的基于MathService的网格服务的部署成功,并能在客户端实现常见的数学运算(加减乘除,三角函数和矩阵运算) 。一般可以将代码生成技术分为被动模式和主动模式两类,而常用的主动模式代码生成系统有模型驱动的代码生成系统、数据文件驱动的代码生成系统和源文件驱动的代码生成系统。图6是Gbuilder中采用的代码生成框架,图6中UML 模型接收来自各种UML 建模工具产生的UML模型(Gbuilder中集成了开源的UML工具)转换成XML模型,这种输入方式是为了实现Gbuilder中基于模型驱动开发的方法。

图6中图形在用户界面,则通过提供的一系列GU I视图接收用户的参数输入并形成模板引擎的输入文件,形成定义文件,定义文件采用XML格式利于模块间数据交换。代码引擎部分是框架结构的核心,它综合利用了多种代码生成技术,例如采用XDoclet引擎,XDoclet引擎是一种代码挑拣器,它可以通过Java文件中特定的标记( TAG)来生成各种代码,例如EJB的接口定义类、Hibernate 的O /R 映射文件等等。目前很多模型驱动的软件, 例如著名的An2droMDA都采用它作为代码生成的核心组件,另外引擎采用的是Velocity 。网格计算应用目前的主流结构是采用符合OGSA 标准网格中间件, 例如GT3 (GlobusToolkit3) ,通常一个网格计算应用包含接口描述文件( GWSDL) 、网格服务实现文件、网格部署描述文件、Web Service的存根文件等等。利用代码生成技术只需要建构(模型的方法)特定的接口实现就可以完成一个简单网格服务的开发。对于复杂的网格服务也只需要关注特定的逻辑功能而不需要撰写大量的框架代码。代码生成框架为此提供了便利。



网格服务适配器

如图1所示,适配器在Gbuilder平台的开发中属于最底层的功能模块。Global Grid Forum ( GGF)的OGSI工作小组于2002年6月制定的开放网格服务架构(Open Grid ServicesArchitecture,OGSA)为基于网格的应用定义了通用标准的体系结构,相应的OGSI(Open Grid Services Infrastructures)规范扩展了标准Web服务,为网格服务定义了标准的接口、行为和交互。而Globus Toolkit适配器的目的是为了让不同的ToolKit能够对平台上层提供一致的接口,以便于模块之间的调用和消息传递。因此我们适配的目标就是符合OGSA /OGSI标准的一系列接口。但是由于标准制定主要参照Globus Toolkit、制定时间晚于工具箱的开发等诸多原因,并非所有的网格服务工具箱的接口都严格遵照这一标准而定义。所以,要使GBuilder能够使用各个工具箱、自动完成在不同工具箱间进行转换、并且能基于不同工具箱进行协同应用,我们所设计的Globus Toolkit适配器就势必要在多个适配源中完成自动的选择性适配,该模型的功能详细设计框架如图7所示。



网格服务工作流
模型驱动器实现网格服务工作流的概念借鉴了模型驱动开发(MDA)的概念,通过模型至少是预先定义的一些模型允许用户完成基于模型的网格应用开发,模型驱动器用来处理这些模型。一个简单的模型驱动器的实现是基于状态机和组合模式两种设计模式,根据网格的应用类型我们将网格计算分为数据密集、任务密集、普遍共享等几种形式,并将模型按照这些形式进行分类从而方便最终用户的使用。

EMF是遵循MDA思想设计的,它是MDA在Eclip se平台上的实现。模型本身用元模型来描述,通过使用映射,使其产生相应实时转换的软件。模型的生成可以通过以下3种方式: (1) 利用XM I直接书写; (2) 利用Rational Rose或Omondo Eclip se2UML插件生成,并导出XM I文件; (3) 利用Java接口刻画模型属性。映射有2类: ( 1) 由元数据交换生成XML、DTD和XSD; ( 2) 元数据接口生成Java或其它语言IDL代码。

GEF必须先拥有一个以图形方式显示和编辑的模型PIM, GEF查看器是基于基于模型—视图—控制器(ModelViewController,MVC)体系结构的。其中M:模型是唯一会被持久存储和恢复的东西,应用程序应当将所有重要数据都存储在模型中,在编辑、撤销和重做的过程中,模型是唯一保持不变的; V: GEF提供了图形的和基于树的两种查看器类型,每种查看器都主管一种不同类型的视图。图形查看器使用了在SWT画布(Canvas)上绘制的图形(Figure) ,图形是在Draw2D插件中定义的,该插件是GEF的一部分;C:控制器作为视图和模型之间的桥梁。基于图3的设计思路,结合网格服务具体问题,MDA可以应用在网格服务开发的工作流有2种:不通过Ant;通过Ant。具体工作流设计如图8所示。



结束语

使网格服务从接口描述到部署整个过程中涉及到的代码都自动产生,利用到的工具有Velocity、XDoclet、Eclip se (EMF + GEF +Draw2D)以及一些其它辅助插件,所以MDA方法将是软件开发过程发展的必然实现,但目前业界对MDA 编程只是一个摸索,MDA仍然是在OMG标准下提出的。图8给出的网格服务工作流在图4中已经初步实现,但随着Gbuilder平台的不断改进,将使这一思想在网格计算中得到应用,为广大网格爱好者提供方便,使编程环节中实现以下几点: (1) 方便快捷的建立、部署和完成一个网格服务; (2) 使相同的部分尽量以模板文件来代替原语言文件,减少代码的冗余; (3) 一个完整的网格服务从服务端到客户端的实现尽量实现操作的可视化,使MDA 思想得以展现; ( 4 ) 对OGSA /OGSI规范和技术的接口部分能完好适配,方便各方工具的升级和维护,尽可能的达到一致性。本文利用MDA方法和原理,结合网格计算平台的开发来体现终极编程思想,但是在具体实现以上思想时还有待完善。