服务网格标准规范体系，本文主要内容关键词为：网格论文,标准规范论文,体系论文，此文献不代表本站观点，内容供学术参考，文章仅供参考阅读下载。
【分类号】 G250.76
1 背景
网格(Grid)[1] 技术借鉴电力网格(Power Grid)概念。利用计算机网络，以松散耦合机制，把分布的各种资源(计算、存储、带宽、软件、数据、信息、知识)连成一个逻辑整体，按照一定的服务质量(Quality of Service)要求，支持动态、跨组织域的虚拟组织(Virtual Organization)实现协同的资源共享和问题求解。迄今为止，网格的发展经历了3个阶段：萌芽阶段开始于上个世纪90年代早期，侧重于千兆网试验床以及一些元计算方面的工作；早期试验阶段从90年代中期到晚期，出现了一些重要的开创性和奠基性研究项目，如I-WAY[2]、Globus[3]、Legion[4]等；目前是网格计算的迅速发展阶段，网格研究、开发和应用项目大量出现，全球网格论坛和企业网格联盟合并建立了开放网格论坛[5]，网格计算也从科学研究领域向更广泛的领域推广。
对于这些领域方面的问题，都有相应的技术及规范来解决相应的问题。标准化是解决网格系统的重要支撑。与网格相关的标准化组织包括：
(1)开放网格论坛(Open Grid Forum,OGF):http://www.ogf.org/
(2)结构化信息标准促进组织(Organization for the Advancement of Structured Information Standards,OASIS):http://www.oasis-open.org/
(3)万维网联盟(World Wide Web Consortium,W3C):http://www.w3c.org/
(4)分布式管理任务组(Distributed Management Task Force,DMTF):http://www.dmtf.org/
(5)Web服务互操作组织(Web Services Interoperability Organization,WS-I):http://www.ws-i.org/
在这些标准化组织、科研机构、商业组织的共同推动下，网格相关的技术、标准正逐步成熟。
2 Open Grid Services Architecture(OGSA[TM])的功能要求
OGSA是由功能性和非功能性的要求所驱动而定义的，这些要求源自使用案例[6，7]。这些案例涵盖了商业和科研领域的基础架构和应用场景。这些场景为架构定义的过程提供了有用的信息和大量相关的功能性或非功能性的要求：
(1)互操作性和支持动态异构的环境：OGSA必须提供对不同的分布异构的资源和服务的互操作性，以降低管理不同异构系统的复杂度，并支持资源虚化；通用的管理能力；提供资源发现和查询的机制；支持互操作的标准协议和大纲。
(2)跨组织的资源共享：全局命名空间、元数据服务、站点自治、资源使用数据是共享资源必须考虑和解决的问题。
(3)优化：有效分配资源的技术，需要对提供方和消费方的资源和服务同时进行优化。
(4)服务质量保证：服务级协定、服务级成就、迁移的要求都要求保证一定的服务质量。
(5)作业执行：作业执行也必须支持管理、调度、预备、作业控制和异常处理。
(6)数据服务：策略规范和管理、数据存储、访问、传输、位置管理、更新、持久性、联合等功能需求在网格应用中非常需要。文献[8]提供了以数据库为中心的视角，展示数据服务如何成为全面的网格服务方案。
(7)安全：认证与授权、多个安全基础架构、边界安全方案、隔离、委托、入侵检测，保护及安全日志是保证网格系统正常运行不可或缺的功能要求。
(8)缩减管理成本：基于策略的管理、应用层内容管理、问题确定等自动化的管理任务支持，能够缩减管理成本和人工失误的风险。
(9)可伸缩性：需要扩展到成千上万、各式各样的资源上的管理架构和支持高吞吐的运算。
(10)可用性：网格的异构性和或长或短的无故障运行时间要求基于策略的自动控制、动态预备、灾难恢复、错误管理功能来提供稳定的、高度可靠的执行环境。
(11)易用及扩展性：无论策略还是机制都应当是可扩展和可替换的，以此来允许OGSA不断进化并允许用户构建适合他们自己需要的机制和策略。此外，核心系统组件本身也应当是可扩展和可替换的，这些扩展和定制不应当影响到系统的互操作性。
OGSA的目标是推动对分布、异构资源的无缝管理及使用。对这样的基础架构的使用被描述成一套能力。图1展示了逻辑的、抽象的、半分层的部分能力的表示。在这个表示中将逻辑的、抽象的能力分为了3层。
图1 开放网格架构分层视图[9]
图1中的第一层(底层)代表了基础资源。最好的资源是被物理的、逻辑的实体或人造物品在底层所支持的资源，同时在OGSA的情景外具有相关性的资源。物理实体包括CPU、内存、磁盘；逻辑实体包括授权、内容、操作系统的进程。虚化是和实体紧紧联系在一起的，因此，虚化的名字也使用底层的实体或者人造物品的名字。这些资源通常都是本地拥有和管理的，但可能被远程共享。配置和定制也在本地完成。由于实际的实体和人造物品可能来自多个源头，其特征也经常变动，这项资源的特征，如服务质量、版本、可用性等也会经常变动。
第二层(中间层)代表更高一层的虚化和逻辑抽象。虚化和抽象直接引出了OGSA网格中所广泛定义的能力。这些能力能够被单独地使用，或者通过组合提供基础架构以支持更上层的应用或者“用户态”的域进程。OGSA定义的这套能力是相对不变和标准的。这些能力被实现为可扩展和可组合的，以便于用户域应用在系统级决定基础架构的服务质量。
OGSA面向服务的本质意味着虚化的资源实际上代表的是架构中的服务及其他对等服务(例如中间层的服务和上层的服务)。服务的对等关系意味着架构中的任何服务都可以向其他服务发起交互的请求。此外，第二层的服务需要使用和管理由底层所支持的虚化(资源)，从而提供对个体服务(服务集合或者服务组合)的能力支持。从图1中可以看到底层和中间层之间的紧密关系。因此，底层的实体也被OGSA作为相关的部分进行探讨。
逻辑表示中的第三层(顶层)代表了应用和其他实体，运行面向用户和域的功能和进程。它们大部分在OGSA的范围之外，但是可以通过对基础架构的需求和案例来驱动对架构的定义。
所有的层互相协同工作从而达到整个系统预期的服务质量(或者满足应用层用户场景所需服务的质量要求)，提升用户体验，因此被称为“宏服务质量”。
3 OGSA标准规范及其体系
3.1 OGSA框架
OGSA将图1中间层定义为服务，这些服务的接口、状态都属于服务所有，服务之间的交互通过面向服务的架构来进行。
一个系统中并不需要全套的OGSA能力都存在。换句话说，可以使用OGSA定义的能力的子集来完成系统的构建。能力本身也不是单块的，系统可以使用或者提供任何能力的服务子集。
OGSA代表的是服务、它们的接口以及这些服务的交互行为及语义。这些服务的内部实现的软件架构则不是OGSA讨论的范围。
架构本身不是分层的，某个服务的实现及交互则只能在它逻辑上所依赖的层来决定。虽然很多概念看起来是面向对象的，但是它们并不是面向对象的。
服务是松耦合的对等节点，无论单个还是一个交互组的服务，它们的实现、组合、与其他服务的交互都贯彻着OGSA的能力概念。例如，为了实现“编排”能力，一组服务中的一部分也许被构建为驱动编排的服务(编排者)，而另一些服务提供了被“编排”的接口和机制(被编排者)。为了实现不同的能力，一个特定的服务可能实现或者参与到多个集合或者交互当中。另一方面，实现一个特定的能力不需要所有的服务都参与其中。
服务可能参与到虚拟域的虚拟集合当中以实现能力，在服务组当中共享集体的情景或者管理框架。应当存在一套核心的非空的接口，标准和达成共识的引导服务，作为OGSA网格的必备实现。这套支持OGSA的公有的实现和呈现被称为基础架构服务(Infrastructure Service)或者网格建筑(Grid Fabric)。
3.2 主要网格标准
开放网格服务架构(Open Grid Services Architecture,OGSA)是开放网格论坛公布的网格计算的开放标准。标准提供了一个开放的框架来指导分布系统的集成、虚化及相应的管理。框架需要定义一套核心的接口、行为、资源模型及绑定。OGSA定义了对网格的核心能力的要求和通用的参考架构。规范虽然没有定义编程级别的接口或者保证实现的互操作性，但它定义了对于特定应用环境应当包括的基本功能。
围绕OGSA还有相应的流程、规范、应用纲要以及相应实现的软件[10]。除了定义整个框架的架构以外，相应的应用案例、服务描述文档、场景文档、指南及路线图展示了OGSA工作组对于OGSA从架构到实现的考虑(见图2)。应用案例、路线图和架构构成了基础的文档。场景和服务描述驱动了下一步完整性的定义，由信息文档、推荐标准和指南(纲要定义和模型指南)共同约束生成最终的应用纲要，并由这些应用纲要来具体限定实际上采用的规范和信息模型。
图2 OGSA工作组文档结构[11]
从图2中可以看到，OGSA的文档主要分为四大类：信息类文档、正式文档、推荐纲要和信息类纲要。
信息类文档主要包括使用案例、架构文档、服务描述文档、场景文档和指南文档。这些文档在OGF开放网格论坛的标识为GFD-I。下面对部分相对重要的文档作一简单介绍。
OGSA架构文档(版本1.5)[12]，该文档提供了高层的OGSA定义，并专注于需求和相应的能力要求，以便网格系统及其应用程序能够同时支持e-Science和电子商务。架构中描述的能力包括执行管理、数据、资源管理、安全、自我管理以及信息。OGSA工作组同时定义了OGSA词表，以提供各个文档中涉及的概念及定义的解释。
OGSA ByteIO应用案例[13]：能够明确地说明OGSA ByteIO接口的要求。案例可能包括读写二进制文件、读特定DAIS(Database Access and Integration Services)[14] 查询的结果、读传感器数据以及其他场景。期望现存的API(如POSIX API)应当能够被很容易地映射到ByteIO的Web服务接口上。
分布式系统的命名问题[15]：传统的分布式系统通常具有三层命名机制，人名、路径被映射为抽象名字，随后被映射到一定的地址形式上。参照了WS-Addressing、DNS、SGNP(Secure Grid Naming Protocol)、WSRF和JXTA[16] 等，但文档本身只是信息性质的，不依赖于具体的其他规范。
与OGSA相关的正式的规范，作为OGF论坛的候选推荐标准发布。这些文档相对而言已经经过比较成熟的讨论和应用。
OGSA ByteIO接口文档(OGSA ByteIO Interface Document Version 1.0)：OGSA多个工作组对于从多个源读写序列化的字节都有共同的要求，这个接口文档定义了完成这项功能最小的Web服务接口。接口应当适用整个架构。ByteIO接口应当基于OGSA WSRF基本纲要。
数据移动功能规范(Data Movement Functional Specification)：文档定义了操作、输入、输出以及能够提供数据移动服务的底层语义。目前，这些定义通过抽象的描述表达，并没有通过实际的代码、XML、WSDL等表达。作为OGSA及OGSA-Data架构的组成部分，数据移动功能规范将直接或者间接被这些架构所引用。规范由OGSA-DMI-WG工作组负责①，预计于2008年发布。
数据移动传输协议及其在DMI中的使用(Data Movement Transport Protocols and Their Use in DMI)：数据移动服务是和传输协议无关的。但是，为了考虑效率，必须协商一个可接收的协议来提供可扩展的、标准化的数据传输。文档主要描述协商是如何进行的，扩展如何达成，并且列出了一组可供初始化的协议和接口。规范由OGSA-DMI-WG工作组负责，预计于2008年发布。
OGSA推荐纲要由相关的工作组制定。其制定流程参照OGSA纲要定义文档[17]。这些文档在OGF文档中首先作为提议推荐(GFD-R.P)发布。底层相关的Web服务规范没有纳入这些规范的总结当中。
OGSA WSRF基础纲要(OGSA WSRF Basic Profile Version 1.0)[18]：在对有状态的实体进行模型、管理时，或者网格计算、分布式资源管理的服务实现时，需要纲要进行指导和限定。这些服务受益于WS-Addressing、WS-Resource Framework、WS-Notification家族规范定义的接口和行为。OGSA工作组已经发布了纲要的1.0的正式版本(其文档自编号为GFD.72)。纲要基于WS-I Basic Profile 1.1、WS-Addressing、WS-ResourceProperties、WS-ResourceLifetime、WS-BaseNotification和WS-BaseFaults。OGSA WSRF基础纲要是OGSA工作组制定的大量纲要和规范的基础，包括ByteIO、ACS及BES等。
信息类纲要的开发进度没有计划。信息类纲要主要说明和其他组织的合作。为了保证有效的生产率与其他标准组织的良好沟通，OGF及其工作组与其他标准化组织或者工业组织保持着良好的联系和沟通。
与标准开发组织在网络资源管理方面的合作(Standards Development Organizations Collaboration on Networked Resources Management,SCRM)：除了在工作组级一对一的联系之外，OGSA也和标准开发组织(Standards Development organizations,SDO[，s])在机构级进行合作，创建相应的基于Web服务的网络资源管理技术和规范。这些SDO[，s]组织包括但不限于DMTF、IETF、ITU-T、OASIS、OGF、SNIA、TMF和W3C。这项活动称为与标准开发组织在网络资源管理方面的合作(Standards Development Organizations Collaboration on Networked Resources Management,SCRM)。SCRM-WG工作组发布了网络资源管理的规范和标准的在线指南。以Wiki的方式进行合作开发②，信息被全世界顶级专家不断更新，SCRM-WG工作组仅仅维护Wiki本身信息的完整性和合理性。
OGSA架构中各个规范的相互关系如图3所示。
图3 OGSA架构规范之间的关系[20]
Web服务资源框架(Web Services Resource Framework,WSRF)是在保持OGSI概念和功能的前提下，对OGSI V1.0规范中的概念和接口的直接重构和发展，定义出通用开放的架构，利用Web服务对具有状态属性的资源进行存取，并包含描述状态的机制，也包含如何将机制延伸到Web服务中的方式。WSRF将网格服务完全融入Web服务标准，通过对消息处理器和状态资源的分离来明确Web服务操作对状态资源的管理和操纵。WSRF[19] 定义了一套规范来描述Web服务(通常是没有状态的)和有状态的资源之间的关系。
Web服务相关标准：网格服务与Web服务之间的关系如此之紧密，与Web服务相关的大量标准同样适用于网格服务。XML、WSDL、SOAP、UDDI等最基本的Web服务标准必然被网格服务所应用。此外，WS-I的许多相关的互操作规范也和网格服务的规范相关。网格服务借助这些与平台无关的Web服务标准来完成服务的描述、查找、访问和信息传输功能。用户不再需要担心和考虑底层的服务是由.NET还是CORBA提供的。
4 标准规范典型应用范例
多个开源软件项目和商业软件厂商都根据OGSA及其相关规范开发了顺应OGSA规范的网格解决方案。
网格技术最著名的代表是美国Argonne国家实验室研发的Globus项目，共有12所大学和研究机构参与，研究资源管理、安全、信息服务及数据管理等网格计算的关键理论，开发能在各种平台上运行的网格计算工具软件(Toolkit)，帮助规划和组建大型的网格试验平台，开发适合大型网格系统运行的大型应用程序。Globus Toolkit[21，22] 是其最重要的成果，最新稳定版本4.0版在2004年3月推出，作为开放源码软件发布。目前，Globus的技术已经在NASA网格(NASA IPG)[23]、欧洲数据网格(Data Grid)[24] 等项目中得到应用。
Globus项目是国际上最有影响力的与网格计算相关的项目之一，作为网格开源实现的领头羊，Globus Tookit基于开放结构、开放服务资源和软件库，并支持网格和网格应用，为构建网格应用提供中间件服务和程序库。Globus Alliance[25] 通过开源软件实施的过程对OGSA规范的发展提供了设计和实现上的支持。目前的版本GT4基于之前的WSRF和WS-Notification的实现，并实现了部分相关的安全标准。Globus工具包为开发丰富的网格应用提供了良好的应用网格中间件支持。
Globus联盟由一群具有对于标准的制定，尤其是OGSA标准的制定有着非常浓厚兴趣的公司组成，它们通过对Globus工具包的开发修改将其投入商业应用。
弗吉尼亚大学网格研究组[26] 致力于实现ByteIO、BES、RNS和WS-Naming规范的开源版本。
商业网格计算项目[27] 也基于OGSA架构规范。尤其专注于规范中描述的应用内容服务、JSDL和WS-Agreement的开源实现。商业网格计算项目倾向于使用OGSA WSRF基本纲要1.0版本。
NextGrid[28] 是欧洲下一代网格架构开发的研究项目。项目使用OGSA WSRF基本纲要以及其他的OGSA应用案例作为其架构实现的基础。项目从战略和内容的角度对OGSA架构的开发和应用提出建议。
日本的国家研究网格计划(National Research Grid Initiative,NAREGI)[29] 是日本e-Science网格项目组织，为科学工程研究开发计算基础架构。NAREGI项目的主要目的是为GGF的标准化活动提供支持。NAREGI参与到了多个GGF的工作组和研究组的工作中。作为第一个实现EMS架构规范的组织，NAREGI实现了基础执行服务、资源选择服务和应用内容服务，并于2007年2月23日发布了Naregi网格中间件的Beta版本。
开放中间件基础架构(The Open Middleware Infrastructure Institute,OMII)[30] 是英国e-Science项目的核心组织之一，位于南新普顿大学。其开源分发实现了OGSA-DAI项目的DAIS，GridSAM项目的JSDL和BES。
UniGrids项目[31] 开发顺应OGSA标准的网格服务基础架构。软件基于WSRF和UNICORE网格软件。项目的主要目的是通过开发的实践来影响标准的制定。UNICORE的第一个版本实现了WSRF、WS-Addressing和JSDL。第二版实现了BES并支持WS-Security、SAML授权以及WS-Notification。
Gridbus项目[32] 主要开发面向服务的网格计算工具。项目设计并实现了开源版本的网格服务掮客(Grid Service Broker,GSB)，使用兼容WSRF的技术开发高级网格服务；网格工作流管理系统遵循JSDL、Portlet及WS-BPEL规范；GridBank(网格认证、授权、记帐服务)遵循资源使用记录(Resource Usage Record,RUR)；一个基于SLA的网格资源分配模块和基于.NET的企业级网格管理器。这些技术都遵循GGF的标准或者兼容标准所定义接口。
Globus Tookit具有较为统一的国际标准，有利于整合现有资源，也易于维护和升级换代。现在，一些重要的公司，包括IBM和微软等都公开宣布支持Globus Toolkit。目前大多数网格项目都是采用基于Globus Tookit所提供的协议及服务建设的。
5 推广应用分析与建议
网格应用正处在蓬勃发展的上升时期，相应的标准化工作正在商议制定的过程中。虽然现在已有大量投入实际使用的网格系统，但很多相关的标准还需要在实践中制定。
对整个分布式网格架构模型最有影响力的变化是近年来Web服务已经成为网络上方法调用和数据交换的事实基础。网格服务使用HTTP协议之上的XML来交换消息并构建于被广知的Web服务标准之上。不断涌现的Web服务标准③ 覆盖了包括消息内容、传输、安全、事务、元数据和工作流等多个功能领域。单个独立发展的Web服务规范可能会导致互操作的问题，因此，WS-I发布了基本纲要和基本安全纲要(Basic Profile and the Basic Security Profile,BSP)。而OASIS发布的Web服务资源传输框架(WS-Resource Transfer Framework,WSRF)添加了能够被远程访问和监控的Web服务状态。
OGSA基于非私有化组织(OGF)定义的标准以保证网格系统的互操作性及跨界资源共享。OGSA将这些Web服务的标准规范绑定到一起并通过分类和由DMTF定义的通用信息模型(Common Information Model,CIM)理论描述了一个分布式的网格系统。OGSA将这些标准和具体的应用纲要联系在一起，并定义出一个标准化的支持互操作的网格系统。OGSA必须紧紧跟随Web服务的变化并不时评估它们的变化对于OGSA架构和整个网格社区的影响。
注释：
①OGSA Data Movement Interface WG,https://forge.gridforum.org/sf/ projects/ogsa-dmi-wg
②http://forge.ggf.org/sf/wiki/do/viewPage/projects.scrm-wg/wiki/HomePage
③http://roadmap.cbdiforum.com/reports/protocols/