3 网格体系的本质
动态的、跨组织的虚拟组织共享关系的建立，管理和开采需要新的技术。我们以标识基本的系统组件的网格构架来组织我们对这个技术的讨论，说明这些组件的目的和功能，以及指出这些组件如何和其它的进行交互。
在定义一个网格构架中，我们从那些影响虚拟组织需要我们能够在任何潜在的参与者中建立共享关系的操作的景象开始。互用性因此成为中心问题被确定下来。在网络环境中，互用性意味着通用的协议。因此，我们的网格构架首先是一个协议构架，这些协议定义了基本的，使用者和资源协商，建立，管理和开采共享关系的机制。一个基于标准的、开放的构架会使得可跨展性，互用性，可移植性和代码共享变得容易；标准的协议可以使定义提供增强能力的、标准的服务容易。我们也可以构造应用程序接口和软件开发工具（参阅附录的定义）来提供需要用于创建一个可用的网格的编程抽象。合起来讲，这个技术和构架组成了通常术语化了的中间件（在一个分布式的网络中支持一系列应用的服务），虽然我们在这里因为它的含糊避免使用这个术语。我们将在后面讨论每一点。
为什么互操作性占有如此重要的位置？我们需要在任意不同的单位之间建立共享关系，动态的调和新参与者，通过不同的平台、语言和编程环境。在此状态下，如果他们没被定义和实现，就实现不了跨组织边界、执行策略、资源类型的互操作，这些机制也就不起作用。没有互操作性，在参与和应用虚拟组织时就必须进行双边的共享分配，此时不能保证双边使用的机制能扩展到其他的地方去。没有这样的保证，动态虚拟组织几乎是不可能实现的，而虚拟组织能够存在的类型也极为有限。就像WEB通过提供通用语法和协议（HTTP和HTML）使信息共享产生了革命，因此我们在资源共享方面也需要标准的语法和协议。
为什么评估协议的互动性？一个协议不仅定义特定了分布式系统元件之间进行的交互的目的和功能的实现，也包括这些交互之间的信息交换。这样对外部（交互）的关注比对内部（软件、资源特性）的关注更有实际价值。虚拟组织是明不稳定的：它的机制在发现资源、建立身份、进行授权和开始共享时必须是可扩展的和轻量级的，只有这样资源共享的分配才可能快速的建立和修改。因为虚拟组织是补充而不是对现有机构和共享机制的替换，它不能要求本地策略因此而进行底层的改变，同时要让单个机构能够继续对自己资源进行终端控制。因为协议管理了组件之间的交互而不是它们的执行。本地协议是被保留的。
为什么服务重要？一个服务（见附录）通过一种协议来表达和工作。标准服务的定义：对于有权使用计算、有权获得数据、资源发现、同步安排、数据复制等等，让我们能增进对虚拟组织的参与者提供的服务，对于那些可能妨碍虚拟组织应用发展的抽象的特定资源细节亦如此。
为什么我们也关注API和SDK？当然，这是因为与互操作性、协议、服务的相比，开发者必须能在动态的执行环境中开发出的复杂的系统。用户要能操作这些应用程序。应用程序的健全性，正确性，开发成本和维护成本都是要考虑的重要因素。标准概念，API和SDK能加速代码开发，能够便于代码共享，并增强程序的可移植性。API和SDK是协议的附加而不是替代的。没有标准协议的话，若要达到API层面的互操作，在到处就只能用相同的执行方式――在许多有意思的虚拟组织中是不可行的――或者每种执行方式都知道其他每种执行方式的细节。（Jini中下载远程站点的协议代码没能绕过这个需求）
总的来说，我们着重论述了网格体系结构的认证、协议和服务，对于API、SDK我们放在第二位。
4.网格结构体系的描述
我们描述网格体系的目标不是提供一个所有必要协议的集合（包括服务、API和SDK等），而是对各部分必要的规格进行分类定义。这个结论是个可扩展的、开放的结构并能在虚拟组织中解决。我们的体系和接下来讨论的组成部分是分层的，如图2所示。各层的组成部分有相同的特征，不过较低层只能构造的条件是能力和要求较低。
在指定的各层的网格体系中，我们遵从“沙漏模型”原则，沙漏的瓶颈形成了少数的核心协议（例如TCP和HTTP在Internet中）它们可以映射到许多不同的上层协议（沙漏的上层），同时可以映射到许多不同的底层协议（沙漏的底部）。根据定义，定义为核心协议的数量不能太多。在我们的体系中，资源和互联的协议的是核心组成部分，它降低了单独的资源共享的难度。协议在这些层次中被设计为能够在构造层被定义并执行不同种类的资源，还能依次建立一个宽泛的全局服务和特殊的应用在汇聚层，之所以叫汇聚是因为它们联系协调（汇聚）使用许多的资源。
我们的体系描述是高等级和很少的限制在设计执行上面。为了使抽象的描述更加具体，我们也举出例子，为了说明目的，这些协议被定义在Globus Toolkit[33]中，使用这些网格工程的有the NSF’s National Technology Grid[59], NASA’s Information Power Grid [46],DOE’s DISCOM [10], GriPhyN (www.griphyn.org), NEESgrid (www.neesgrid.org), Particle Physics Data Grid (www.ppdg.net), and the European Data Grid (www.eu-datagrid.org)。更多的资料见附录。
图2：网格分层体系结构同网络协议的关系。因为网络协议的延伸从网络到应用，所以有映射从网格层有到网络层。
4.1 构造：本地借口控制
网格构造层提供的资源及这些资源的共享访问的协调由网格协议来管理：例如，计算资源、存储系统、目录、网络资源和传感器。一个“资源”或许是个逻辑实体，例如一个分布式文件系统，计算机群组或分布式计算机池；在这些例子中，一个资源涉及内部协议（例如NFS存储控制协议或一个资源群组管理系统的过程控制协议），但是这些并不是网格体系所关心的。
本地构造组件开始向特定资源（无论物理或逻辑）访问则共享更高的的资源。因此有一个紧密和相互依赖的关系在构造层的功能实现上，另一方面能共享的支持，此外，构造层能够提供更丰富的功能，同时，如果我们提供较少的需求在构造层，这是网络构造的部署也就相对简单。例如，资源层支持预先保留功能，则可以为高层服务收集资源否则将很难达到目标。
然而实际上很少有支持如同“开箱即用”的预先保留的资源，一个需求为一个新资源的整体花费为增长的提前预留。
讨论这个庞大建筑物的意义、完整的系统、及时的集合是网格服务的一个重要意义。
一方面，经验支持将很小，资源将被允许访问它们的组织、状态和性能（例如无论它们是否支持预先保留），并且资源管理机制能够对服务的质量进行一些控制。接下来摘要和部分列表提供一些性能的描述。
计算资源：机制需要能够启动程序、监视和控制最终程序的运行。管理机制允许控制有用进程的资源分配，如预先保留机制。查询功能用来决定硬件和软件资源的特性，和相关状态信息一样，例如当前的负载和资源调度管理下的队列状态 。
存储资源:机制需要保存和取得文件。能对第三方高性能（例如有斑纹）进行有效传输。因而对于读写文件子集机制，或者对远程数据实行选取或压缩的功能。管理机制允许有益于对分配数据传输资源的控制 (空间，磁盘带宽，网络带宽，CPU)，如同预先保留机制。 查询功能来决定硬件和软件的状态和相关的负载信息例如可用的空间和带宽。
网络资源:管理机制提供对分配给网络传输的资源(例如，优先级，预约)有益的控制，查询功能应当提供网络的特性和负载来定义。
代码库:这是一个专门用来储存资源的机制，用来管理源代码和目标代码: 例如，一个CVS控制系统。
目录: 这是一个专门用来储存资源的机制，实现对目录查询和升级操作系统： 例如，一个相关数据库。
Gloubus Toolkit：Gloubus工具包被设计为 使用(主要)现有的构造层组件，包括卖方支持协议和界面。然而，如果一个卖方没有提供必须的构造层行为，Globus工具包将缺少的必要功能。例如，查询软件提供寻找不同种类但常见资源的结构和状态信息，例如计算机(像OS版本，硬件配置，负载，队列调度状态)，存储系统(像可用空间)，网络(像当前和预报将来的负载)和把这些信息封装成利于上层特别是在资源层执行的形式。另一方面，资源管理通常被假定为本地资源管理者的范围，一个例外是为保留和分配的标准的目的体系（GARA），它提供一个“插槽管理”为不支持这一能力的资源提供实现资源预先保留的功能。其余的增加发展批处理作业和计算机系统资源管理软件包和秃鹰来支持预先保留功能。
4．2 连接性: 通信便捷和安全
连接层为需要处理的专用网格网络定义核心通信和认证协议。通信协议能够在构造层资源之间交换数据。认证协议建立在通信服务提供加密的安全机制上，为检验用户和资源的身份。
通信要求包括传输、路由和命名。我们假定这些协议来自TCP/IP协议的特定栈中抽取的，像Internet分层协议体系中的 Internet（IP和ICMP），传输层(TCP和UDP)和应用层(DNS，OSPF，RSVP等)。这并不是说在未来，网格通讯不需要新的协议说明特殊的动态网络类型。
考虑到连接层的安全问题，我们观察到安全问题的复杂性，它十分重要要求任何解决方案尽可能的已存在的标准基础上进行。在通信中，许多基于Internet协议组的安全标准是适用的。
对于虚拟组织环境的鉴定方法需要以下的特征：
单一注册。 用户必须要登录一次（鉴定），这时就可以访问被定义的的构造层网格资源，不需要用户的进一步注册。
授权：用户必须让程序可以使用用户自身的身份启动，因此程序能够访问用户被授权的资源。该程序还能够有条件地委派它的部分权限授予另一个程序（有时涉及受限的授权）。
不同的本地安全解决方法的综合：每一个站点或者资源提供商可以使用一些不同的本地的安全解决方案，包括Kerberos和Unix安全方案。网格安全解决方案必须能够突破这些不同的本地解决方案。它们不要求网格安全方案大规模替代本地安全解决方案，但是它必须能够实现向本地环境的映射。
基于用户的信任关系: 用户可以使用多个提供者提供的资源，但并不要求资源提供者在安全环境中协同操作或者互操作。例如， 如果一个用户有权利使用站点A和B的资源，这个用户将站点A和B结合起来用而不需要要求A和B的安全管理相互作用。
网格安全方案也应该为通信保护提供可扩展的支持（例如，对保护级别的控制，独立数据单元的保护，支持TCP之外的可靠传输协议)并且能够控制授权结果，包括用各种方法限制授权的能力。
Globus Toolkit: 前面列出的Internet协议都是用于通信的，基于公匙的网格安全基础协议的（GSI）用于认证：通信保护和授权。GSI协议是建立并延伸了传输层安全协议（TLS），其涉及了下列的大多数问题:特别是单一登录，授权，不同的本地安全解决方法的综合，基于用户的信任关系（X.509版本身份证明被使用）。可以通过授权工具包来控制授权，它允许资源拥有者通过GAA来控制界面集成本地的策略。剩余的受限支持不在当前的工具包版本中但是也在被论证。
4．3 资源层:共享单一的资源
资源层定义是建立在连接层的通信和认证协议上的协议(API和SDK)，包括安全连接，初始化，监视，控制，审计和单独资源的共享的付费等。使用资源层的协议命令构造层的功能来访问和控制本地资源。资源层协议只关心单独的资源，因此忽略了全局状态和分布式收集不可分割的问题，这些问题是接下来将要讨论的汇聚层所关心的。
资源层的两个主要的协议是很重要的:
信息协议用来获得资源的结构和状态的信息，例如，它的配置，当前的负载，还有使用策略(比如花费)。
管理协议用来商议对共享资源的访问，例如指出资源需求(包括预先保留和服务质量)和操作的执行，例如构造的进程或者数据存取。因此管理协议还负责初始化共享关系，它们必须保证“要求的应用策略”和共享策略在底层的共享资源要求一致。还要考虑记帐和付费的问题。一个协议可能还需要支持监测操作的状态和控制(例如终止)操作的功能。
很多这样的协议被设想出时，资源(和连接)协议就形成了我们沙漏模型的瓶颈，因此其本身应当限制为一个要小和集中的协议。这些协议必须选择能抓住不同资源类型的基本共享机制（例如，不同的本地资源管理系统），同时又不能抑制这些高层协议的类型和性能的发展。
在4.1节提供的描述构造功能性的列表总结了资源层协议所需要的主要特性。在这张表上我们增加了“exactly once”这个概念。对于许多操作，当操作失败时应当有可靠的错误报告系统。
Globus Toolkit:采用了一个小的和基本上标准化的协议集，特别是:
网格资源信息协议(GRIP，基于目录访问协议LDAP)用来定义一个标准的资源信息协议和相关联的信息模型。 一个关联软状态的 资源注册协议（网格资源注册协议GRRP)，用网格索引信息服务器来注册资源，在下一节里面讨论。
基于HTTP的网格资源存取和管理协议(GRAM)，用来分配计算资源并监视和控制这些资源进行的计算。
一个FTP的扩展版本：“GridFTP”是一个数据存取的管理协议；扩展部分包括连接层安全、存取部分文件和对应的高速传输管理。FTP采用一个基础的数据传输协议是因为它支持了第三方数据传输，独立的控制和数据通路 便于执行复杂的服务。
LDAP也是一个目录访问协议。
Globus Toolkit为这些协议定义了客户端C和Java的API和SDK。这些服务也为服务器端提供了SDK和服务，来综合不同资源(计算力，存储，网络) 组成为网格。例如，网格信息资源信息服务(GRIS)的实现，使用了服务器端的LDAP的功能，允许对公布的的资源信息编号。一个在的服务器端重要的工具包组件是“守门员”，它提供本质上是一个GSI认可的“inetd”，说明GRAM协议能用于派发各种本地操作。一般的安全服务（GSS）API 被用于获取，转交，和验证认可信任书，并提供在传输层的完整性和保密性在这些SDK和服务器，使得能够在连接层推戴候选的安全性服务协议。
4.4 汇聚层:协调各种资源
资源层关注一个独立资源的交互性，在这个体系的下一层包括了协议和服务(API和SDK)，它不仅仅和某种特定的资源交互而是整体的通过资源的收集进行交互。由于这个原因， 我们将这个层命名为汇聚层。因为汇聚层组件建立在资源层和连接层形成的协议的沙漏瓶颈上，它们能够在不增加新的要求的情况下实现广泛的和多样化的共享行为。 例如：
目录服务：其允许虚拟组织的参与者发现虚拟组织中存在的资源或者其特性，一个目录服务允许用户根据名字和/或属性（例如类型，可靠性或负载）。资源层的GRRP和GRIP协议可以用来建立目录。
协同分配，调度以及代理服务：允许虚拟组织的参与者申请分配一个或者更多的资源为了在相应的资源上进行任务调度。例子包括AppLes, Condor-G, Nimrod-G和the DRM broker。
监测和诊断服务：其支持监视虚拟组织资源的失败，对抗性侵入(侵入探测)，超载等等。
数据复制服务：其支持虚拟组织的存储资源(也许包括网络和计算)管理为最佳数据访问性能像反应时间、可靠性和花费。
激活的网格编程系统可以在网格熟悉的环境中编程模型，使用不同的网格服务解决资源发现、安全、资源分配和其他问题。例 子包括信息传送界面的激活网格执行和管理者框架。
工作量管理系统和合作框架：也被称为问题解决环境（PSEs），提供对描述、使用、多布管理、异步和全构成机制。
软件发现服务发现和选择最好的软件解决基于参数平台的问题。例子包括NetSolve和Ninf。
公共授权服务强迫公共规则控制资源存储，性能的指标为公共团体成员都能访问的公共资源。这些服务器提供全局的规则强制服务器建立资源信息并且资源管理协议（在资源层）和在连接层的安全协议。Akenti涉及了一些这个问题。
公共统计和支付服务收集组织成员的资源使用信息为了统计、付费和对公共成员能限制资源的使用。
协作服务支持同等交换为潜在广大的用户团体，不论同步还是异步。例子见CAVERNsoft，Access Grid 和commodity groupware systems。
这些例子阐明了多样的汇聚层的协议和服务在实际应用中遭遇的挑战。注意到资源层协议必须在本质上简易并有广阔的拓展，汇聚层的协议跨越了从通用型到高端应用或特殊领域，以后的发展也许只是针对虚拟组织的。
汇聚功能可以作为永久的服务来实现，包括相关的协议和与应用相关的SDK（和相关的API）。在这两种情况，它们的实现能够建立在资源层协议和API上（或者其他的汇聚层）。例如，图3显示的一个汇聚层协同分配的API和SDK（中间层）可以使用一个资源层管理协议来操纵底层的资源。由以上功能所知，我们定义一个协同预留协议并实现一个协同预留服务，调用协同分配API来实现协同分配操作，还可能提供附加的功能，比如授权，容错以及记录。这时一个应用就可以使用协同预留服务来实现端到端的网络预留功能。
图3： 汇聚层和资源层协议，服务，API和SDK协同多种方法传递功能给应用。
汇聚层组件可以通过定制满足特定的用户社区，虚拟组织或者应用领域的需求，比如，一个SDK可以用来实现特定应用一致的协议，或者一个特定网络资源集合的协同预留服务。其他汇聚组件可以实现更多用途，例如，一个复制服务可以控制为多个社区一个国际性的存储系统，或者用于发现虚拟组织的目录服务。一般的，用户社团的规模越大，基于标准化基础来建造汇聚层组件协议和API就越重要。
Golbus Toolkit:除了上文列出的服务例子外，还有许多基于Globus的连接和资源协议，我们提到元目录服务（MDS），通过引入GIIS来支持对任意的资源子集的访问，LDAP信息协议用来访问特殊的资源，GRIS用来获得资源状态，GRRP用来注册资源。目录复制和管理复制服务用于支持网格环境中的数据复制管理。在线信任仓库服务（我的代理）提供安全代理信任存储，DUROC协同分配库为资源协同分配提供SDK和API。
4.5 应用层
应用层作为网格体系的最后一层是包含在虚拟组织环境中的。图4说明从应用程序员的观点来看网格结构。应用层是由任一层上定义的服务来构造的。在任一层，我们都很好的定义了协议来提供给一些有用的服务访问：资源管理，数据存取，资源发现等等。在任一层，API（提供理想状态的第三方SDK）也可以被定义为适当的服务执行信息协议交换。
图4：API被软件开发工具包使用，它使用网格协议联系网络服务为最终用户提供性能。上层的SDK能提供的功能不直接映射到一个特定的协议，但是联合许多协议调用另外的API和本地功能来实现。实线表示直接的调用; 虚线表示协议是交互的。
我们着重标志为“应用”的部分，在图4中显示为单独的层也许在实际上调用复杂的框架和库（例如普通构成体系,SciRun,CORBA,Cactus,工作流系统），内部特性也远远比图上显示的复杂。这些框架定义了它们自身的协议、服务和API（例如简单工作流访问协议）。然而，这些问题超出了这篇文章的范围，本文只讨论网格所要求的基本协议和服务。
5 实际上的网格体系
我们用两个例子来说明网格体系结构如何在实际中工作。表1显示了可以用于实现在图1中介绍的多学科模拟和利用空闲时间（射线追踪）的服务。基本的构造层组件在两个事例中都是一样的:包括计算机，存储系统和网络。 此外，各种资源都使用通讯和认证的标准的连接协议，而资源协议用来询问分配和管理。总之，各种应用使用混合了普通和专业化的服务。
在射线追踪应用的例子中，我们假定是基于一个高能计算系统。为了管理虚拟组织环境的大规模互相独立的任务的执行，这个系统保持追踪活动和未处理的任务。为每个任务寻找合适的资源，策划那些资源的执行表，诊测和相应各种各样的错误等等。 在这里的网格体系结构的上下文中，一个实现除了使用标准的资源和连接协议外，既使用了专门领域的汇聚服务(动态检查， 任务池管理，失效备援)也能使用更普通的汇聚服务(代理，执行和公共输入文件的备份)，还有标准资源和连接协议。 Condor-G代表了通向这个目标的第一步。
表1：网格服务用来构建图1中的两个例子。
在这个多学科模拟应用的例子中，在最高层的问题是完全不同的。一些应用框架（例如CORBA，CCA）可以构造各种组件的应用。我们也需要这样的机制：发现适当的计算资源，为这些资源预先保存，为进行分段运输（或许），提供对远程存储的访问等等。此外，一些专门领域的汇聚服务 (例如，解决者联结器，分布式数据存储)，但这些基础和射线追踪例子是一样的。
动态的、跨组织的虚拟组织共享关系的建立，管理和开采需要新的技术。我们以标识基本的系统组件的网格构架来组织我们对这个技术的讨论，说明这些组件的目的和功能，以及指出这些组件如何和其它的进行交互。
在定义一个网格构架中，我们从那些影响虚拟组织需要我们能够在任何潜在的参与者中建立共享关系的操作的景象开始。互用性因此成为中心问题被确定下来。在网络环境中，互用性意味着通用的协议。因此，我们的网格构架首先是一个协议构架，这些协议定义了基本的，使用者和资源协商，建立，管理和开采共享关系的机制。一个基于标准的、开放的构架会使得可跨展性，互用性，可移植性和代码共享变得容易；标准的协议可以使定义提供增强能力的、标准的服务容易。我们也可以构造应用程序接口和软件开发工具（参阅附录的定义）来提供需要用于创建一个可用的网格的编程抽象。合起来讲，这个技术和构架组成了通常术语化了的中间件（在一个分布式的网络中支持一系列应用的服务），虽然我们在这里因为它的含糊避免使用这个术语。我们将在后面讨论每一点。
为什么互操作性占有如此重要的位置？我们需要在任意不同的单位之间建立共享关系，动态的调和新参与者，通过不同的平台、语言和编程环境。在此状态下，如果他们没被定义和实现，就实现不了跨组织边界、执行策略、资源类型的互操作，这些机制也就不起作用。没有互操作性，在参与和应用虚拟组织时就必须进行双边的共享分配，此时不能保证双边使用的机制能扩展到其他的地方去。没有这样的保证，动态虚拟组织几乎是不可能实现的，而虚拟组织能够存在的类型也极为有限。就像WEB通过提供通用语法和协议（HTTP和HTML）使信息共享产生了革命，因此我们在资源共享方面也需要标准的语法和协议。
为什么评估协议的互动性？一个协议不仅定义特定了分布式系统元件之间进行的交互的目的和功能的实现，也包括这些交互之间的信息交换。这样对外部（交互）的关注比对内部（软件、资源特性）的关注更有实际价值。虚拟组织是明不稳定的：它的机制在发现资源、建立身份、进行授权和开始共享时必须是可扩展的和轻量级的，只有这样资源共享的分配才可能快速的建立和修改。因为虚拟组织是补充而不是对现有机构和共享机制的替换，它不能要求本地策略因此而进行底层的改变，同时要让单个机构能够继续对自己资源进行终端控制。因为协议管理了组件之间的交互而不是它们的执行。本地协议是被保留的。
为什么服务重要？一个服务（见附录）通过一种协议来表达和工作。标准服务的定义：对于有权使用计算、有权获得数据、资源发现、同步安排、数据复制等等，让我们能增进对虚拟组织的参与者提供的服务，对于那些可能妨碍虚拟组织应用发展的抽象的特定资源细节亦如此。
为什么我们也关注API和SDK？当然，这是因为与互操作性、协议、服务的相比，开发者必须能在动态的执行环境中开发出的复杂的系统。用户要能操作这些应用程序。应用程序的健全性，正确性，开发成本和维护成本都是要考虑的重要因素。标准概念，API和SDK能加速代码开发，能够便于代码共享，并增强程序的可移植性。API和SDK是协议的附加而不是替代的。没有标准协议的话，若要达到API层面的互操作，在到处就只能用相同的执行方式――在许多有意思的虚拟组织中是不可行的――或者每种执行方式都知道其他每种执行方式的细节。（Jini中下载远程站点的协议代码没能绕过这个需求）
总的来说，我们着重论述了网格体系结构的认证、协议和服务，对于API、SDK我们放在第二位。
4.网格结构体系的描述
我们描述网格体系的目标不是提供一个所有必要协议的集合（包括服务、API和SDK等），而是对各部分必要的规格进行分类定义。这个结论是个可扩展的、开放的结构并能在虚拟组织中解决。我们的体系和接下来讨论的组成部分是分层的，如图2所示。各层的组成部分有相同的特征，不过较低层只能构造的条件是能力和要求较低。
在指定的各层的网格体系中，我们遵从“沙漏模型”原则，沙漏的瓶颈形成了少数的核心协议（例如TCP和HTTP在Internet中）它们可以映射到许多不同的上层协议（沙漏的上层），同时可以映射到许多不同的底层协议（沙漏的底部）。根据定义，定义为核心协议的数量不能太多。在我们的体系中，资源和互联的协议的是核心组成部分，它降低了单独的资源共享的难度。协议在这些层次中被设计为能够在构造层被定义并执行不同种类的资源，还能依次建立一个宽泛的全局服务和特殊的应用在汇聚层，之所以叫汇聚是因为它们联系协调（汇聚）使用许多的资源。
我们的体系描述是高等级和很少的限制在设计执行上面。为了使抽象的描述更加具体，我们也举出例子，为了说明目的，这些协议被定义在Globus Toolkit[33]中，使用这些网格工程的有the NSF’s National Technology Grid[59], NASA’s Information Power Grid [46],DOE’s DISCOM [10], GriPhyN (www.griphyn.org), NEESgrid (www.neesgrid.org), Particle Physics Data Grid (www.ppdg.net), and the European Data Grid (www.eu-datagrid.org)。更多的资料见附录。
图2：网格分层体系结构同网络协议的关系。因为网络协议的延伸从网络到应用，所以有映射从网格层有到网络层。
4.1 构造：本地借口控制
网格构造层提供的资源及这些资源的共享访问的协调由网格协议来管理：例如，计算资源、存储系统、目录、网络资源和传感器。一个“资源”或许是个逻辑实体，例如一个分布式文件系统，计算机群组或分布式计算机池；在这些例子中，一个资源涉及内部协议（例如NFS存储控制协议或一个资源群组管理系统的过程控制协议），但是这些并不是网格体系所关心的。
本地构造组件开始向特定资源（无论物理或逻辑）访问则共享更高的的资源。因此有一个紧密和相互依赖的关系在构造层的功能实现上，另一方面能共享的支持，此外，构造层能够提供更丰富的功能，同时，如果我们提供较少的需求在构造层，这是网络构造的部署也就相对简单。例如，资源层支持预先保留功能，则可以为高层服务收集资源否则将很难达到目标。
然而实际上很少有支持如同“开箱即用”的预先保留的资源，一个需求为一个新资源的整体花费为增长的提前预留。
讨论这个庞大建筑物的意义、完整的系统、及时的集合是网格服务的一个重要意义。
一方面，经验支持将很小，资源将被允许访问它们的组织、状态和性能（例如无论它们是否支持预先保留），并且资源管理机制能够对服务的质量进行一些控制。接下来摘要和部分列表提供一些性能的描述。
计算资源：机制需要能够启动程序、监视和控制最终程序的运行。管理机制允许控制有用进程的资源分配，如预先保留机制。查询功能用来决定硬件和软件资源的特性，和相关状态信息一样，例如当前的负载和资源调度管理下的队列状态 。
存储资源:机制需要保存和取得文件。能对第三方高性能（例如有斑纹）进行有效传输。因而对于读写文件子集机制，或者对远程数据实行选取或压缩的功能。管理机制允许有益于对分配数据传输资源的控制 (空间，磁盘带宽，网络带宽，CPU)，如同预先保留机制。 查询功能来决定硬件和软件的状态和相关的负载信息例如可用的空间和带宽。
网络资源:管理机制提供对分配给网络传输的资源(例如，优先级，预约)有益的控制，查询功能应当提供网络的特性和负载来定义。
代码库:这是一个专门用来储存资源的机制，用来管理源代码和目标代码: 例如，一个CVS控制系统。
目录: 这是一个专门用来储存资源的机制，实现对目录查询和升级操作系统： 例如，一个相关数据库。
Gloubus Toolkit：Gloubus工具包被设计为 使用(主要)现有的构造层组件，包括卖方支持协议和界面。然而，如果一个卖方没有提供必须的构造层行为，Globus工具包将缺少的必要功能。例如，查询软件提供寻找不同种类但常见资源的结构和状态信息，例如计算机(像OS版本，硬件配置，负载，队列调度状态)，存储系统(像可用空间)，网络(像当前和预报将来的负载)和把这些信息封装成利于上层特别是在资源层执行的形式。另一方面，资源管理通常被假定为本地资源管理者的范围，一个例外是为保留和分配的标准的目的体系（GARA），它提供一个“插槽管理”为不支持这一能力的资源提供实现资源预先保留的功能。其余的增加发展批处理作业和计算机系统资源管理软件包和秃鹰来支持预先保留功能。
4．2 连接性: 通信便捷和安全
连接层为需要处理的专用网格网络定义核心通信和认证协议。通信协议能够在构造层资源之间交换数据。认证协议建立在通信服务提供加密的安全机制上，为检验用户和资源的身份。
通信要求包括传输、路由和命名。我们假定这些协议来自TCP/IP协议的特定栈中抽取的，像Internet分层协议体系中的 Internet（IP和ICMP），传输层(TCP和UDP)和应用层(DNS，OSPF，RSVP等)。这并不是说在未来，网格通讯不需要新的协议说明特殊的动态网络类型。
考虑到连接层的安全问题，我们观察到安全问题的复杂性，它十分重要要求任何解决方案尽可能的已存在的标准基础上进行。在通信中，许多基于Internet协议组的安全标准是适用的。
对于虚拟组织环境的鉴定方法需要以下的特征：
单一注册。 用户必须要登录一次（鉴定），这时就可以访问被定义的的构造层网格资源，不需要用户的进一步注册。
授权：用户必须让程序可以使用用户自身的身份启动，因此程序能够访问用户被授权的资源。该程序还能够有条件地委派它的部分权限授予另一个程序（有时涉及受限的授权）。
不同的本地安全解决方法的综合：每一个站点或者资源提供商可以使用一些不同的本地的安全解决方案，包括Kerberos和Unix安全方案。网格安全解决方案必须能够突破这些不同的本地解决方案。它们不要求网格安全方案大规模替代本地安全解决方案，但是它必须能够实现向本地环境的映射。
基于用户的信任关系: 用户可以使用多个提供者提供的资源，但并不要求资源提供者在安全环境中协同操作或者互操作。例如， 如果一个用户有权利使用站点A和B的资源，这个用户将站点A和B结合起来用而不需要要求A和B的安全管理相互作用。
网格安全方案也应该为通信保护提供可扩展的支持（例如，对保护级别的控制，独立数据单元的保护，支持TCP之外的可靠传输协议)并且能够控制授权结果，包括用各种方法限制授权的能力。
Globus Toolkit: 前面列出的Internet协议都是用于通信的，基于公匙的网格安全基础协议的（GSI）用于认证：通信保护和授权。GSI协议是建立并延伸了传输层安全协议（TLS），其涉及了下列的大多数问题:特别是单一登录，授权，不同的本地安全解决方法的综合，基于用户的信任关系（X.509版本身份证明被使用）。可以通过授权工具包来控制授权，它允许资源拥有者通过GAA来控制界面集成本地的策略。剩余的受限支持不在当前的工具包版本中但是也在被论证。
4．3 资源层:共享单一的资源
资源层定义是建立在连接层的通信和认证协议上的协议(API和SDK)，包括安全连接，初始化，监视，控制，审计和单独资源的共享的付费等。使用资源层的协议命令构造层的功能来访问和控制本地资源。资源层协议只关心单独的资源，因此忽略了全局状态和分布式收集不可分割的问题，这些问题是接下来将要讨论的汇聚层所关心的。
资源层的两个主要的协议是很重要的:
信息协议用来获得资源的结构和状态的信息，例如，它的配置，当前的负载，还有使用策略(比如花费)。
管理协议用来商议对共享资源的访问，例如指出资源需求(包括预先保留和服务质量)和操作的执行，例如构造的进程或者数据存取。因此管理协议还负责初始化共享关系，它们必须保证“要求的应用策略”和共享策略在底层的共享资源要求一致。还要考虑记帐和付费的问题。一个协议可能还需要支持监测操作的状态和控制(例如终止)操作的功能。
很多这样的协议被设想出时，资源(和连接)协议就形成了我们沙漏模型的瓶颈，因此其本身应当限制为一个要小和集中的协议。这些协议必须选择能抓住不同资源类型的基本共享机制（例如，不同的本地资源管理系统），同时又不能抑制这些高层协议的类型和性能的发展。
在4.1节提供的描述构造功能性的列表总结了资源层协议所需要的主要特性。在这张表上我们增加了“exactly once”这个概念。对于许多操作，当操作失败时应当有可靠的错误报告系统。
Globus Toolkit:采用了一个小的和基本上标准化的协议集，特别是:
网格资源信息协议(GRIP，基于目录访问协议LDAP)用来定义一个标准的资源信息协议和相关联的信息模型。 一个关联软状态的 资源注册协议（网格资源注册协议GRRP)，用网格索引信息服务器来注册资源，在下一节里面讨论。
基于HTTP的网格资源存取和管理协议(GRAM)，用来分配计算资源并监视和控制这些资源进行的计算。
一个FTP的扩展版本：“GridFTP”是一个数据存取的管理协议；扩展部分包括连接层安全、存取部分文件和对应的高速传输管理。FTP采用一个基础的数据传输协议是因为它支持了第三方数据传输，独立的控制和数据通路 便于执行复杂的服务。
LDAP也是一个目录访问协议。
Globus Toolkit为这些协议定义了客户端C和Java的API和SDK。这些服务也为服务器端提供了SDK和服务，来综合不同资源(计算力，存储，网络) 组成为网格。例如，网格信息资源信息服务(GRIS)的实现，使用了服务器端的LDAP的功能，允许对公布的的资源信息编号。一个在的服务器端重要的工具包组件是“守门员”，它提供本质上是一个GSI认可的“inetd”，说明GRAM协议能用于派发各种本地操作。一般的安全服务（GSS）API 被用于获取，转交，和验证认可信任书，并提供在传输层的完整性和保密性在这些SDK和服务器，使得能够在连接层推戴候选的安全性服务协议。
4.4 汇聚层:协调各种资源
资源层关注一个独立资源的交互性，在这个体系的下一层包括了协议和服务(API和SDK)，它不仅仅和某种特定的资源交互而是整体的通过资源的收集进行交互。由于这个原因， 我们将这个层命名为汇聚层。因为汇聚层组件建立在资源层和连接层形成的协议的沙漏瓶颈上，它们能够在不增加新的要求的情况下实现广泛的和多样化的共享行为。 例如：
目录服务：其允许虚拟组织的参与者发现虚拟组织中存在的资源或者其特性，一个目录服务允许用户根据名字和/或属性（例如类型，可靠性或负载）。资源层的GRRP和GRIP协议可以用来建立目录。
协同分配，调度以及代理服务：允许虚拟组织的参与者申请分配一个或者更多的资源为了在相应的资源上进行任务调度。例子包括AppLes, Condor-G, Nimrod-G和the DRM broker。
监测和诊断服务：其支持监视虚拟组织资源的失败，对抗性侵入(侵入探测)，超载等等。
数据复制服务：其支持虚拟组织的存储资源(也许包括网络和计算)管理为最佳数据访问性能像反应时间、可靠性和花费。
激活的网格编程系统可以在网格熟悉的环境中编程模型，使用不同的网格服务解决资源发现、安全、资源分配和其他问题。例 子包括信息传送界面的激活网格执行和管理者框架。
工作量管理系统和合作框架：也被称为问题解决环境（PSEs），提供对描述、使用、多布管理、异步和全构成机制。
软件发现服务发现和选择最好的软件解决基于参数平台的问题。例子包括NetSolve和Ninf。
公共授权服务强迫公共规则控制资源存储，性能的指标为公共团体成员都能访问的公共资源。这些服务器提供全局的规则强制服务器建立资源信息并且资源管理协议（在资源层）和在连接层的安全协议。Akenti涉及了一些这个问题。
公共统计和支付服务收集组织成员的资源使用信息为了统计、付费和对公共成员能限制资源的使用。
协作服务支持同等交换为潜在广大的用户团体，不论同步还是异步。例子见CAVERNsoft，Access Grid 和commodity groupware systems。
这些例子阐明了多样的汇聚层的协议和服务在实际应用中遭遇的挑战。注意到资源层协议必须在本质上简易并有广阔的拓展，汇聚层的协议跨越了从通用型到高端应用或特殊领域，以后的发展也许只是针对虚拟组织的。
汇聚功能可以作为永久的服务来实现，包括相关的协议和与应用相关的SDK（和相关的API）。在这两种情况，它们的实现能够建立在资源层协议和API上（或者其他的汇聚层）。例如，图3显示的一个汇聚层协同分配的API和SDK（中间层）可以使用一个资源层管理协议来操纵底层的资源。由以上功能所知，我们定义一个协同预留协议并实现一个协同预留服务，调用协同分配API来实现协同分配操作，还可能提供附加的功能，比如授权，容错以及记录。这时一个应用就可以使用协同预留服务来实现端到端的网络预留功能。
图3： 汇聚层和资源层协议，服务，API和SDK协同多种方法传递功能给应用。
汇聚层组件可以通过定制满足特定的用户社区，虚拟组织或者应用领域的需求，比如，一个SDK可以用来实现特定应用一致的协议，或者一个特定网络资源集合的协同预留服务。其他汇聚组件可以实现更多用途，例如，一个复制服务可以控制为多个社区一个国际性的存储系统，或者用于发现虚拟组织的目录服务。一般的，用户社团的规模越大，基于标准化基础来建造汇聚层组件协议和API就越重要。
Golbus Toolkit:除了上文列出的服务例子外，还有许多基于Globus的连接和资源协议，我们提到元目录服务（MDS），通过引入GIIS来支持对任意的资源子集的访问，LDAP信息协议用来访问特殊的资源，GRIS用来获得资源状态，GRRP用来注册资源。目录复制和管理复制服务用于支持网格环境中的数据复制管理。在线信任仓库服务（我的代理）提供安全代理信任存储，DUROC协同分配库为资源协同分配提供SDK和API。
4.5 应用层
应用层作为网格体系的最后一层是包含在虚拟组织环境中的。图4说明从应用程序员的观点来看网格结构。应用层是由任一层上定义的服务来构造的。在任一层，我们都很好的定义了协议来提供给一些有用的服务访问：资源管理，数据存取，资源发现等等。在任一层，API（提供理想状态的第三方SDK）也可以被定义为适当的服务执行信息协议交换。
图4：API被软件开发工具包使用，它使用网格协议联系网络服务为最终用户提供性能。上层的SDK能提供的功能不直接映射到一个特定的协议，但是联合许多协议调用另外的API和本地功能来实现。实线表示直接的调用; 虚线表示协议是交互的。
我们着重标志为“应用”的部分，在图4中显示为单独的层也许在实际上调用复杂的框架和库（例如普通构成体系,SciRun,CORBA,Cactus,工作流系统），内部特性也远远比图上显示的复杂。这些框架定义了它们自身的协议、服务和API（例如简单工作流访问协议）。然而，这些问题超出了这篇文章的范围，本文只讨论网格所要求的基本协议和服务。
5 实际上的网格体系
我们用两个例子来说明网格体系结构如何在实际中工作。表1显示了可以用于实现在图1中介绍的多学科模拟和利用空闲时间（射线追踪）的服务。基本的构造层组件在两个事例中都是一样的:包括计算机，存储系统和网络。 此外，各种资源都使用通讯和认证的标准的连接协议，而资源协议用来询问分配和管理。总之，各种应用使用混合了普通和专业化的服务。
在射线追踪应用的例子中，我们假定是基于一个高能计算系统。为了管理虚拟组织环境的大规模互相独立的任务的执行，这个系统保持追踪活动和未处理的任务。为每个任务寻找合适的资源，策划那些资源的执行表，诊测和相应各种各样的错误等等。 在这里的网格体系结构的上下文中，一个实现除了使用标准的资源和连接协议外，既使用了专门领域的汇聚服务(动态检查， 任务池管理，失效备援)也能使用更普通的汇聚服务(代理，执行和公共输入文件的备份)，还有标准资源和连接协议。 Condor-G代表了通向这个目标的第一步。
表1：网格服务用来构建图1中的两个例子。
在这个多学科模拟应用的例子中，在最高层的问题是完全不同的。一些应用框架（例如CORBA，CCA）可以构造各种组件的应用。我们也需要这样的机制：发现适当的计算资源，为这些资源预先保存，为进行分段运输（或许），提供对远程存储的访问等等。此外，一些专门领域的汇聚服务 (例如，解决者联结器，分布式数据存储)，但这些基础和射线追踪例子是一样的。
434
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
