基于混合结构化P2P的数字图书馆交互框架_数字图书馆论文

基于混合式结构化P2P的数字图书馆互操作框架,本文主要内容关键词为:结构化论文,框架论文,数字图书馆论文,操作论文,P2P论文,此文献不代表本站观点,内容供学术参考,文章仅供参考阅读下载。

1 问题的提出

随着数字图书馆建设的日益深入,互联网上涌现出越来越多的数字图书馆,虽然增加了用户获取信息的渠道,但并未减轻用户获取信息的沉重负担,其原因是:这些由不同组织建设的数字图书馆具有分布性、异构性和自治性等特征,使得各数字图书馆之间很难相互通信和共享资源,现有的数字图书馆就像是互联网上一座座信息孤岛,不能实现跨仓储的统一检索。由于没有任何一个数字图书馆能拥有满足用户所有需求的信息,因此用户为了全面地获取所需信息,往往需要访问多个数字图书馆,这就要求用户不仅要向多个数字图书馆重复提交同一检索请求,而且还要用户自行将各数字图书馆返回的检索结果进行合并、整理并去掉重复的信息,同时还要知道各数字图书馆的网址,并熟悉各数字图书馆的检索方法,显然这种检索方式费时费力。用户迫切期望各数字图书馆之间的信息和服务是可互操作的,即通过一定的机制,屏蔽互联网上广域分布的各数字图书馆间的差别,将它们无缝集成为一个能够共享信息资源和服务的联合体,用户通过一个统一的检索平台,即可实现对众多数字图书馆信息资源的透明访问[1]。

互操作问题在数字图书馆界越来越受到重视,提出了许多解决方案,其中利用OAI-PMH协议(Open Archive Initiative Protocol for Metadata Harvesting)[2]进行元数据采集的方案被认为是一种简单的、低障碍的互操作模式[3],并得到广泛应用,其基本思想是:提供统一检索的数字图书馆中心从多个数字图书馆采集元数据,经过合并处理后保存在元数据仓储中,并以这些元数据为基础为用户提供统一检索服务。目前OAI-PMH应用系统采用的是集中检索模式,这种模式下所有检索操作均依赖中心服务器,随着元数据的剧增、检索用户的增加,中心服务器的负担将越来越重,并逐渐成为系统的性能瓶颈,一旦中心服务器崩溃,整个系统也随之瘫痪。为了解决这个问题,本文引入混合式结构化P2P技术对OAI-PMH互操作方案进行改进,变集中式检索模式为分布式检索模式,以有效解决现有OAI-PMH应用系统的负载问题。

2 互操作框架

2.1 基于Chord的混合式结构化P2P的引入

P2P网络是一种采用对等策略计算模式的网络[4],它改变了传统Client/Server模式集中存储和处理资源的方法,在P2P网络中的每个节点的地位是对等的,都可以作为服务使用者和服务提供者,可以把一项关键应用任务分配到P2P网络中的若干个节点进行分布式处理,从而解决了服务器单点失效问题,实现了负载均衡,并提高了系统的可扩展能力。因此,可以利用P2P网络将现有数字图书馆互操作系统的集中式检索方式转换成具有负载均衡并可避免单点失效的分布式检索方式,而其中关键的问题是如何针对数字图书馆实际需求构造P2P网络以及有关路由算法,以实现高效快速的资源定位。

