资源发现方法

资源发现方法
一、目前网格中所使用的资源发现方法
资源发现机制是分布式系统研究领域的重点问题，有许多工作已经或正在进行。

现有的网格系统采用了不尽相同的资源发现机制。

其中较为典型的有：
1．Globus
Globus网格中的监控和发现服务组件MDS (Monitoring and Discovery Service),它将网格内的资源及服务组织为诸多VO，利用基于LDAP的层次目录服务机制来组织管理信息，这是一种集中式的信息管理系统。

MDS包含两个基本元素[4]：1)信息提供者（information provider）提供有关单个实体的信息；2)聚合目录服务（aggregate directory services），搜集、管理、索引由多个信息提供者提供的信息。

信息提供者提供有关网格中各种资源（实体）的信息；而聚合目录则提供了与VO有关的网格资源的特定试图。

信息提供者通过网格资源注册协议（Grid Resource Registering Protocol,GRRP）向聚合目录注册，聚合目录可以用网格资源索引协议（Grid Resource Indexing Protocol,GRIP）主动搜集信息提供者的信息，用户则通过GRIP查询信息提供者或聚合目录上的信息。

由于GRIP、GRRP等协议都是软件状态协议，因此MDS具有很高的容错性。

与Web中的搜索相比，GRIP相当于HTTP协议，而聚合目录则相当于搜索引擎。

在GRIP和GRRP的支持下，MDS构建了层次化的资源发现服务，如图所示：
图MDS中的两层资源发现结构
GRIP具有资源的发现（discovery）和查询（enquire）两种基本功能，其中资源的发现通过搜索操作进行。

如，一个信息提供者维护有关一组工作站的信息，资源发现代理通过在该信息提供者上执行搜索操作来获取这一组工作站中满足一定条件的部分机器的信息。

查询则可被用于对被发现资源信息的求精：用给定资源名对信息提供者进行查询，可得到相关的详细的资源描述。

GRIP采用标准的LDAP协议，包括其数据模型、查询语言等。

LDAP数据模型使用类型来描述资源（一个资源可能有多个类型，如某机器上的存储设备的类型为“storage”和“file system”），并使用层次化的命名机制对信息提供者记录的资源进行命名（如同一主机上的资源包含队列、存储等，被组织成树状结构），如图
图 LDAP数据模型中的资源命名机制
GRIP的查询语言不提供复杂的联结操作，因为在信息服务的底层提供一致的全局资源状态视图难以扩展到大规模的系统。

GRRP没有指定资源注册和查找消息的传输方式。

目前MDS 中利用LDAP传输GRRP,GRRP消息被映射成LDAP中的add操作。

随着网格和Web Service的进一步融合，GRRP中可能会采用SOAP协议进行消息传输。

尽管采用了两层的资源发现结构，但是MDS并没有提出适应于整个网格范围的资源发现机制。

MDS中的聚合目录只使用于提供某个特定VO内的资源信息，各个聚合目录之间尽管可以通过标准的协议进行交互，进行信息复制等操作，但MDS并没有对这些信息结点之间的著者交互定义通用的协议和规范。

2. Condor
Condor[5]将大量地理分布、属于不同所有者的空闲计算资源聚合起来支持高吞吐率的计算。

Condor中的计算资源由于只是在空闲时才对Condor可用，参与具有不稳定性，因此被称为机会资源（opportunistic resources）。

Condor允许对任务设置检查点[6]（checkpoint），并允许资源拥有者在需要自己的资源时对任务进行抢占。

被抢占的任务不会因此失败，因为检查点保存了任务的状态，可以继续在Condor中寻找其它的资源完成运行。

Condor中与资源和调度有关的一个重要部件时匹配器[7,8]（Matchmaker），它负责将任务请求和周期性提交上来的资源状况作匹配，并通知匹配的双方进行谈判和协作。

匹配器做的匹配只是为相互匹配的任务和资源做一种“介绍”，而不管任务的执行。

Condor会周期性重新匹配任务，若发现更好的资源，则正在进行的任务会被迁移到新的机器上执行。

