Anatomy of the Grid翻译（3）

6 “在网格上”： 网格系统间协议的需要 
    我们的网格体系确定了对协议和API的需要，使资源，服务，代码的共享成为可能。另外的它不限定用来实现这些协议和API的技术。事实上，要定义关键的网格体系组件的多个实例是很可行的。例如，我们能够在连接层建立基于Kerberos和PKI的协议，能够经过同样的API 访问这些安全机制，具体在GSS-API(见附录)。然而，网格的构建用这些不同协议并不能协作也不能共享基本的服务，至少没有网关是不可能的。由于这个原因，网格计算长期的工作要求我们在连接层和资源层选择和实现一个核心协议的广泛的展开。集体层在较小的 程度上也是如此。这很像Internet的核心协议，使得能够在不同的电脑网络之间交换信息。这些网格内部的协议(姑且这样称呼)使得不同的组织能够操作和共享资源。采用这些协议的资源可以说是“在网格上”。 如果网格的代码被共享的话，标准API 也是很有用的。这些基本协议和API的认证超出了本文的范围，尽管Globus工具包有一些成功的尝试。

7 和其它技术的联系 

    这个受限制的动态共享的概念在虚拟组织中是如此的基础，我们可以假定类似网格的技术肯定会得到广泛的发展。实际上，无论如何，当这个技术普遍需要时，在许多宽广的不同领域里我们发现解决虚拟组织问题的措施简单且不够充分。简而言之，当前分布式计算并不提供虚拟组织需要的一个普遍的资源共享框架。网格技术和它们自身的区别在于提供了通用的资源共享方案。这种形势指出了网格技术的众多的应用机会。 

7.1 万维网 
    普遍存在的Web技术（例如IETF和W3C基础协议：TCO/IP,HTTP,SOAPD等和类似HTML和XML语言）很有吸引力，其为构造虚拟组织和应用的平台。然而，这些技术能够出色的支持浏览器-用户-网-服务器交互模式，这是今天的WEB的基础，但是他们缺乏满足在虚拟组织中更复杂的互动所需要的特性。例如，现在的网络浏览器代表性的使用TLS体系，但是不支持单一签证或授权技术。
    结合网格和网络技术结合的步骤很清楚。例如，单一签证技术扩展了GSI到TLS的功能，如果集成到浏览器的话，允许对多网络服务器的单一签证。GSI授予客户服务器代理的功能。这些功能，简而言之，用网络技术来建立“虚拟组织入口”更容易，其对复杂的虚拟组织应用提供一个瘦客接口。 网络操作系统引起了一些讨论。

7.2 应用和存储服务提供商 
    应用服务提供商，存储服务提供商和类似的公司都对特殊的商业和工程应用开放了资源(在ASP的例子中)和存储能力(在SSP的例子中)。 一个消费者得到一个服务等级的协议许可能使用特定硬件和软件的集合。使用虚拟专用网技术处理安全问题用ASP或SSP所给予用户的资源来扩充使用者的内部网络，其它的SSP利用用户的Id和密码，存取控制列表，通过HTTP，FTP，WebDAV 提供文件共享服务。 
    从虚拟组织来看，这些都是低层次技术。虚拟专用网和静态配置使得许多虚拟组织的共享形式都很难实现。例如，虚拟专用网的使用意味着在一般的情况下，一个ASP要想存取位于一个独立的SSP上的数据。类似的，在一个单独的ASP或SSP中进行动态的资源配置也是挑战性的，事实上，几乎没有在提供商之间尝试共享负载，这在电力行业是一件很平常的事情，但在提供商之间几乎没有听说过。一个基本的问题是一个虚拟专用网不是一个虚拟组织:它不能动态的扩展以覆盖其它的资源，也不能对远程的资源提供商提供何时和怎样共享资源的任何控制。
    融合了网格技术的ASP和SSP领域，能够实现更多的服务。例如，标准化的网格服务和协议能够降低对硬件和软件的要求。一个消费者能够利用一个SLA以获得特定的硬件资源，然后利用网格资源协议来动态的提供消费者所需的特定服务。 灵活的授权和访问控制，将使一个消费者 能够让在ASP上运行的程序直接高效安全的把数据存放在一个SSP 上，求解更加复杂的问题时，结合自己和多个ASP和SSP的资源。实际上要求一个单一认证的安全底层机制能够跨越多个安全域， 网格资源 管理和统计/支付协议将支持动态供应和预约的可能性 (例如，存储统计，传输带宽)。

7.3 企业计算系统 
    企业发展技术例如CORBA，EJB， J2EE和DCOM系统被设计用来构造分布式的应用。它们提供了标准的资源接口，远程唤醒机制和发现服务，因此使在一个单独组织内部共享资源非常的容易。然而，这些机制并不涉及上面所列举的建立特别的虚拟组织的需要。共享安排是基于静态的并限制在一个单独组织内部使用。基本的交互形式是客户机－服务器，而不是对等使用多种资源。 
    这些结论支持网格技术应该在企业计算中占有一席之地。例如，在CORBA的例子中，我们将建立一个对象代理请求，用GSI 机制来解决跨组织的安全问题。我们能够采用网格资源协实现容易的对象转换以访问在一个虚拟组织内的资源。我们能够建立网格命名和交易服务，用网格信息服务协议在大的虚拟组织间查询信息资源。在每一个例子里，网格协议的使用功能增强了(例如，跨领域的安全)并且使得和其它客户（无CORBA）的协同工作成为可能。类似的结论也能由java和jini得出。例如，jini的协议和实现由个小的策略集合联系起来。一个“网格jini”被网格协议和服务使用，并允许jini在一个大范围多企业环境下使用。