按照资源组织与定位方法,P2P网络可分为集中式P2P、全分布非结构化P2P、全分布结构化P2P和混合式P2P等四类,这四类P2P网络各具优缺点,其中:①集中式P2P网络,通过一个中央目录服务器集中提供各节点资源的索引信息,因此有利于网络资源的快速检索,但容易因单点故障而导致整个系统失效。②全分布非结构化P2P网络,没有设置中央目录服务器,对等节点之间的内容查询直接通过相邻节点广播接力传递,其最显著特点是“完全去中心化”,因此系统稳定性强,但由于采用泛洪方式查询和定位资源,查询效率低,而且随着节点数量的增加,网络可能因过多的查询消息而发生拥塞。③全分布结构化P2P网络,采用分布式哈希表(Distributed Hash Tables,简写成DHTs)技术来组织网络中的节点,分布式哈希表存储所有信息资源的索引条目,巨大的哈希表被分割成不连续的块,按照特定的规则要求每个节点负责维护哈希表的一个片段,同时要求每个节点维护一个路由表。定位资源时通过路由表进行选择性转发,经过一定的路由跳数就能定位到所需资源,因此有更快的查找速度,以及更好的可扩展性和可管理性等许多优点。但随着节点数量的增多,其DHTs维护机制的复杂性也将增大。目前比较著名的DHTs路由算法有Chord、CAN、Tapestry、Pastry等[5]。④混合式P2P网络,按照一定规则将P2P网络划分成若干个簇,并将每个簇组织成集中式P2P结构,在每个簇中选择一个性能较强的节点作为超级节点,在其上存储该簇其他普通节点资源的索引信息,目前Kazaa模型等主流的混合式P2P网络中所有超级节点均以全分布非结构化P2P结构连接在一起,信息查询请求只在超级节点之间转发,由此可见这种结构的P2P网络综合了集中式P2P快速查找和全分布非结构化P2P去中心化的优势,同时也存在全分布非结构化P2P网络的缺陷,可将这种结构的P2P网络称为混合式非结构化P2P网络。

笔者在充分分析上述各类P2P网络优缺点的基础上,试图结合混合式非结构化P2P网络和结构化P2P网络的优点,同时克服它们各自的缺点,提出一种新的P2P网络结构模型——基于Chord的混合式结构化P2P网络模型,与混合式非结构化P2P网络不同之处在于所有超级节点以Chord结构化P2P网络结构组织在一起,这样可以避开泛洪查找机制,提高信息资源检索效率。Chord是由美国麻省理工学院提出的结构化P2P路由协议,具有路由表结构简单、负载均衡、可扩展性好等优点,具有很高的应用价值,但研究发现Chord具有路由表中存在一定的冗余信息、信息定位效率不高等缺点[6],因此本文在3.3中对Chord路由算法进行改进和优化。

2.2 互操作框架总体结构

笔者在OAI-PMH框架基础上,引入基于Chord的混合式结构化P2P网络模型,建立了数字图书馆互操作框架,如图1所示。本互操作框架在控制层面上采用两层结构,下层是由参与互操作的各数字图书馆(称为Common Peer)组成的资源层;上层是由超级节点(Super Peer)以Chord结构化P2P网络结构组织在一起所构成的索引层(称为超级节点Chord环)。

图1 基于混合式结构化P2P的数字图书馆互操作框架

本互操作框架包含以下几个主要对象:

(1)簇:参与互操作的数字图书馆作为普通节点以集中式P2P网络模式连接到相应的超级节点上,形成簇。簇的体系结构采用OAI-PMH协议交互框架模型,每个簇中设立三类节点:普通节点、超级节点、注册节点,分别充当OAI-PMH框架中数据提供者、服务提供者和注册服务器的角色。普通节点通过OAI-PMH协议发布元数据,超级节点通过OAI-PMH协议采集元数据并提供检索服务。

簇的大小即簇中的节点个数将影响系统的整体性能,如果簇太大,超级节点负载超荷,极易产生单点失效障碍,成为系统的瓶颈;如果簇太小,上层的超级节点数则增多,必然增加该层DHTs维护机制的复杂性。鉴于此有必要依据一定的划分标准将我国数字图书馆划分成若干簇。考虑到我国行业之间横向割断、行业内部纵向相关的事实[7],可将同一行业的数字图书馆组成一个簇,如教育数字图书馆簇、医学数字图书馆簇、国防工业数字图书馆簇等。如果同一行业内的数字图书馆个数太多,还可以再按地区分为不同的簇,如教育系统包含各类院校的数字图书馆,规模很大,可以细分为华北地区教育数字图书馆簇、华中地区教育数字图书馆簇、华东地区教育数字图书馆簇、华南地区教育数字图书馆簇、西北地区教育数字图书馆簇。