Condor中使用Classad[9]语言描述任务的需求和资源的属性，其主要特点为：使用半结构化数据模型；将查询语言包含在数据模型中，约束表示为属性；可以被任意嵌套，可表示资源的聚合或协同分配请求。

二、W eb Service中的服务发现方法
Web Service致力于通过使用Web的标准协议实现服务的互操作和集成。

Web Service和网格研究有相似性，且面向服务的网格体系结构OGSA(Open Grid Services Architecture)使两者出现了很强的融合趋势。

UDDI是Web服务中信息注册的标准规范，它对Web服务实体进行标准分类、集中式的注册和查询。

目前广泛使用的是UDDI2.0[11]的版本。

UDDI2.0基本上是一种集中式的服务注册和查找机制，而UDDI3.0[12]已经提出了联邦注册中心的概念，将服务注册和发现从集中方向向分布方式转变。

UDDI的核心是Web Service服务描述的表示，一个UDDI注册项提供了分类、建目录和管理Web Service的标准机制，使Web Service能够被发现和使用。

UDDI还支持多种不同的服务查找方式，如：1)根据实现的接口来查找Web Service 实例；2)根据已知分类来查找Web Service的提供者；3)询问一个给定Web Service所采用的安全和传输协议；4）根据关键词搜索服务。

三、P2P网络中的资源发现方法
网格与P2P都面向解决分布环境中资源集成和协调使用问题，在很多方面具有很强的互补性，而且两者的相互融合已逐渐成为学术界的共识。

目前网格中的集成资源比P2P网络中的资源更强大，但只包括了少量或中等规模的结点，实际的部署中仍然包含大量集中式的数据存储和资源管理部件。

因此，随着规模的增长，网格在可伸缩性方面有越来越多的问题需要解决；尽管目前P2P主要针对文件共享以及CPU主频共享等应用，但其资源通常具有较大规模，并在很大程度上实现了可伸缩、自组织的管理。

在P2P环境中，结点还具有高度的自治性，其频繁的加入和退出导致P2P网络呈现高度的动态性。

在这种高度分散、动态的P2P网络上进行有效的资源发现一直是P2P研究中的一个重要问题。

目前P2P应用一般基于关键词来查询所需的资源。

根据实现方式的不同，资源查找可分为基于目录、基于泛洪（flooding）以及基于分布式哈希表（Distributed Hash Tables,DHT）等3种基本形式。

其中，基于集中目录的系统，如Napster,为资源建立集中式的目录，各结
点通过该目录进行资源的发现和查找；基于泛洪的系统，如Gnutella等，则取消了集中的索引结点，结点之间通过TCP连接形成了覆盖网络（overlay network），依赖邻结点之间的消息广播来查找所需的资源。

以上两种资源发现的方式如图所示。

其中，P代表P2P网络种的结点，S代表目录服务器，Q代表查询，R代表查询的响应，D代表结点之间的文件下载。

(a)Napster系统采用的基于集中目录的查询方式
(b)Gnutella中泛洪的查询方式
图 P2P网络中基于集中目录以及泛洪式的文件查询方式
由于Gnutella网络中结点邻接拓扑是随机建立的，且没有固定的结构，因此这一类的P2P 网络也被称为无结构P2P网络（unstructured P2P network）。

显而易见，基于集中式目录的P2P系统面临伸缩性问题，基于泛洪的P2P系统搜索效率低，且由于泛洪占用大量网络带宽，同样也会有可伸缩性方面的问题。

为了解决资源发现中系统规模与效率之间的矛盾，基于分布式哈希表的系统被作为一种新的网络形式提出，典型的DHT系统有Chord,CAN和Pastry等。

DHT被视为哈希表数据结构的一种分布式的版本，试图实现资源按标识或键值（key）的有效存取。

DHT系统中资源发现的核心问题式将资源或其指针根据键值映射到P2P网络中的结点，并且对于给定的资源键值，快速、高效的将插入、查找或删除消息路由到与之对应的结点。