级别: 初级
樊 宁, 实习生, IBM中国软件开发中心, WebSphere Commerce组
2006 年 9 月 11 日
本文将介绍网格技术目前流行的三个网格体系结构,五层沙漏结构(Five-Level Sandglass Architecture)、开放网格服务体系结构(Open Grid Services Architecture,OGSA)、Web 服务资源框架(Web Services Resource Framework,WSRF),以及它们的实现和支撑技术。
1 引言
网格体系结构是关于如何构建网格的技术,它包括两个层次的内涵。一是要标识出网格系统由哪些部分组成,清晰地描述出各个部分的功 能、目的和特点。二是要描述网格各个组成部分之间的关系,如何将各个部分有机地结合在一起,形成完整的网格系统,从而保证网格有效地运转,也就是将各个部 分进行集成的方式或方法。网格技术的权威伊安 ▪ 福斯特(Ian Foster)将网格体系结构定义为“划分系统基本组件,指定系统组件的目的与功能,说明组件之间如何相互作用的技术”。显然,网格体系结构是网格的骨 架,只有建立合理的网格体系结构,才能设计和构建好网格。
到目前为止,主流的网格体系结构主要有三个:第一个是伊安 ▪ 福斯特等人在早些时候提出的五层沙漏结构(Five-Level Sandglass Architecture);第二个是在以IBM为代表的工业界的影响下,考虑到Web技术的发展与影响后,伊安 ▪ 福斯特等结合五层沙漏结构和Web Service提出的OGSA(Open Grid Services Architecture,开放网格服务体系结构);第三个是由Globus联盟、IBM和HP于2004年初共同提出的WSRF(Web Service Resource Framework,Web服务资源框架),WSRF v1.2规范已于2006年4月3日被批准为OASIS(Organization for the Advancement of Structured Information Standards,结构化信息标准促进组织)标准。
下面将介绍网格的基本组件,即网格的基本功能模块和三种具体网格体系结构。
2 网格的基本功能模块
研究网格体系结构的目的是为了更好地实现网格,因此在网格体系结构的研究过程中,首先需要确定的就是网格系统到底由哪些基本的功能模块组成的,它们之间如何有机地组合,成为一个完整的网格系统。
网格是建立在现有国际互联网的基础之上的,使用了互联网的IP地址、网络传输协议等概念和技术,它需要已有的一些互联网协议和规范 作为支持,如超文本传输协议(HTTP)、文件传输协议(FTP)、简单邮件传输协议(SMTP),这些都是互联网上的成熟协议,将它们用作网格协议的传 输载体就为方便地构建网格打下了一定基础。当然全盘照用这些协议还是不能满足网格的需求的,例如HTTP协议是为网页浏览而制定的,使用“请求——应答” 的方式,但在网格中除了这种消息请求方式外,还有主动推送等其他的消息方式。因此在构建网格时,还需要在现有互联网协议的基础上加以扩展。
互联网完成的功能在网格体系结构中就不再考虑了,以网格数据为例,网格需要考虑到是数据表示形式、数据的传输方式、数据存储和副本管理,但对具体的数据传输格式和传输过程使用FTP或是UDP协议则不再考虑,因为这些是互联网解决的问题。
网格体系结构要考虑到是如何向用户提供一个接口,通过该接口接收来自用户的请求,发送来自网格的信息。用户可以将所使用的网格看作 是一个黑盒子,不必知道其内部如何实现用户请求的服务。实际上,网格系统中是由一系列的基本功能模块协作,向用户提供服务的,网格系统的基本功能模块如图 1所示。
网格用户通过用户界面实现与网格之间的信息交互,实现诸如用户作业提交、结果返回等输入输出功能。网格在提供服务之前要知道哪个资 源当前可以向用户提供服务,这就需要网格中信息管理模块提供相应的信息。选定合适的资源后,网格需要把该资源分配给用户使用,并对使用的过程中的资源进行 管理,这些是资源管理的功能。网格在提供服务的过程中需要网格数据管理功能模块将远程数据传输到所需节点,作业运行过程中由作业管理模块提供作业的运行情 况汇报。使用网格的用户及其使用时间和费用等的管理则由用户和记账管理模块实现,用户使用网格的整个过程中都需要QoS(Quality of Service,服务质量)保证、通信和安全保障,以提供安全可靠、高性能的服务。
当然,以上仅仅是对网格系统中基本功能模块的简单描述,实际上各个功能模块的功能远远不止这些,几个主要功能模块的详细情况见本章后续部分中的介绍。
为了实现上述功能要求的网格系统可以有不同的实现方案。举个例子,如果将网格系统比作一个房子,房子的基本功能可能是向使用者提供 睡觉、吃饭、会客、洗漱等功能,这些功能可比作网格中的资源管理、作业管理等功能模块。具体建造房子的时候,可以建造各个不同的房间以实现不同的功能,而 各个房间如何布局就要依据使用者的要求各不相同了。如何实现布局各个房间以及安排其功能,设计出房子的结构图,就是房子的“体系结构”要解决的问题,各人 设计的房屋“体系结构”相差很大,有的是别墅,有的是平房,但都必须要实现房子的基本功能。网格也是如此,建造网格需要依据网格的“结构图”——网格体系 结构,网格体系结构决定了网格系统由哪些模块实现网格的各个功能,模块之间如何有机地组合成完整的网格系统。当然,实现同样功能的网格体系结构是各不相同 的,依据它们构建的网格系统也是各不相同,以下就介绍已有的几个网格体系结构。
3 五层沙漏体系结构
五层沙漏结构是由伊安 ▪ 福斯特等提出的一种具有代表性的网格体系结构,其影响十分广泛,它的特点就是简单,主要侧重于定性的描述而不是具体的协议定义,容易从整体上进行理解。在 五层沙漏体系结构中,最基本的思想就是:以协议为中心,强调服务与API和SDK的重要性。
五层沙漏结构的设计原则就是要保持参与的开销最小,即作为基础的核心协议较少,类似于OS内核,以方便移植。另外,沙漏结构管辖多种资源,允许局部控制,可用来构建高层的、特定领域的应用服务,支持广泛的适应性。
3.1 五层结构的划分
五层沙漏结构根据该结构中各组成部分与共享资源的距离,将对共享资源进行操作、管理和使用的功能分散在五个不同的层次,由下至上分 别为构造层(Fabric)、连接层(Connectivity)、资源层(Resource)、汇聚层(Collective)和应用层 (Application)。如图2所示。
在五层结构中,资源层和连接层共同组成了瓶颈部分,使得该结构呈沙漏形状。其内在的含义就是各部分协议的数量是不同的,对于其最核 心的部分,要能够实现上层各种协议向核心协议的映射,同时实现核心协议向下层各种协议的映射,核心协议在所有支持网格计算的地点都应该得到支持,因此核心 协议的数量不应该太多,这样核心协议就形成了协议层次结构中的一个瓶颈。
为了便于理解,我们可以将该结构这五层与广为使用的TCP/IP网络协议结构进行粗略的对比,如图3所示。
3.2 各层结构的描述
下面对五层的功能特点分别进行描述。
(1)构造层
构造层的基本功能就是控制局部的资源,包括查询机制(发现资源的结构和状态等信息)、控制服务质量的资源管理能力等,并向上提供访 问这些资源的接口。构造层资源是非常广泛的,可以是计算资源、存储系统、目录、网络资源以及传感器等等。构造层资源提供的功能越丰富,则构造层资源可以支 持的高级共享操作就越多,例如如果资源层支持提前预约功能,则很容易在高层实现资源的协同调度服务,否则在高层实现这样的服务就会有较大的额外开销。
(2)连接层
连接层的基本功能就是实现相互的通信。它定义了核心的通信和认证协议,用于网格的网络事务处理。通信协议允许在构造层资源之间交换 数据,要求包括传输、路由、命名等功能。在实际中这些协议大部分是从TCP/IP协议栈中抽取出的。认证协议建立在通信服务之上,提供的功能包括:单一登 录、代理、与局部安全方法的集成、基于用户的信任机制。
(3)资源层
资源层的主要功能就是实现对单个资源的共享。资源层定义的协议包括安全初始化、监视、控制单个资源的共享操作、审计以及付费等。它忽略了全局状态和跨越分布资源集合的原子操作。
(4)汇聚层
汇聚层的主要功能是协调多种资源的共享。汇聚层协议与服务描述的是资源的共性,包括目录服务、协同分配和调度以及代理服务、监控和 诊断服务、数据复制服务、网格支持下的编程系统、负载管理系统与协同分配工作框架、软件发现服务、协作服务等。它们说明了不同资源集合之间是如何相互作用 的,但不涉及到资源的具体特征。
(5)应用层
应用层是在虚拟组织环境中存在的。应用可以根据任一层次上定义的服务来构造。每一层都定义了协议,以提供对相关服务的访问,这些服务包括资源管理、数据存取、资源发现等。在每一层,可以将API定义为与执行特定活动的服务交换协议信息的具体实现。
4 开放网格服务体系结构(Open Grid Services Architecture, OGSA)
OGSA包括两大关键技术,即网格技术和Web Service技术,它是在五层沙漏结构的基础上,结合Web Service技术提出来的,解决了两个重要问题——标准服务接口的定义和协议的识别。以服务为中心是OGSA的基本思想,在OGSA中一切都是服务。这 一结构的意义就在于它将网格从科学和工程计算为中心的学术研究领域,扩展到更广泛的以分布式系统服务集成为主要特征的社会经济活动领域。
4.1 OGSA的基本思想
OGSA最基本的思想就是以“服务”为中心。在OGSA框架中,将一切抽象为服务,包括各种计算资源、存储资源、网络、程序、数据库等等,简而言之,一切都是服务。这种观念,有利于通过统一的标准接口来管理和使用网格。
OGSA定义了网格服务(Grid Service)的概念,网格服务是一种Web Service,该服务提供了一组接口,这些接口的定义明确并且遵守特定的管理,解决服务发现、动态服务创建、生命周期管理、通知等问题。在OGSA中, 将一切都看作网格服务,因此网格就是可扩展的网格服务的集合。网格服务可以以不同的方式聚集起来满足虚拟组织的需要,虚拟组织自身也可以部分地根据他们操 作和共享的服务来定义。简单地说,网格服务=接口/行为+服务数据。图4是对网格服务的简单描述。
OGSA以服务为中心,具有如下好处:
网格中一切都是服务,通过提供一组相对统一的核心接口,所有的网格服务都基于这些接口实现,可以很容易地构造出具有层次结构的、更高级别的服务,这些服务可以跨越不同的抽象层次,以一种统一的方式来看待。
虚拟化也使得将多个逻辑资源实例映射到相同的物理资源上成为可能,在对服务进行组合时不必考虑具体的实现,可以以底层资源组成为基础,在虚拟组织中进行资源管理。通过网格服务的虚拟化,可以将通用的服务语义和行为,无缝地映射到本地平台的基础设施之上。
4.2 OGSA的两大支撑技术
网格技术(如Globus软件包)和Web Service是OGSA的两大支撑技术。
(1)Globus
Globus是已经被科学和工程计算领域广泛接受的网格技术解决方案。它是一种基于社团的、开放结构、开放源码的服务的集合,也是支持网格和网格应用的软件库。该工具包解决了安全、信息发现、资源管理、数据管理、通信、错误监测以及可移植等问题。
与OGSA关系密切的Globus组件是GRAM网格资源分配与管理协议和门卫(Gate Keeper)服务,它们提供了安全可靠的服务创建和管理功能,元目录服务通过软状态注册、数据模型以及局部注册来提供信息发现功能,GSI(Grid Security Infrastructure网格安全架构)支持单一登陆点、代理和信任映射。这些功能提供了面向服务结构的必要元素,但是比OGSA中的通用性要小。
(2)Web Service
Web Service是一种标准的存取网络应用的框架。XML协议相关的工作是Web Service的基础。Web Service中几个比较重要的协议标准是SOAP(Simple Object Access Protocol,简单对象访问协议)、WSDL(Web Service Description Language,Web服务描述语言)、WS-Inspection、UDDI(Universal Description, Discovery & Integration,统一的描述、发现与集成)。SOAP是基于XML的RPC(Remote Process Call,远程进程调用)协议,用于描述通用的WSDL目标。通过将SOAP进行扩展支持Web Service框架的安全性。WSDL用于描述服务,包括接口和访问的方法,复杂的服务可以由几个服务组成,它是Web Service的接口定义语言。WS-Inspection给出了一种定义服务描述的惯例,包括一种简单的XML语言和相关的管理,用于定位服务提供者公 布的服务。而UDDI则定义了Web Service的目录结构。
4.3 OGSA的服务接口
OGSA符合标准的Web Service框架。Web Service解决了发现和激活永久服务的问题,但是在网格中有大量的临时服务,因此OGSA对Web Service进行了扩展,提出了网格服务(Grid Service)的概念,使得它可以支持临时服务实例,并且能够动态创建和删除。
表1列出了网格服务的接口,其中只有GridService接口是必须的,而其他的接口都是可选的。每个接口定义了一些操作,这些 操作通过交换定义好的一系列消息来激活。网格服务接口和WSDL的portTypes相对应,网格服务提供portTypes的集合,包括一些与版本有关 的附加信息,在网格服务中用serviceType来描述,serviceType是OGSA定义的WSDL的扩展元素。
PortType | 操作 | 描述 |
---|---|---|
GridService | FindServiceData | 查询网格服务实例的各种信息,包括基本的内部信息、大量关于每个接口的信息以及与特定服务有关的信息。 |
SetTerminationTime | 设置并得到网格服务实例的终止时间。 | |
Destroy | 终止网格服务实例。 | |
NotificationSource | SubscribeToNotificationTopic | 根据感兴趣的消息类型和内容说明,相关事件的通知发送者进行登记。 |
UnSubscribeToNotificationTopic | 取消登记。 | |
NotificationSink | DeliverNotification | 异步发送消息。 |
Registry | RegisterService | 网格服务句柄的软状态注册。 |
UnRegisterService | 取消注册的网格服务句柄。 | |
Factory | CreateService | 创建新的网格服务实例。 |
PrimaryKey | FindByPrimaryKey | 返回根据特定键值创建的网格服务句柄。 |
DestroyByPrimaryKey | 撤销特定键值创建的网格服务实例。 | |
HandleMap | FindByHandle | 返回与网格服务句柄相联系的网格服务实例。 |
5 Web服务资源框架(Web Service Resource Framework,WSRF)
5.1 WSRF的提出
在OGSA刚提出不久,GGF及时推出了OGSI(Open Grid Services Infrastructure,开放网格服务基础架构)草案,并成立了OGSI工作组,负责该草案的进一步完善和规范化。OGSI是作为OGSA核心规范 提出的,其1.0版于2003年7月正式发布。OGSI规范通过扩展Web服务定义语言WSDL和XML Schema的使用,来解决具有状态属性的Web服务问题。它提出了网格服务的概念,并针对网格服务定义了一套标准化的接口,主要包括:服务实例的创建、 命名和生命期管理、服务状态数据的声明和查看、服务数据的异步通知、服务实例集合的表达和管理、以及一般的服务调用错误的处理等。
OGSI通过封装资源的状态,将具有状态的资源建模为Web服务,这种做法引起了“Web服务没有状态和实例”的争议,同时某些 Web服务的实现不能满足网格服务的动态创建和销毁的需求。OGSI单个规范中的内容太多,所有接口和操作都与服务数据有关,缺乏通用性,而且OGSI规 范没有对资源和服务进行区分。OGSI使用目前的Web服务和XML工具不能良好工作,因为它过多地采用了XML模式,比如xsd:any基本用法、属性 等,这可能带来移植性差的问题。另外,由于OGSI过分强调网格服务和Web服务的差别,导致了两者之间不能更好地融合在一起。上述原因促使了WSRF (Web Service Resource Framework,Web服务资源框架)的出现。
WSRF采用了与网格服务完全不同的定义:资源是有状态的,服务是无状态的。为了充分兼容现有的Web服务,WSRF使用WSDL 1.1定义OGSI中的各项能力,避免对扩展工具的要求,原有的网格服务已经演变成了Web服务和资源文档两部分。WSRF推出的目的在于,定义出一个通 用且开放的架构,利用Web服务对具有状态属性的资源进行存取,并包含描述状态属性的机制,另外也包含如何将机制延伸至Web服务中的方式。
5.2 WSRF的技术规范
WSRF是一个服务资源的框架,是五个技术规范的集合,表2总结了这些技术规范。这些规范定义了以下方法:
Web服务资源可以与销毁请求同步地或者通过提供基于时间的析构(destruct)机制来销毁,而且指定的资源特性可以被用来检查和检测Web服务资源的生存期;
Web服务资源的类型定义可以由Web服务的接口描述和XML资源特性文档来组成,并且可以通过Web服务消息交换来查询和更改Web服务资源的状态;
如果Web服务内部所包含的寻址或者策略信息变得无效或者过时,Web服务端点引用(Web服务寻址)可以被更新;
可以定义异构的通过引用方式结合在一起的Web服务集合,不管这些服务是否属于Web服务资源;
通过使用用于基本错误的XML Schema类型以及扩展这个基本错误类型的规则应用到Web服务中,使得Web服务中的错误报告可以更加标准化。
名称 | 描述 |
---|---|
WS-ResourceLifeTime | Web服务资源的析构机制。包括消息交换,它使请求者可以立即地或者通过使用基于时间调度的资源终止机制来销毁Web服务资源。 |
WS-ResourceProperties | Web服务资源的定义,以及用于检索、更改和删除Web服务资源特性的机制。 |
WS-RenewableReferences | 定义了WS-Addressing端点引用的常规装饰(a conventional decoration),该WS-Addressing端点引用带有策略信息,用于在端点变为无效的时候重新找回最新版本的端点引用。 |
WS-ServiceGroup | 连接异构的通过引用的Web服务集合的接口。 |
WS-BaseFaults | 当Web服务消息交换中返回错误的时候所使用的基本错误XML类型。 |
WSRF规范是针对OGSI规范的主要接口和操作而定义的,它保留了OGSI中规定的所有基本功能,只是改变了某些语法,并且使用了不同的术语进行表达。表3给出了OGSI各项功能和WSRF规范的映射关系。
OGSI | WSRF |
---|---|
Grid Service Reference | WS-Addressing Endpoint Reference |
Grid Service Handle | WS-Addressing Endpoint Reference |
HandleResolver portType | WS-RenewableReferences |
Service data defn & access | WS-ResourceProperties |
GridService lifetime mgmt | WS-ResourceLifeCycle |
Notification portTypes | WS-Notification |
Factory portType | Treated as a pattern |
ServiceGroup portTypes | WS-ServiceGroup |
Base fault type | WS-BaseFaults |
WSRF使Web服务体系结构发生了以下两点演变:提供了传输中立机制来定位Web服务;提供获取已发布服务的信息机制集,具体的信息包括WSDL描述、XML模式定义和使用这项服务的必要信息。
5.3 WSRF的优点及发展
和OGSA的最初核心规范OGSI相比,WSRF具有以下五个方面的优势:
(1)融入Web服务标准,同时更全面地扩展了现有的XML标准,在目前的开发环境下,使其实现更为简单。
(2)OGSI中的术语和结构让Web服务的标准组织感到困惑,因为OGSI错误地认为Web服务一定需要很多支撑的构建。WSRF通过对消息处理器和状态资源进行分离来消除上述隐患,明确了其目标是允许Web服务操作对状态资源进行管理和操纵。
(3)OGSI中的Factory接口提供了较少的可用功能,在WSRF中定义了更加通用的WS-Resource Factory模式。
(4)OGSI中的通知接口不支持通常事件系统中要求的和现存的面向消息的中间件所支持的各种功能,WSRF中规范弥补了上述的不足,从广义角度来理解通知机制,状态改变通知机制正是建立在常规的Web服务的需求之上。
(5)OGSI规范的规模非常庞大,使读者不能充分理解其内容,以及明确具体任务中所需的组件。在WSRF中通过将功能进行分离,使之简化并拓展了组合的伸缩性。
作为OGSA最新核心规范的WSRF,它的提出加速了网格和Web服务的融合,以及科研界和工业界的接轨。OGSA和WSRF目前 都处于不断的发展变化之中。2004年6月,OGSA 1.0版本发布,阐述了OGSA与Web服务标准的关系,同时给出了不同的OGSA应用实例。OGSA 2.0版本于2005年6月发布,WSRF 1.2也于2006年4月3日被批准为OASIS标准
对于WSRF本身而言,由于其提出不久,其规范还有待在实践中得到进一步应用证明,并逐步得到完善。基于OGSA和WSRF的服务网格平台和规范协议,将最终成为下一代互联网的基础设施,所有的应用都将在网格的基础平台上得以实施。
6 结束语
网格计算的架构决定于网格体系结构的设计,但不管采用何种体系结构,网格都必须具备资源管理、信息管理、数据管理、服务质量保证、安全等基本的功能模块。关于这些基本的功能模块,我们将在以后的文章中作进一步阐述,以使读者对网格有较为全面的理解。
参考资料
学习