CN103139314B - 基于P2P的分布式Web服务发现方法及其系统 - Google Patents

Abstract

本发明涉及服务计算领域。针对目前大多数已有的Web服务发现技术所采用的基于关键字的服务匹配机制在服务发现性能和服务发现效果不能令人满意的现状，本发明提出一种基于P2P的分布式Web服务发现方法及其系统。本方法首先使用本体建模工具构建领域本体，使用OWL-S描述框架对Web服务提供语义描述，使服务包含更多的语义信息；然后根据领域划分构建双层分布式自治域的服务发现结构，在域内基于该领域共享的本体信息对服务提供分类，使用分布式的P2P技术构建服务发现框架；最后本发明提出了一种基于Chord的语义Web服务发现算法，利用服务本体信息对Web服务进行注册和查询。本发明基于P2P的框架，改进传统的Chord算法进行Web服务发现，提高了服务发现的查询率和查准率，具有优良的服务发现性能。

Description

基于P2P的分布式Web服务发现方法及其系统

技术领域

本发明涉及服务计算领域，特别是涉及一种基于P2P的分布式Web服务发现方法及其系统。

背景技术

Web服务发现技术是Web服务系统架构中的重要组成部分，它的目标是从互联网上快速准确的找到用户所需的服务，从而实现企业和行业异构系统的集成和灵活的业务流程。目前己有的Web服务发现技术大都是采用基于关键字的服务匹配机制，缺乏对服务功能的语义描述，使得机器无法理解和处理，导致查询准确率较低，因此并不能对知识进行有效地推理，影响服务系统可用性。为了解决上述问题，研究人员将语义技术应用到了Web服务领域，提出了基于语义的Web服务发现。基于语义的Web服务发现具有较高的查全率和查准率，提高了Web服务发现的性能。

当前Web服务发现方式按网络拓扑结构主要分为两种：集中式和分布式。

1）集中式Web服务发现结构，主要表现为基于UDDI注册协议的服务发现体系结构，通过服务请求与UDDI注册信息之间的关键字匹配的方法来实现服务查询。基于UDDI的集中式服务发现方法，一方面使用基于关键字的精确匹配缺乏对关键字语义内容的理解，因此服务查询的查全率和查准率都不高。另一方面，集中注册式的Web服务发现结构实现简单，在系统中存储数据较少的情况下可以保证较高的发现效率，但随着系统中数据的增多，发现效率会明显下降，尤其当某时段的查询请求过多时，容易造成网络拥塞，从而增加服务发现的时间，同时集中式结构还存在网络节点的单点失效问题，这些都极大的影响了服务发现结构的可用性。

2）分布式Web服务发现结构，由于集中式服务发现在大规模开放环境中的限制，研究者提出了很多分布式Web发现结构，其中基于P2P网络的服务发现系统得到了研究者的一致认同。基于P2P的分布式服务发现结构又可分为结构化和非结构化P2P以及混合P2P结构三种方式。非结构化P2P方式由于存在服务查询请求泛洪，导致查询负载过重的问题，因此并不适合直接应用在大规模开放式服务网络中。

发明内容

发明目的：为了解决上述集中式和分布式Web服务发现存在的问题.，本发明提供了一种基于P2P的分布式Web服务发现方法及其系统。

技术方案：基于P2P的分布式Web服务发现方法，包括如下步骤，

首先构建领域本体信息库，为服务注册中心提供统一分类标准；

其次根据领域划分构建双层分布式自治域的服务发现结构，在域内基于该领域共享的本体信息对服务提供分类，使用分布式的P2P技术构建Web服务结构；

最后利用服务本体信息并适用一种改进的基于Chord的语义Web服务发现算法，对Web服务进行注册和查询。

其中，使用OWL-S描述框架对Web服务提供语义描述构建领域本体信息库。

双层分布式自治域的服务发现结构构建方法是，根据领域本体的分类将整个服务发现网络分为若干管理域，在管理域中服务注册中心之间使用Chord协议进行服务查询；每个管理域有两个基本节点，包括管理服务器和和服务注册中心。

改进的基于Chord的语义Web服务发现算法的实现方法是，在每个节点上记录网络中节点的请求数信息，根据请求次数建立TOP-K最大堆，将热门节点的路由信息放入缓存以加快处理请求的查询时间。

对Web服务进行注册的方法是：当Web服务发布时，先将其服务注册信息向服务注册中心提交，如果该服务注册信息符合注册服务领域，那么管理服务器将该服务注册到本地节点，否则管理服务器根据Web服务的所属领域将Web服务信息发布到与该服务所属域相符的域管理服务器上，再使用域内注册机制实现注册。