7.4 INTERNET和对等计算
    对等计算（例如已实现的Napster、Gnutella和Freenet文件共享系统）和Internet计算(例如已实现SETI@home、Parabon和Entropia等项目)是我们在虚拟的特性中涉及的共享模式和计算结构的更普通的例子（超出了客户端－服务器模式）。同样的，它们和网格技术也有许多相同之处。
    实际上，我们发现这项技术的焦点在和时间不相关的领域。一个原因是对等和网络计算的焦点都在垂直的综合的解决方案，而不是寻求定义一种通用的协议使得允许共享底层结构和提高互用性。（这是因为，显然一个新的普遍市场的特征是参与者希望获得垄断。）另一方面不同的应用所需要的共享形式非常有限，例如，文件共享没有访问控制，计算共享要有一个核心服务器。
    当这些应用变得越来越复杂并对互用性的要求越来越清晰的时，我们将看到对等计算、 互联网和网格计算将会有一个强有力的交互点。例如，当计算和数据共享必须互操作并且管理存储个体资源的策略必须更加合成时，单一签证、认证和授权技术将会变得更加重要。

8 网格在其它方面的前景 

    网格和虚拟组织的前景显然不是在这篇文章中可以决定的。我们在这里总结并且批评一些其它的看法（用斜体字给出）。 
网格是第二代的Internet。网格并不是Internet的替代品：它不如说是基于创造与使用计算和数据的环境要求的Internet协议和服务上建立起来的一组附加的协议和服务。任何资源 如果在“在网格上”也可以按定义来说，是“在网上”。 
    网格计算是免费的计算资源。网格计算并非无限制的访问资源。网格计算是可控制的共享。资源所有者希望根据组织成员的支付能力来执行限制访问的政策等等。因此，记帐是非常重要的，并且一个网格体系必须结合资源和集合层的协议以交换使用和费用信息，同时在决定是否开放共享资源时调用这些信息。
    网格需要一个分布式操作系统。在这个观点中，网格软件需要定义操作系统服务建立在多人系统，这些服务提供者为一个单独的电脑提供一个操作系统网格：也就是位置、命名和安全等的透明相关。在另一方面，这些对网格软件的前景是定义成一个虚拟机。然而，我们的主要目标在发展的广阔和互用性，这是个矛盾的目标。我们讨论这个适当的模型比Internet协议更合适，它提供一个主要的垂直服务从事关心网络环境。这个巨大的物理和管理不同遭遇在网格环境中表示难获得期望的要求；另一方面，它能够获得一致同意在基础协议。这个被提议的体系是开放的：它被定义在一个紧凑和尽可能小的协议集中，一个协议必须显示“在网格中”；除此之外，它只提供一个结构被要求的框架。
    网格需要新的程序模型。在网格环境中的程序的挑战并不体现在串行（或并行）电脑，例如多管理域、新的失效模型和在性能上的巨大变化。然而，我们讨论这些附带的，非核心的问题和最基本的不同不是基础程序问题。例如，一个开发者相信一个通用的分布式共享存储模型能简化网格应用层的发展，并能执行网格协议的模型方面，拓展或延伸这个协议只是在这个目的还不明确。同样的，一个开发者相信所有的网格资源将提供给使用者作为执行面向对面分析的“API”在网格协议中。
    网格使高性能电脑资源浪费。成百上千甚至数百万的处理器它们可以在虚拟组织中表现出重要的计算能力，如果我们能将它们用在合适的地方。然而，这并不意味着高性能电脑将过时。许多问题需要紧紧联系起来的高通信带宽的电脑；网格计算将很好的增长，而不是降低，这些系统需要更好的访问。

9 摘要 
    我们在这篇文章中对“网格问题“作了简明的陈述，把网格问题定义为控制和整理共享资源并在动态的可扩充的虚拟组织中使用。我们也提出了网格体系的需求和框架，确定了在虚拟组织间实现共享所需的主要功能，定义了这些功能之间关键的联系。最后，我们在一些细节上讨论了网格技术和其它重要的技术有什么样的联系。
    我们希望在这篇文章中介绍的词汇和结构能够被逐渐发展的网格学科证明是有用的，能够增加我们对问题的了解和提供通用的用来描述问题的语言。我们也希望我们的分析能够帮助建立网格开发者和相关技术的开发者之间联系。 
    这篇论文也提出了一些重要的问题。网格内协议需要选择一些什么协议以使得实现网格系统间的互用性？一个稳定的版本中应当实现一些什么样的服务以创建网格（而不是每个具体的应用都要重新实现）？必须提供给用户什么样的API和SDK以加速开发和对网格应用的扩充？对这些问题我们有自己的看法，但这些答案还有待于未来的研究。