(2)普通节点(Common Peer):各数字图书馆以普通节点的身份加入本互操作框架,普通节点通过注册模块在注册节点中注册成为OAI-PMH框架的数据提供者,注册节点为其分配一个唯一标识符(Unique Identifier),称为CP_UI。

(3)超级节点(Super Peer):在本互操作框架中选用带宽能力、计算能力和存储能力较强的服务器作为超级节点。超级节点通过注册模块在注册节点中注册成为OAI-PMH框架的服务提供者,注册节点为其分配一个唯一标识符SP_UI。

(4)注册节点(Registry Peer):注册节点承担着OAI-PMH框架注册服务器的角色,负责对本簇的超级节点、普通节点进行注册、检测、查询等管理工作。本互操作框架要求普通节点、超级节点在发布或采集元数据之前必须要在注册节点中进行注册,注册信息包括Owner、BaseURL、ProtocolVersion、Administrator Information(name、email、phone、address、postalcode)等。注册节点收到注册请求后将执行相关验证程序来测试注册者是否符合OAI-PMH接口的规定,普通节点和超级节点只有通过测试,才能被注册。

(5)注册中心节点(Registry Center Peer):在本互操作框架中由注册中心节点对所有的注册节点进行管理,注册节点只有在注册中心节点注册后才能够生效,注册中心节点为每个注册节点分配一个唯一标识符RP_UI。为了使本互操作框架中所有节点的唯一标识符具有唯一性,每个注册节点为本簇普通节点和超级节点分配的唯一标识符(CP_UI/SP_UI)可采用如下形式:RP_UI.LocalName,在同一簇中各节点的LocalName必须互不相同。

(6)超级节点Chord环[8]:负责为资源层提供快速的索引查询服务,根据Chord协议的规定,所有超级节点按一定规则排列成一个逻辑圆环,每个超级节点管理一部分资源的路由信息并维护一张路由表,从而实现对资源的快速定位。

3 互操作框架关键技术

3.1 元数据的发布与采集

普通节点以OAI-PMH框架数据提供者的身份通过元数据采集接口向超级节点发布元数据,因此,普通节点应为其数字仓储中的数字对象建立元数据。普通节点可以根据本馆的实际情况创建各种格式的元数据,但OAI-PMH协议规定数据提供者必须能够提供DC(都柏林核心元数据)格式的元数据,因此普通节点应能够通过元数据的映射,发布符合OAI-PMH协议规范的元数据。普通节点还应该为各数字对象设立一个唯一标识符DOI(Digital Object Identifier),DOI的形式为:Prefix/Suffix,Prefix(前缀)是由注册节点分配给普通节点的唯一标识符CP_UI,Suffix(后缀)是普通节点为数字对象定义的本地标识符。为了方便检索结果的查重,本互操作框架将不同数字图书馆所拥有的相同信息资源的DOI后缀设为相同,采用以下公式生成后缀:Suffix=hash(title+creator+publisher+date),其中,Hash表示哈希函数,title、creator、publisher、date分别为DC格式元数据记录中title、creator、publisher、date元素的内容,“+”表示将这些元素的内容连接起来。

超级节点从注册节点处获取各个普通节点的基地址,然后以OAI-PMH框架服务提供者的身份从各个普通节点上采集元数据。超级节点使用OAI-PMH协议的GetRecord或ListRecords命令向普通节点发送请求,从而获得从普通节点处返回的以XML文档形式封装的响应信息,从中解析出元数据记录并存储于元数据仓储中,作为向用户提供检索服务的基础。当超级节点第一次向普通节点采集元数据时,需要采集所有过去的元数据,之后定期或不定期地采集新增的元数据。如果采用定期(比如每天或每周)方式采集元数据,可能出现如下两种情况:普通节点在一段时间内没有增加任何元数据,但超级节点仍定期来采集,将增加网络和普通节点的负担;普通节点新增了元数据,但超级节点还没有对普通节点进行采集,使超级节点采集的元数据不完整。为了避免上述情况的发生,本互操作框架采用不定期方式采集元数据,一旦普通节点更新了元数据,就及时将更新情况反馈给超级节点,超级节点立即启动元数据采集机制从普通节点中抓取新增的元数据。