对Web服务进行查询的方法是：当Web服务请求时，首先将Web服务请求信息向服务注册中心提交，根据Web服务请求所属领域判断是否在域内进行服务发现；如不是则将该服务请求经由域内的管理服务器发往目标服务域，再进行域内服务匹配与查询。

基于P2P的分布式Web服务发现系统，包括：服务提供、服务请求、服务注册中心；其中，服务提供模块，用于构建领域本体信息库，为服务注册中心提供统一分类标准；服务请求模块，用于向服务注册中心发送Web服务请求信息；服务注册中心模块，用于解析服务请求，并进行服务注册和查询。

本发明采用上述技术方案，具有以下有益效果：本发明基于P2P的分布式Web服务发现，改进了传统的Chord算法，具有优良的服务发现性能；本体库可以提供统一的服务信息分类，使得语义服务描述可以得到支持；分布式语义Web服务发现方法可以避免负载不均的影响，具有效率高的优点；相同功能服务注册于相邻的若干个节点，这有效的避免了单点失效对服务系统造成的影响；用户的个性化需求获得支持，可以根据需求决定是否指定供应商。

附图说明

图1为本发明实施例的双层分布式语义Web服务发现拓扑结构示意图；

图2为本发明实施例的服务注册中心示意图；

图3为本发明实施例的分段Hash机制示意图。

具体实施方式

下面结合具体实施例，进一步阐明本发明，应理解这些实施例仅用于说明本发明而不用于限制本发明的范围，在阅读了本发明之后，本领域技术人员对本发明的各种等价形式的修改均落于本申请所附权利要求所限定的范围。

基于P2P的分布式Web服务发现方法，采用B/S（Browser/Server）架构，其中浏览器客户端具体表现为一个Web页面其主要作用是收集当前用户请求送给服务器后台。服务器端采用Java语言开发，主要表现为一个servlet程序，该servlet作为服务注册模块和服务查询模块。用户需要查询服务时，通过提交OWL-S描述的服务请求文件，系统通过解析该文件获得目标服务语义信息，再根据这些信息来发现具体服务。服务提供商在经过身份认证后向服务系统提交服务OWL-S描述文件，通过路由表转发至目标节点，并有目标文件解析文件后注册至本地数据库。

具体包括如下步骤，

步骤一、构建领域本体信息库，为服务注册中心提供统一分类标准；

领域本体可以表示特定领域范围内的特定知识，可以根据具体系统需求来构建，它可以是某几个领域的一种结合，也可以是一个领域中的一个小范围，由于知识具有显著的领域特性，所以领域本体能够更为合理而有效的进行知识表示；

领域本体可以根据应用需求方便的进行扩充、进一步细化或者修改。通过领域本体形式化的表述将服务功能领域进行划分，同时对每个领域中的概念及其属性进行明确定义。

本实施例使用本体是基于OWL描述框架的，因此选用较流行的Protégé本体编辑器。Protégé主要用于语义网中本体的构建及维护，是本体开发的核心工具，主要提供本体概念类、关系、属性和实例的构建，对OWL描述的本体支持较好。

在形式化定义本体后，采用本体推理工具Jena API将本体存储到数据库以支持本体共享。

步骤二、根据领域划分构建双层分布式自治域的服务发现结构，在域内基于该领域共享的本体信息对服务提供分类，使用分布式的P2P技术构建Web服务结构；如图1所示。

根据本体最上层领域的分类将整个服务发现网络分为若干管理域，在管理域中服务注册中心之间使用Chord协议进行服务发现。每个管理域中存在两种基本节点：

1)管理服务器(Manager Server)

在逻辑层面上：管理服务器是领域中Web服务发现结构的管理节点。它一方面提供域内的各项管理功能，例如域内本体库更新、用户和服务提供商身份管理等，另一方面作为边界网关(Border Gateway)给外部服务请求提供路由机制。

在物理层面上：管理服务器存储的核心数据包括：1)路由表：记录了各个相邻领域边界网关的领域信息和物理地址二元组，通过路由表，管理服务器可将非本领域的服务请求发送至目标领域，然后再进行域内发现。2)领域本体信息：利用开源的本体推理工具Jena api分析领域本体文件，并将其持久化到本体库中进行存储，同时支持领域管理者更新本体库中的信息。3)为用户和服务提供商提供注册管理功能，使用可控匿名机制来实现使用服务系统时身份认证的问题。

2)服务注册中心(Service Registry)

在逻辑层面上：语义注册中心是服务发现结构中的存储节点和域内请求转发节点。它根据语义来分类存储Web服务信息，并提供基于语义的Web服务匹配和服务信誉管理功能。