附录：定义 

    我们定义了四个术语，它们在这篇文章中非常基本但是常常被误解和滥用的，即协议、服务、SDK和API。 
    协议。一个协议是远程通讯系统中末端节点在交换信息时所使用的一组规则。例如：
    IP定义了一个不可靠的包传输协议；
    建立在IP协议之上的TCP协议定义了一个可靠的数据传输协议； 
    TLSP定义在两个需要通讯的应用间，提供保密的和保证数据完整性的协议，它位于一个可靠的传输协议例如TCP协议之上。
    LDAP建立在TCP协议之上，定义了查询远程数据库状态的查询－响应协议。 
    协议的一个重要的性质是可供多个实现使用：两个端点只需实现相同的协议就能够通信。因此，在分布式计算环境中，标准的协议是达到互操作性的根本。
    一个协议的声明很少涉及使用协议的实体的行为。例如， FTP协议的声明指出了用来传输文件的报文格式，但并没有说清楚接收的实体应当怎样管理这些文件。
    像上面的例子一样，某个协议也许会基于其它协议定义。 

    服务：一个服务是通过网络能提供专门能力的实体。例如，移动文件，创造进程或者是校验访问权限的能力。一个服务由与之交互所使用的协议和响应不同的协议消息交换所期望的行为所定义（例如：服务＝协议＋行为）。 一个服务也许允许各种的实现。例如：
    一个FTP服务器使用FTP协议，支持远程对文件集进行的读写。一个FTP服务器的实现 也许只是简单的在服务器本地硬盘上读出和写入，另一个也许会从一个巨大的压缩存储系统中读出和写入，在运行中自动的压缩和解压缩文件。从基础结构级的角度来看，这两个服务器响应同一个存储请求的行为是非常不同的。但是在要求服务的客户看来，这些行为是不可分辨的；储存一个文件然后重新检索它将会产生同样的结果，不管实际采取的是那一种实现。
    一个LDAP 服务采用LDAP协议，支持对查询的响应。一个LDAP服务器实现也许使用一个信息数据库来响应查询，另一个也许通过动态地形成简单网络管理协议（SNMP）调用得到必须的信息以响应查询。
    一个服务可以是，但也可以不是持久的，能够监测一定的错误和从错误中恢复，以特权运行，或有一个分布式的实现。如果允许不同的变体，需要客户自己定制服务属性的探索机制是非常重要的。
    还要注意一个用户可以使用同一协议的不同的服务。例如，在Globus工具包中，复制和信息服务都使用LDAP协议。
    API: 一个应用程序编程接口定义了一个标准界面为调用一个指定的功能函数（例如，子程序调用或面向对象的API）。
    常规安全服务（GSS）API定义标准函数为鉴别不同的通信伙伴、信息译码等。
    信息传递界面API在不同语言中定义了标准界面，这个函数用来在并行计算系统中通过进程传递。 
    一个API可以定义多语言联编或使用一种接口定义语言。这种语言可以是传统的编程语言，如c或java；也可以是外壳语言。此时API将参照命令行自变量的具体定义，程序的输入输出以及程序的出口状态。一个API通常规定了一个标准的行为，同一个API可以允许多个实现的存在。 
    理解API与协议之间的关系是重要的，一个协议并不规定可在程序里面调用以便产生协议消息的API的任何事情。一个单独的API可以有多个实现存在。例如，如果在各种异构的平台上支持相同的API，并以此API作为不同的存储系统的接口，程序员的任务将大大简化。 
    例如，public key和Kerberos已被定义于GSS-API（GSS代表一般的安全性服务），因此使用GSS－API调用认可操作的程序，可以或者在Public Key中操作，或者在kerberos环境中操作而不需要改变。另一方面，如果我们希望一个程序同时能在Public Key和kerberos环境中操作的话，这需要支持此二环境的互操作性的标准协议。

    图5：左边，一个API被用于开发能将Kerberos或PKI安全性机制作为目标的应用。右边，GSP（由Globus提供的网格安全性协议）协议被用于使得Kerberos和PKI域之间能够互操作。
    SDK：这个概念标记一组打算与应用程序链接在一起，并从应用程序中调用以提供规定的功能的代码集。一个SDK典型的实现为一个API。如果一个API准许为多种实现所用，则对此API将会有多个SDK。某些SDK经过特别的协议提供对服务的访问。例如： 
    OpenLDAP版本包括了一个LDAP客户端的SDK，该SDK包括能由， c/c++应用使用的执行查询LDAP服务的函数库。
    JNDI是一个java SDK，它包含能用于执行查询一个LDAP服务的函数。
    不同的SDK执行GSS-API使用TLS和Kerberos协议。他们可能是多个SDK，例如为多卖家提供一个特殊的协议。更进一步的，为C-S面向协议，能为想访问服务器的应用程序区分客户端SDK，以及想接受特殊服务的服务器SDK的定制服务。
    一个SDK不需要采用任何协议。 例如，提供了数字的功能的SDK可以完全本地化的行动而不需要执行该操作的任何服务。