3.2 数字对象DOI的地址解析机制

在本互操作框架中数字对象DOI的地址解析采用Handle System[9]解析机制,由注册中心节点和注册节点共同构成DOI的地址解析系统,负责将数字对象的DOI转换成相应的物理存放地址。因此,由注册中心节点负责存储所有注册节点唯一标识符RP_UI以及它们的物理地址;注册节点负责存储本簇所有数字对象的DOI以及物理地址。当注册中心节点接收到一个数字对象DOI时,从其前缀中取出RP_UI,由RP_UI解析得到该数字对象所在簇的注册节点的物理地址,将该DOI发往该注册节点,注册节点通过该DOI解析得到该数字对象所在普通节点的物理地址。

3.3 超级节点Chord环的路由算法

3.3.1 路由表的构建

根据Chord协议的规定,使用哈希函数(如SHA-1)对每个超级节点的唯一标识符SP_UI进行计算产生一个m位的节点标识符,称为之为SP_ID,将所有超级节点按照SP_ID从小到大沿顺时针方向排列成一个逻辑圆环,即构成为Chord环。每个超级节点在Chord环上有两个邻居节点,顺时针方向离本地节点最近的节点称为Successor(后继节点),逆时针方向离本地节点最近的节点称为Predecessor(前驱节点),为了便于资源的定位,超级节点需记录后继节点和前驱节点的信息。同时,超级节点用上述相同的哈希函数为信息资源的每个关键词分配一个m位的标识符,称之为KEY_ID。超级节点从元数据记录中抽取如下形式的DC元素作为信息资源的关键词并进行哈希计算产生KEY_ID:<元素名>元素内容,如对等网络,即KEY_D=Hash(<元素名>元素内容)。将关键词KEY_ID的路由信息(其中SP_ID为保存该信息资源的DC元数据记录的超级节点的标识符)存放在Chord环上节点标识符等于或大于KEY_ID的第一个超级节点上,将该超级节点称为KEY_ID的Successor节点(后继节点),并表示为Successor(KEY_ID),如图2所示。由于KEY_ID和SP_ID都是使用哈希函数计算产生,因此,每个超级节点都被分配管理基本相同数量的路由信息,达到负载平衡[10]。

标准的Chord协议要求每个节点维护一个路由表,按顺时针方向进行路由,从它的路由表可以看出,节点对顺时针方向邻居节点的信息了解得比较多,而对逆时针方向上的邻居信息却知之甚少。而实际上主机间的TCP连接是双向的,因此Chord环拓朴是双向的,而且节点在环上的实际位置分配是随机和均匀的,在这种情况下,如果所查找的关键词在当前节点的前驱节点,也要从顺时针方向进行多次转发才可以到达目标节点[11,12]。为了可以从两个方向来逼近目标节点,提高定位资源的效率,本互操作框架要求每个超级节点维护两个路由表,一个是顺时针方向的路由表,称其为顺时针指针表(Clockwise finger table,简称为C_Finger表),见表1,这是Chord协议规定的路由表,负责顺时针方向的查询;另一个表是逆时针方向的路由表,称其为逆时针指针表(Anticlockwise finger table,简称为A_Finger表),见表2,负责逆时针方向的查询,这是为了实现双向查询而在Chord协议基础上增加的一个路由表。如果SP_ID和KEY_ID都用m位二进制位数表示,那么上述两个指针表各含有m个表项,每个表项分别记为c_finger[i]、a_finger[i]。若当前节点标识符为n,则C_Finger表和A_Finger表的项目定义如下:

为了便于定位和连接,在上述指针表第一项前面增加一项c_finger[0],用于记录前驱节点的信息,这样C_Finger表共有m+1个表项。

图2 6-Bit的Chord环