在物理层面上：语义注册中心中具体存储：1)owls格式的语义Web服务描述文件集及描述文件的索引；2)Chord协议路由表－Finger Table，实现请求转发机制；3)实现服务信誉管理，包括QoS数据收集、信誉值计算。

步骤三、利用服务本体信息并适用一种改进的基于Chord的语义Web服务发现算法，对Web服务进行注册和查询。

一种改进的基于Chord的语义Web服务发现算法具体是，首先在每个节点上记录网络中节点的请求数信息，根据请求次数建立TOP-K最大堆，将热门节点的路由信息放入缓存以加快处理请求的查询时间；

1)用户发送请求至服务注册中心(RC)，若用户请求中没有指定服务提供商则转至步骤5，反之将服务请求解析为(Domain，Category，Provider)；

2)分段计算三元组哈希值，求得服务所在虚拟节点的哈希值为H=Hash(Domain)+Hash(Category)+Hash(Provider)；

3)若H对应的实际节点就是本节点则查询服务注册库，返回结果并退出算法，若不是转至4；

4)查询Finger表，若表中存在可转发节点则转发服务请求，转至3，否则返回错误；

5)分段计算三元组哈希值，求得服务所在虚拟节点的哈希值为H=Hash(Domain)+Hash(Category)+m3比特个0；

6)若H对应的实际节点就是本节点则查询服务注册库，查询本注册中心中满足要求的服务，返回结果；转发请求至H到H+2^m3范围内的其他有效节点。若H不对应本节点转至7；

7)根据Finger表转发服务请求，若Finger表中存在可转发节点则转至6，否则返回错误。

对Web服务进行注册的方法是：当Web服务发布时，先将其服务注册信息向服务注册中心提交，如果该服务注册信息符合注册服务领域，那么管理服务器将该服务注册到本地节点，否则管理服务器根据Web服务的所属领域将Web服务信息发布到与该服务所属域相符的域管理服务器上，再使用域内注册机制实现注册。具体步骤如下：

服务注册请求包含三方面信息，第一是该服务所属的领域，例如旅游或经济；第二该服务功能概念，例如酒店；第三是该服务提供商的ID。在域内服务注册代理接收服务注册请求时，首先需要根据以上三方面信息并基于本体库和身份数据库将服务请求解析为一个三元组(Domain，Category，Provider)，其中Domain表示服务所属的领域；Category表示服务在该领域中所属的类别，该字段可进一步细分成一个多级类别；Provider字段表示服务提供商的身份信息。这里需要说明的是Category属性的值是根据本体库调用Jena API生成的一个由低到高的包含层次的类别。另外，当服务请求中的ID不能获得认证时，注册代理会向请求者返回ID无效的错误提示。

在获得一个有效的三元组后，注册代理发现该请求的Domain与自身所在的Domain不符，则将请求发送给域内的管理服务器(边界网关)，管理服务器根据外部路由表将请求发送给与该服务Domain相符的域管理服务器上，再使用的域内注册机制实现注册。下面将详细介绍域内服务注册机制。

由于域内是基于改进Chord算法的P2P发现结构，而该算法首先需要对关键字进行哈希得出节点标识符，本文将基于分段哈希的机制将服务注册到域内的各个注册中心，服务注册中心见图2所示。

假设服务提供商P1对虚拟节点数量为(哈希值为m位)的Chord环中的某个注册中心提出一个酒店查询服务注册请求，首先注册中心通过供应商身份数据库鉴别该服务提供商的身份信息，得到该供应商的ID信息设为ID1，之后查询相应的领域本体，可知酒店查询的域内分类为Accommodation-Hotel，得出服务标识为(Travel，Accommodation-Hotel，ID1)，然后分别对运用哈希函数对三元组中的字段值计算哈希值，将他们拼成m位的哈希值(见图3)，根据哈希值查询节点中的Finger表转发服务注册请求，在找到目标节点后将服务描述文件注册在相应的服务注册中心。

在本实施例的注册机制中，属于不同服务提供商的服务通过分段Hash机制后将产生Hash(Travel)+Hash(Accommodation-Hotel)到 $\mathrm{Hash}\left(\mathrm{Travel}\right)+\mathrm{Hash}(\mathrm{Accom}\mathrm{mod}\mathrm{ation}-\mathrm{Hotel})+2^{m_3}$ (服务提供商对应的比特位数为m3)范围内的哈希值，这使得相同功能的服务能够存储到Chord环中的某一段的若干个节点上。