由于表1和表2定义的路由表存在冗余信息,如图2所示,为了增加路由表的有效信息,减少查询跳数,采取如下步骤重构路由表:

步骤1:分别扫描C_Finger表和A_Finger表中的信息,标记出node列相同的表项,只保留其中第一项,删除其余重复信息。假设共删除w行信息,当w>=1时,对于C_Finger表,转步骤2;对于A_Finger表,转步骤3。

步骤2:在C_Finger表未能覆盖到的区域按顺时针方向顺序取w个节点加入到C_Finger表的尾部。

步骤3:在A_Finger表未能覆盖到的区域按逆时针方向顺序取w个节点加入到A_Finger表的尾部。

重构后的Chord环路由表如图3所示。

3.3.2 路由算法的设计

一个超级节点N(以下称为当前节点)在Chord环上查找标识符为KEY_ID的资源的路由信息,实际上就是查找Successor(KEY_ID)的过程,其步骤如下:

(1)判断KEY_ID是否∈[前驱节点SP_ID,当前节点SP_ID],若属于,则当前节点是Successor(KEY_ID),查找结束,否则转(2)。

(2)查找当前节点C_Finger表和A_Finger表的所有项,判断KEY_ID是否在某项的start与node之间,如果存在这样的表项,则该表项的node对应节点就是Successor(KEY_ID),查找结束,否则转(3)。

图3 改进的Chord环路由表

(3)在C_Finger表和A_Finger表中查找离KEY_ID最近的节点,并发送查找消息给这个节点,通知其查找Successor(KEY_ID)。

算法如下:

由于原来的Chord协议每个节点只有一个路由表,如图2所示的C_Finger Table,若节点8需要查找关键词标识符为53的后继节点,则需要进行如图4(a)所示的查找过程。图4(b)显示改进的Chord只需进行一步查询即可完成同样的查询。由此可见,尽管每个节点多维护了一个路由表,但查询效率却提高了很多。

3.4 多维元数据检索方法与检索流程

3.4.1 核心元素支配的多维检索方法

Chord协议采用的是基于单个关键词的资源定位方法,这显然不能满足用户的检索需求,因此,需要研究如何在Chord环中进行多维检索,例如用户提交如下检索请求:

title:Java程序设计&&publisher:清华大学出版社&&language:chi (1)

这是一个由3个子条件构成的多维检索请求。最简单的方法是:先进行3个子条件的检索,得到满足各子条件的信息资源集合(1<=i<=3),然后求它们的交集,得到检索结果W,即:W=∩(1<=i<=3)。这种方法由于要进行所有子条件的单独查询,大大增加Chord环的路由任务。鉴于此,笔者提出核心元素支配的多维检索方法,其思路是:从检索请求S中选取元素作为检索的核心元素,先在Chord环中检索符合检索子条件的信息资源集合W,然后再在W中将符合检索请求S其他检索子条件的信息挑选出来作为检索的最终结果。根据DC元数据格式15个元素描述信息的重要程度,可以按如下顺序选取核心元素:Identifier(标识符)、Creator(创建者)、Title(题名)、Subject(主题)、Publisher(出版者)、Date(日期)、Language(语种)、Format(格式)、Type(类型)、Coverage(覆盖范围)、Source(来源)、Contributor(其他责任者)、Description(描述)、Relation(关联)、Rights(权限)。

3.4.2 检索流程

(1)用户向任何一个普通节点或超级节点提交检索请求S,并指定检索结果数目。若是由普通节点接收检索请求,则将检索请求传给本簇的超级节点。

(2)超级节点接收到检索请求S后,在本地元数据仓储中进行匹配查找,如果检索结果数目已经达到用户预先的要求,就立即向用户返回结果,转(6)步骤;如果检索结果数目没有达到用户预先的要求,则转下一步。

(3)超级节点从检索请求S中按3.4.1所述的方法选取核心元素,将核心元素与相应的检索词组成<核心元素名>检索词,称为检索子条件,然后进行哈希运算并得到运算值KEY_ID,即KEY_ID=hash(<核心元素名>检索词),比如3.4.1所述的检索式(1)的核心元素为title,KEY_ID=hash(Java程序设计)。将KEY_ID按3.3.2所述路由算法在Chord环上查找KEY_ID值的后继节点Successor(KEY_ID)。

图4 Chord与改进的Chord查找方式比较

(4)从Successor(KEY_ID)中取出所有关键词KEY_ID的路由信息集{……}。

(5)依次从标识符为SP_ID1、SP_ID2、……SP_IDn的超级节点中取出KEY_ID值的元数据记录,得到符合S检索请求检索子条件的信息资源集合W,然后再将W中符合检索请求S其他检索子条件的信息挑选出来形成资源集合W1。根据3.1所述DOI后缀相同的信息资源为相同的信息资源,因此此步骤还须比较资源集合W1中所有资源的DOI后缀,后缀相同的资源只需保留其中一个,形成检索的最终结果返回给用户。

(6)用户从检索的最终结果所含的元数据记录中选择自己所需的资源,本互操作框架将用户所需资源的DOI发往3.2所述的DOI地址解析系统,并解析得到用户所需资源的物理地址,最后连接相应的普通节点请求获取所需的资源。

3.5 互操作框架的维护机制

本互操作框架必须能够随节点的加入和退出及时作适应性的改变。新的普通节点加入本互操作框架,需在本簇的注册节点进行注册;当注册节点接收到或检测到本簇某普通节点退出的消息时,需通知本簇的超级节点将属于该普通节点的资源的元数据记录从元数据仓储中删除,然后由本簇的超级节点再通知这些资源的后继节点删除这些资源的路由信息。超级节点加入或退出时,需对超级节点Chord环做必要的修复操作:

3.5.1 新超级节点的加入

一个新超级节点new_sp加入到Chord环的过程如下:

(1)新超级节点new_sp首先在Chord环中查找一个离它地理位置较近的节点作为自己的向导节点。

(2)向导节点对new_sp的SP_UI进行哈希运算,得到new_sp的标识符Newsp_ID。

(3)向导节点在Chord中查找Newsp_ID的后继节点NS,并将后继节点的原前驱节点NP作为new_sp的前驱节点,并通知前驱节点NP(其标识符为NP_ID)将其后继节点更新为new_sp。

(4)new_sp从后继节点NS中转移关键词标识符∈[NP_ID+1,Newsp_ID]的资源的路由信息,由new_sp负责保存维护。

(5)new_sp根据3.3.1所述的方法构造自己的C_Finger表和A_Finger表。

(6)通知相关节点更新它们的C_Finger表。步骤如下:

步骤1:new_sp通知其前驱节点查看是否要修改C_Finger表,若需要则进行相应的修改。节点P修改C_Finger表的算法如下:

步骤2:由前驱节点通知其前驱节点查看是否要修改C_Finger表,若需要则调用P.update_cfinger()进行相应的修改。

步骤3:重复步骤2,直到某前驱节点不需要修改C_Finger表为止。

(7)通知相关节点更新它们的A_Finger表。步骤如下:

步骤1:new_sp通知其后继节点查看是否要修改A_Finger表,若需要则进行相应的修改。节点S修改A_Finger表的算法如下:

步骤2:由后继节点通知其后继节点查看是否要修改A_Finger表,若需要则调用S.update_afinger()进行相应的修改。

步骤3:重复步骤2,直到某后继节点不需要修改A_Finger表为止。

3.5.2 超级节点的退出

节点的退出分为两种情况,一种是正常退出,一种是异常退出。当超级节点n需正常退出的时候,它将通知它的后继节点ns,并将自己负责管理的资源路由信息转移到它的后继节点上,同时由ns通知相关节点将C_Finger表和A_Finger表中node列内容为n的都替换为ns。异常退出通常是由于主机崩溃或IP网络断开等原因而在没有任何先兆的情况下突然离开网络,致使该节点失效,从而造成Chord环断裂。因此,Chord环中的每个节点必须定期向其后继节点发送探测消息,一旦发现其后继节点失效,则应启动更新机制进行Chord环的更新。为了保证节点n的失效不会影响检索的正常进行,每个节点都维护一张包括K个最近后继节点的后继表,如果某个节点发现其后继节点已经失效,则从后继表顺序查找第一个正常节点替换失效节点[14]。