对Web服务进行查询的方法是：当Web服务请求时，首先将Web服务请求信息向服务注册中心提交，根据Web服务请求所属领域判断是否在域内进行服务发现；如不是则将该服务请求经由域内的管理服务器发往目标服务域，再进行域内服务匹配与查询。具体步骤如下：

用户进行服务查询时与服务注册采用相似的机制，分为域内查询和域外查询。当服务注册中心接收用户查询请求时，首先根据用户查询目标服务所属的领域生成Domain字段，并判断是否在域内进行服务发现。如不是则将该服务请求经由领域边界网关发往目标服务域，再进行域内服务发现。

域内查询在获得服务请求Domain字段后，继续解析出用户请求目标服务所属的分类，并得出Category字段的值，然后使用分段Hash机制分别生成m1比特域哈希值和m2比特分类哈希值。在服务Provider字段值上，根据用户是否指定服务提供商，可以分为两种场景：

1)用户指定服务提供商(Provider≠0)

系统查询用户指定服务提供上的ID，将其进行哈希生成m3比特服务提供商身份哈希值，与前两部分一起构成总的m比特哈希值。这种情况下目标服务只可能存放在与该哈希值对应的一个服务注册中心上，故只需要到该服务器上查询是否存在目标服务；

2)用户未指定服务提供商(Provider＝0)

系统将后m3比特置为0，将其与前两部分一起构成总的m比特哈希值。由于用户未指定服务提供商，则相同功能的服务可能存放在Chord中某一段内若干个服务注册中心上。因为服务提供商的字节只有m3位，则同一功能分类的服务只可能注册在一定数量的节点上(远小于)，这些节点所对应的虚拟哈希值范围在Hash(Domain)+Hash(Category)到Hash(Domain)+Hash(Category)+之间，在服务发查询时需要将服务请求转发至这些节点查询是否存在目标服务。

基于P2P的分布式Web服务发现系统，包括：服务提供、服务请求、服务注册中心；其中，服务提供模块，用于构建领域本体信息库，为服务注册中心提供统一分类标准；服务请求模块，用于向服务注册中心发送Web服务请求信息；服务注册中心模块，用于解析服务请求，并进行服务注册和查询。

Claims (2)

1.基于P2P的分布式Web服务发现方法，其特征在于，包括如下步骤，

首先构建领域本体信息库，为服务注册中心提供统一分类标准；

其次根据本体最上层领域的分类将整个服务发现网络分为若干管理域，在管理域中服务注册中心之间使用Chord协议进行服务发现，每个管理域中存在两种基本节点：管理服务器和服务注册中心；在域内基于该领域共享的本体信息对服务提供分类，使用分布式的P2P技术构建Web服务结构；

具体是，首先在每个节点上记录网络中节点的请求数信息，根据请求次数建立TOP-K最大堆，将热门节点的路由信息放入缓存以加快处理请求的查询时间；

1)用户发送请求至服务注册中心(RC)，若用户请求中没有指定服务提供商则转至步骤5)，反之将服务请求解析为(Domain，Category，Provider)；

2)分段计算三元组哈希值，求得服务所在虚拟节点的哈希值为H＝Hash(Domain)+Hash(Category)+Hash(Provider)；

3)若H对应的实际节点就是本节点则查询服务注册库，返回结果并退出算法，若不是转至步骤4)；

4)查询Finger表，若表中存在可转发节点则转发服务请求，转至步骤3)，否则返回错误；

5)分段计算三元组哈希值，求得服务所在虚拟节点的哈希值为H＝Hash(Domain)+Hash(Category)+m3比特个0，其中，m3为服务提供商对应的比特位数；

6)若H对应的实际节点就是本节点则查询服务注册库，查询本注册中心中满足要求的服务，返回结果；转发请求至H到H+2^m3范围内的其他有效节点，若H不对应本节点转至步骤7)；

7)根据Finger表转发服务请求，若Finger表中存在可转发节点则转至步骤6)，否则返回错误；

对Web服务进行注册的方法是：当Web服务发布时，先将其服务注册信息向服务注册中心提交，如果该服务注册信息符合注册服务领域，那么管理服务器将该服务注册到本地节点，否则管理服务器根据Web服务的所属领域将Web服务信息发布到与该服务所属域相符的域管理服务器上，再使用域内注册机制实现注册；

对Web服务进行查询的方法是：当Web服务请求时，首先将Web服务请求信息向服务注册中心提交，根据Web服务请求所属领域判断是否在域内进行服务发现；如不是则将该服务请求经由域内的管理服务器发往目标服务域，再进行域内服务匹配与查询。

2.如权利要求1所述的基于P2P的分布式Web服务发现方法，其特征在于：使用OWL-S描述框架对Web服务提供语义描述构建领域本体信息库。