由于在本互操作框架中超级节点承担着信息检索任务,为了增强系统的健壮性,防止超级节点的异常退出而影响系统完成检索任务,本互操作框要求注册节点从本簇的普通节点中选择性能最强的普通节点作为候选的超级节点,因此普通节点在注册时还应提供自身的带宽能力、计算能力和存储能力,注册节点根据这些信息计算普通节点性能优先级,将优先级最高的普通节点作为候选超级节点,并将超级节点上的元数据等信息拷贝到候选超级节点上。注册节点实时监视超级节点运行状况,一旦超级节点出现问题,候选超级节点就作为新的超级节点代替出现问题的超级节点,然后,注册节点将剩余普通节点按性能优先级重新排队以选取新的候选超级节点。

4 与相关研究成果的比较

与现有的数字图书馆互操作方案[15-7]相比,本文提出的互操作框架具有以下优点:

(1)参与互操作的数字图书馆具有高度的自治性。本互操作框架只要求各数字图书馆发布信息资源的元数据,无需改变其原有的结构和标准,而且各数字图书馆可以自主地决定共享信息资源的范围以及共享权限,从而保证了数字图书馆参与互操作的积极性。

(2)信息资源检索效率高。一方面是由于资源层各数字图书馆所有信息资源的元数据按一定规律分布存储在索引层的各超级节点中,由索引层提供快速的索引查询服务;另一方面是由于索引层采用Chord结构化P2P网络组织,只要所需的信息资源被发布于上层超级节点上,那么经过较少的路由跳数就一定能够找到该信息资源,而不是盲目泛洪寻找目标。

(3)消除了单点失效的问题。本互操作框架将索引、检索任务合理地分配给索引层的各超级节点,而不是由单个服务器单独承担,有效地实现了负载均衡,避免了因单点故障而导致的系统失效。

(4)具有较好的健壮性和可扩展性。数字图书馆加入和退出本互操作框架,不会影响索引层的结构,因此本互操作框架能够适应数字图书馆的高度动态变化。另一方面,虽然超级节点的加入和退出需要对索引层作适当的修复操作,但本互操作框架要求选择性能好、变动少的节点作为超级节点,因此索引层比较稳定,而且每簇都设置了一个候选的超级节点,可随时替代异常退出的超级节点。

(5)可确保数字对象链接的有效性。本互操作框架数字对象采用DOI进行标识,并由注册中心节点和注册节点共同构成DOI的地址解析系统,如果数字对象的URL发生变动,数字图书馆只要向本簇的注册节点提交并更新数据,即可避免因URL变动而出现的“死链”问题。

(6)高效的查重功能。本互操作框架将不同数字图书馆所拥有的相同信息资源的DOI后缀设为相同,因此只需比较检索结果中所有数字对象的DOI后缀即可去掉重复记录。

5 结语

本文针对目前OAI-PMH应用系统的集中检索模式在实现大规模数字图书馆互操作上的不足,在OAI-PMH框架基础上,通过引入基于Chord的混合式结构化P2P网络模型,提出一种分布式检索模式的数字图书馆互操作框架,该实现方案可以在保持各数字图书馆原有结构、标准不变的基础上,以较低的代价实现大规模数字图书馆的互操作问题,并保证系统有较高的检索效率和较好的可扩展性、健壮性。本研究的下一步工作将以本互操作框架为模型构建一个原型系统,以进一步验证和完善本互操作框架,从而为本互操作框架在数字图书馆建设中的具体应用提供技术支持。

标签:;  ;  ;  ;  ;  ;  ;  ;  ;  

基于混合结构化P2P的数字图书馆交互框架_数字图书馆论文
下载Doc文档

猜你喜欢