用于发布基于结构化元数据的发现的插件模型的方法和装置

摘要

本文描述了用于在网络中发布服务和执行对服务的查询的方法和装置。用原生搜索描述语言编写的服务描述被转换为规范化模式。所述规范模式被发布到网络。在执行所述搜索之前，可以用任何原生搜索描述语言编写的针对网络的查询也被转换为规范化模式。因此，可获得的所有服务可以被发布和在查询中被定位，而不用考虑原生搜索描述语言。

说明书

根据35U.S.C.§119要求优先权

本专利申请要求于2009年6月11日递交的、题为“METHODS ANDAPPARATUS FOR A PLUG-IN MODEL FOR PUBLISHING STRUCTUREDDATAINADISTRIBUTED NETWORK”的临时申请No.61/186,319的优先权，该临时申请已经转让给其受让人，特此通过引用将该临时申请明确地并入本文。

技术领域

本公开涉及移动操作环境，更具体而言，涉及覆盖网络以及用于在其中发布数据结构的方法和装置。

背景技术

覆盖网络是在现有网络上建立的节点和逻辑链路的虚拟网络。覆盖网络的示例包括但是不限于：因特网、Chord、内容可寻址网络(CAN)、Pastry和Viceroy。在一些覆盖网络中，每个节点可以存储被称为分区(partition)的覆盖网络数据的一部分，以便将数据分布在网络上，以提高数据的存储和获取的网络效率。

加入覆盖网络的设备或节点可能期望从在覆盖网络中的另一个设备或节点获得服务。使用多种服务描述语言中的任何一种来在覆盖网络中发布这样的服务，每种服务描述语言具有用于找到所发布的服务的对应服务发现协议。由维基百科给出的服务发现的定义陈述如下：“服务发现协议是允许设备和由这些设备提供的服务在计算机网络上的自动检测的网络协议”。换句话说，服务发现是找到所请求的服务的服务提供方的操作。当获取了所需服务的位置(通常是服务提供方的地址)时，用户可以进一步访问和使用它。

一般，服务发现协议包括两个实体：(a)服务提供方——其在覆盖网络上提供服务，和(b)客户端——其使用所述服务。在一个方案中，服务提供方的示例包括节点，所述节点提供服务，例如打印、扫描、传真、存储、音乐共享、文件共享、游戏和网络服务，所述网络服务例如是预订电影票、旅馆、飞机票或在线游戏等。而且，在网络中的任何节点可以作为客户端。因此，服务发现的目标是帮助客户端找到感兴趣的特定服务(如果这样的服务存在的话)的服务提供方。

为了服务发现在对等覆盖网络中成功进行，服务提供方应当使用服务描述语言来指定其服务，关于服务的元数据应当以某种可搜索的形式被存储在覆盖网络中的节点上，并且客户端应当能够使用可搜索的关键字来表达服务请求，所述可搜索的关键字被传送到查询系统以帮助找到对应的服务。

但是，在现有技术中，因为使用不同的协议，所以产生了找到所有可用服务的问题。如上所述，通常经由服务描述语言来描述服务，并且这种语言既用于发布所述服务又用于在覆盖网络中发现服务。但是，存在数种服务描述语言，它们被标准化、广泛普及并且广泛部署来描述不同种类的服务。一些示例包括OWL-S、UDDI、UPnP、WSDL、XML、RDF等。这些语言的每种具有它们本身的普及领域，并且没有明显的优胜者。因此，当不同的服务使用不同的语言时，客户端仅能够识别使用与客户端的查询相同的语言描述的那些服务。在现有技术中，在发现协议和服务描述语言之间有松散的耦合。例如，UPnP使用其本身的服务描述语言，UDDI使用用于网络服务的WSDL，等等。因此，许多可用服务将无法被识别。

用于解决处理多种服务语言的问题的先前的尝试包括：使用转换器来将使用一种服务描述语言发布的服务描述转换为可以最终在覆盖网络中发布的另一种服务描述。但是，这样的手段是麻烦的，并且假设有N种不同的服务描述语言，其中N是正整数，则需要在每个节点中实现至少O(N)个转换器，其中O是某种函数。

因此，期望具有一种处理多种服务语言的方法，所述方法允许服务描述的高效发布和高效查询处理。

发明内容

下面阐述了一个或多个方案的简要概述，以提供对这些方案的基本理解。本概述并不是所有设想方案的详尽综述，并且既不意图标识所有方案的关键或重要要素，也不意图描绘任意或所有方案的范围。其唯一目的是以简化的形式阐述一个或多个方案的一些概念，作为后面阐述的更详细的说明书的序言。

根据一个方案，一种用于在网络中发布或发现服务的方法包括：接收服务的第一服务描述语言的原生服务描述以用于网络中的发布；从所述原生服务描述提取一个或多个关键字，其中，每个关键字对应于在所述网络上进行服务发现所需要的信息；从所述原生服务描述提取与所提取的一个或多个关键字中的每个对应的一个或多个附加信息；根据具有必需字段和与关键字一起发布的字段的规范化模式来生成可搜索的服务描述，其中，所述必需字段包括从所述原生服务描述提取的每个关键字，其中，所述与关键字一起发布的字段包括与每个所提取的关键字对应的所提取的附加信息；以及向所述网络发布覆盖网络可搜索的服务描述以通告所述服务。

另一方案涉及至少一个处理器，其被配置来在网络中发布或发现服务，所述至少一个处理器包括：第一模块，用于接收服务的第一服务描述语言的原生服务描述以用于网络中的发布；第二模块，用于从所述原生服务描述提取一个或多个关键字，其中，每个关键字对应于在所述网络上进行服务发现所需要的信息；第三模块，用于从所述原生服务描述提取与所提取的一个或多个关键字中的每个对应的一个或多个附加信息；第四模块，用于根据具有必需字段和与关键字一起发布的字段的规范化模式来生成可搜索的服务描述，其中，所述必需字段包括从所述原生服务描述提取的每个关键字，其中，所述与关键字一起发布的字段包括与每个所提取的关键字对应的所提取的附加信息；以及第五模块，用于向所述网络发布所述可搜索的服务描述以通告所述服务。

再一方案涉及一种计算机程序产品，其包括计算机可读介质，所述计算机可读介质包括：第一组代码，用于使计算机接收服务的第一服务描述语言的原生服务描述以用于网络中的发布；第二组代码，用于使所述计算机从所述原生服务描述提取一个或多个关键字，其中，每个关键字对应于在所述网络上进行服务发现所需要的信息；第三组代码，用于使所述计算机从所述原生服务描述提取与所提取的一个或多个关键字中的每个对应的一个或多个附加信息；第四组代码，用于使所述计算机根据具有必需字段和与关键字一起发布的字段的规范化模式来生成可搜索的服务描述，其中，所述必需字段包括从所述原生服务描述提取的每个关键字，其中，所述与关键字一起发布的字段包括与每个所提取的关键字对应的所提取的附加信息；以及第五组代码，用于使所述计算机向所述网络发布所述可搜索的服务描述以通告所述服务。

又一方案涉及一种装置，包括：用于接收服务的第一服务描述语言的原生服务描述以用于网络中的发布的单元；用于从所述原生服务描述提取一个或多个关键字的单元，其中，每个关键字对应于在所述网络上进行服务发现所需要的信息；用于从所述原生服务描述提取与所提取的一个或多个关键字中的每个对应的一个或多个附加信息的单元；用于根据具有必需字段和与关键字一起发布的字段的规范化模式来生成可搜索的服务描述的单元，其中，所述必需字段包括从所述原生服务描述提取的每个关键字，其中，所述与关键字一起发布的字段包括与每个所提取的关键字对应的所提取的附加信息；以及用于向所述网络发布所述可搜索的服务描述以通告所述服务的单元。

另一方案涉及一种用于在网络中发布服务的装置，包括：接收机，其被配置为接收服务的第一服务描述语言的原生服务描述以用于网络中的发布；可搜索模式插件组件，其被配置为：从所述原生服务描述提取一个或多个关键字，其中，每个关键字对应于在所述网络上进行服务发现所需要的信息；从所述原生服务描述提取与所提取的一个或多个关键字中的每个对应的一个或多个附加信息；以及根据具有必需字段和与关键字一起发布的字段的规范化模式来生成可搜索的服务描述，其中，所述必需字段包括从所述原生服务描述提取的每个关键字，并且其中，所述与关键字一起发布的字段包括与每个所提取的关键字对应的所提取的附加信息；以及发布处理组件，其被配置为向覆盖网络发布所述可搜索的服务描述以通告所述服务。

根据另一方案，一种用于处理网络搜索查询的方法包括：接收原生服务描述语言的原生服务查询；根据规范化模式来将所述原生服务查询转换为可搜索的查询；搜索网络以寻找由所述原生搜索查询识别的服务，所述搜索是根据所述规范化模式来执行的；以及将搜索结果从所述规范化模式转换为所述原生搜索描述语言。

为了实现前述以及相关目标，一个或多个方案包括在后文中完整描述并在权利要求中具体指出的特征。以下说明书和附图详细阐述了一个或多个方案的某些说明性的特征。然而，这些特征仅仅指示了可以采用各种方案的原理的各种方式中的少数几个，并且本说明书意图包括所有这些方案及其等同方案。

附图说明

下面结合附图来描述所公开的方案，这些附图被提供来说明而不是限制所公开的方案，其中，相似的标识表示相似的要素，并且其中：

图1是对等网络的方案的方框图；

图2是用于在网络中进行服务发布的系统的方案的示意图，其支持各种不同的服务描述语言；

图3是计算设备的方案的示意图，该计算设备被配置来在图1的网络或图2的系统中执行本文描述的功能；

图4是生成和发布可搜索的服务描述的方法的方案的流程图；

图5是用于处理对服务的查询的方法的方案的流程图；

图6是用于在网络中发布和发现服务的系统的方案的示意图；

图7是规范化模式的示例；以及

图8是规范化模式的另一示例。

具体实施方式

现在参照附图描述各种方案。在下面的描述中，出于解释的目的，阐述了许多特定细节以提供对一个或多个方案的透彻理解。然而，显而易见地，可以在没有这些特定细节的情况下实践这些方案。

例如对等网络的网络依赖于在计算机网络上发现设备和由那些设备提供的服务的能力。各种服务描述语言模式可以用于描述服务。在此描述的系统和方法提供了用于发布和发现服务的通用框架。可以与用于描述服务的服务描述语言无关地发布和发现服务。

参考图1，提供了对等覆盖网络100的方框图。网络100包括底层网络102，其包括任何类型的网络，例如网际协议网络。虽然底层网络102被示出为单个实体，但是底层网络可以包括任何数量或类型的网络，例如WAN、LAN、无线网络或任何其他类型的网络。虽然图1描绘了对等覆盖网络，但是本申请不限于覆盖网络。在此描述的系统和方法等同地适用于任何类型的网络，包括集中式网络。例如，网络100可以包括提供发现服务的服务器。在这种情况下，服务器可以作为容放与发现相关的信息的目录。例如，服务器可以容放由网络中的节点发布的关键字和对应信息。节点可以向服务器发布信息，并且查询也可以被发送给服务器。

在一个方案中，底层网络102包括多个对等网络(104、106和108)。对等网络104、106和108每个包括底层网络102的节点的子集，并且使用底层网络102的服务来工作以允许那些节点进行通信。例如，在对等网络104、106和108中，节点通过由底层网络102提供的通信链路进行连接，以形成期望的路由路径。对等网络104、106和108可以具有任何拓扑或架构，以实现任何路由配置，而不限于在图1中所示的配置。

在例如网络104、106和108的对等覆盖网络中，每个节点可以作为服务提供方和/或作为客户端。即，节点可以向覆盖网络提供服务，并且可以使用一个或多个其他节点的服务。这样的服务可以包括例如打印、扫描、传真、存储、音乐共享、文件共享、游戏和网络服务，该网络服务例如是预订电影票、旅馆、飞机票或在线游戏。但是，注意这些服务示例是非限定性的，并且实际服务可以包括比所列出的那些更多或更少的服务。每个节点可以包括计算设备，例如个人计算机、膝上型计算机、无线通信设备、移动电话、个人数字助理、打印机、传真机和/或任何其他网络可连接的计算设备。

服务发现协议可以用于帮助作为客户端的节点找到感兴趣的特定服务的服务提供方。服务提供方使用服务描述语言来指定其服务，该服务描述语言例如是可扩展标记语言(XML)、研究描述格式(Research DescriptionFormat)(RDF)、RDF-S、网络服务描述语言(WSDL)、WSDL-S、网络本体语言(OWL)、用于服务的网络本体语言(OWL-S)、通用描述发现和集成(UDDI)、通用即插即用(UPnP)和/或其他服务描述语言。关于服务的元数据以可搜索的格式存储在覆盖网络中的节点上，并且客户端可以使用可搜索的关键字来表达服务请求，该可搜索的关键字被传送到查询系统，以帮助找到对应的服务。

图2描绘了用于服务发布的示例性系统200，其支持各种不同的服务描述语言。系统200提供了用于在对等网络上通告和发现服务的通用框架。如图2中所示，可以使用任何服务描述语言/模式204来发布服务描述的数据202，该服务描述语言/模式204例如XML、XDS、RDF、RDF-S、WSDL、UDDI、UPnP、OWL、OWL-s等。一个或多个插件模块206可以被提供来基于规范化模式209将服务描述从其例如各个服务描述语言204的原生(native)形式转换为可搜索的服务描述208。然后可以在覆盖网络210上发布可搜索的服务描述208。

可搜索的服务描述208使得能够聚合服务发现所需要的所有信息以及对服务进行排序(rank-order)和访问所需要的信息。发布可搜索的服务描述208可以包括从原生服务描述提取关键字。例如，关键字可以提取为XML属性-值对、RDF三元组、简单关键字，或根据任何其他提取方法来提取。插件模块206提供了规范化模式209，该规范化模式209定义了要提取的特定字段和用于提取字段的格式。该规范化模式209不是服务描述语言，因为其不提供服务描述语言的所有功能。和转换器的使用不同，插件模块206不是从一种服务描述语言转换为一种或多种其他服务描述语言。相反，插件模块206便利基于规范化模式209从原始服务描述提取特定数据。例如，由规范化模式209指定的字段被映射到原生服务描述语言204的特定数据。因此，在覆盖网络上发布根据规范化模式209提取的信息。这样，不是在网络上发布多个版本的服务描述(其中每个版本使用不同的服务描述语言)，而是可以向网络发布可以被任何节点搜索和识别的单个描述。

图3描绘了可以作为对等和/或覆盖网络中的节点的示例性计算设备300。计算设备300包括处理器302，用于执行与一个或多个组件相关联的处理功能和本文描述的功能。处理器302可以包括单组或多组处理器或多核处理器。而且，处理器302可以被实现为集成处理系统和/或分布式处理系统。

计算设备300还包括存储器304，例如用于存储被处理器302执行的应用的本地版本。存储器304可以包括可由计算机使用的任何类型的存储器，例如随机存取存储器(RAM)、只读存储器(ROM)、带、磁盘、光盘、易失性存储器、非易失性存储器及其任何组合。

而且，计算设备300包括通信组件306，其使用在此描述的硬件、软件和服务来建立和维护与一方或多方的通信。通信组件306可以承载在计算设备300上的组件之间以及在计算设备300和外部设备(诸如位于通信网络上的设备和/或串行或者本地连接到计算设备300的设备)之间的通信。例如，通信组件306可以包括一个或多个总线，并且还可以包括分别与发射机和接收机相关联的发射链组件和接收链组件，可操作来与外部设备通过接口连接。而且，例如，通信组件306可以被配置来使得计算设备300能够与覆盖网络中的其他节点进行通信。

另外，计算设备300还可以包括数据存储设备308，其可以是硬件和/或软件的任何适合组合，其提供结合在此描述的方案所采用的信息、数据库和程序的大容量存储。例如，数据存储设备308可以是处理器302当前未执行的应用的数据储存库。

计算设备300还可以包括用户接口组件310，其可操作来从计算设备300的用户接收输入，并且还可操作来生成要向用户呈现的输出。用户接口组件310可以包括一个或多个输入设备，其中包括但是不限于键盘、数字键盘、鼠标、触敏显示器、导航键、功能键、麦克风、语音识别组件、能够从用户接收输入的任何其他机构，或者它们的任意组合。而且，用户接口组件310可以包括一个或多个输出设备，其中包括但是不限于显示器、扬声器、触觉反馈机构、打印机、能够向用户呈现输出的任何其他机构，或者它们的任何组合。

在一个方案中，计算设备300还可以包括一个或多个可搜索模式插件模块206。例如，该一个或多个插件模块206可以被存储在存储器304中。每个模式插件模块206可以被配置来基于规范化模式209从以任何服务描述语言204编写的服务描述来生成可搜索的服务描述208(图2)。可搜索的服务描述208被发布到网络，并且用于处理对于服务的查询。生成可搜索的服务描述208包括从其原生形式的服务描述提取关键字，然后在网络上以可搜索的服务描述208的格式来通告这些关键字。

计算设备300还可以包括发布处理模块312，其便利发布可搜索的服务描述208(图2)。另外，查询处理模块314可以被包括来用于处理对网络的查询。当接收到原生服务描述语言的查询时，查询处理模块314可以被配置来基于规范化模式209转换所述查询。由此，可以执行网络的搜索。在已经获得了搜索结果后，查询处理模块314可以被配置来将结果转换回原始查询的原生服务描述语言，并且将结果转发到请求者。

图4是描绘用于生成和发布可搜索的服务描述的示例性方法的流程图。如所描绘的，在402，处理从接收以原生服务描述语言编写的服务描述开始，该原生服务描述语言例如是XML、RDF、WSDL、OWL和/或任何其他服务描述语言。在图2和3中描绘的插件模块206可以接收该原生语言的服务描述。

如所描绘的，在404，可以从服务描述提取一个或多个关键字。另外，还提取要与关键字一起发布的其他识别信息。关键字可以对应于例如服务名称、服务描述语言等。如所描绘的，在406，基于规范化模式，使用所提取的关键字和其他识别信息来创建可搜索的服务描述。可搜索的服务描述可以包括字段，例如但是不限于必需字段、可选字段和“与关键字一起发布的”(publish with keywords)字段。规范化模式包括每个字段中的属性，所述属性可以从服务描述语言文件中的多个属性中选择。不同的服务描述语言可以具有针对特定属性的不同命名规范。规范化模式定义了每个属性的标准属性名称。当提取关键字和生成可搜索的服务描述时，原生属性值与适当的标准属性名称相关联。

必需字段包括来自原生服务描述的必须在网络上发布以用于服务发现的所有信息。必需信息的示例包括但是不限于例如与服务描述相关联的服务名称、关于服务使用的服务描述语言的信息等。如果通过多种语言描述了服务，则必需字段可以包括不止一种的服务描述语言。另外，必需字段中可以包括其他信息，例如用于便利服务发现的文本描述和/或关键字、用于联系服务的信息，和/或与服务相关并且未被其他字段描述的可能关键字的列表。

可选字段包括可以被发布来用于服务发现的所有信息。本字段呈现了用于便利高级搜索和发现的附加信息，并且可以不包含已经在必需字段中的字段。可选字段中的示例实体可以包括例如关于服务获得的输入的可能类型的信息、关于服务产生的输出的可能类型的信息、根据模式限定的服务的前提和前提实例上的范围、关于服务的特定结果和在什么条件下生成该输出的信息、关于发布者的信息、与服务相关并且未被其他字段描述的可能关键字的列表和/或其他信息。

“与关键字一起发布”的字段包括需要与从必需和可选字段提取的关键字一起发布的信息。“与关键字一起发布”的字段可以包括例如特定关键字特有并且仅与该所选择的关键字一起被存储的信息、与从服务描述提取的所有关键字一起存储的关于正在描述的服务的信息和/或其他信息。例如，特定关键字特有的信息可以包括特定关键字在服务描述的文档中出现的次数。这个信息对于基于相关性的搜索而言可能是有用的，其中，基于词频值来对查询结果进行排序。

再次参见图4，如所描绘的，在408，可以向网络发布基于规范化模式而创建的可搜索的服务描述。然后，由可搜索的服务描述所描述的服务可以被发出以任何服务描述语言格式化的搜索查询的节点发现。

图5是描绘用于处理对于服务的查询的示例性方法的流程图。如所描绘的，在502，该处理当接收到原生搜索描述语言的查询时开始。如所描绘的，在504，然后基于规范化模式将查询转换为服务查询。如所描绘的，在506，可以执行对网络的搜索以寻找匹配服务查询的服务。如本文所描述的，网络存储已经基于规范化模式而格式化的服务描述。如所描绘的，在508，接收搜索查询的结果。该结果也根据规范化模式被格式化。如所描绘的，在510，将该结果转换为对应的原生搜索查询的原始或原生服务描述语言。

转向图6，其说明了用于在网络中发布和发现服务的系统600。如所描绘的，系统600包括可以表示由处理器、软件或其组合(例如固件)实现的功能的功能块。系统600包括协同操作的电气组件的逻辑组602。例如，可以通过作为对等网络中的节点的计算设备来实现系统600。

逻辑组602可以包括用于接收服务的第一服务描述语言的原生服务描述以用于网络中的发布的模块604。而且，逻辑组602可以包括用于从原生服务描述提取一个或多个关键字的模块606，其中，每个关键字对应于网络上进行服务发现所需要的信息。逻辑组602还可以包括：用于从原生服务描述提取与一个或多个提取的关键字的每个对应的一个或多个附加信息的模块608；用于根据具有必需字段和与关键字一起发布的字段的规范化模式来生成可搜索的服务描述的模块610，其中，必需字段包括从原生服务描述提取的每个关键字，其中，与关键字一起发布的字段包括与每个提取的关键字对应的所提取的附加信息；以及用于向网络发布可搜索的服务描述以通告服务的模块612。另外，系统600可以包括存储器618，其保存用于执行与电气组件604-612相关联的功能的指令。虽然被示出为在存储器618外部，但是应当明白，电气组件604-612可以位于存储器618内。

规范化模式209(图2)的一个示例是从Qualcomm公司可获得的Genie可搜索模式。与规范化模式209一样，Genie可搜索模式(GSS或Genie)不是服务描述语言。其不提供服务描述语言的所有功能，并且也不必被理解为一种服务描述语言。GSS仅提供用于聚合服务发现所需要的所有信息和对服务进行排序与访问所需要的信息的机制。在Genie中，我们假定使用其原生服务描述来描述服务；这可以是OWL-S、WSDL、UPnP或任何其他已知或仍待发现的模式。在覆盖网络上发布这个信息包含两个步骤。第一步骤是从描述提取关键字。每个提取的关键字可以是三种类型之一，即简单关键字、XML属性-值对和RDF三元组。下一步骤是在覆盖网络上通告这些关键字。这可以使用PUT命令来进行。PUT命令具有作为输入的ResourceName(资源名称)、AuthName(认证名称)、KindID(类型ID)、Name(名称)、Value(值)和LifeTime(生存期)。注意，PUT命令支持用于三种类型的关键字的三种不同的kindID，即KEYWORD、XML_KEYWORD和RDF_KEYWORD。

因此，GSS用作服务发布中的中间步骤。其包含连同附加边信息(sideinformation)列表一起从原始服务描述提取的关键字列表，该附加边信息可以与这些关键字一起被发布。GSS是步骤1的最后产物，并且向可以包括Genie中间件的节点提供关于可以发布服务描述的什么部分和可以在覆盖网络中存储什么部分的某些信息。GSS本身未在覆盖网络中的任何节点中被存储为一个文档。

GSS包含三个基本字段：

1.必需字段：包含原生服务描述中必须在覆盖网络中发布的所有字段。

2.可选字段：包含原生服务描述中可选并且可以被发布来用于服务发现的所有信息。

3.publishWithKeywords(与关键字一起发布的字段)：这个字段包含需要与从原生服务描述提取的每个关键字一起发布的所有信息。

图7描绘了GSS 700的一个示例。必需字段702包含需要在覆盖网络上发布以用于服务发现的所有信息。必需字段702可以包含下面列出的以下实体。任何GSS 700的必需字段702都包含servicename(服务名称)和servicedescriptionlanguage(服务描述语言)，并且在必需字段702中的剩余字段可选地包括在GSS 700中。表1描绘了在必需字段中的条目的示例。

表1

字段servicedescriptionlanguage包含关于服务使用的服务描述语言的信息。必需字段必须包含至少一个servicedescriptionlanguage字段。如果用多种语言描述了服务，则必需字段可以包括不止一个servicedescriptionlanguage字段。在这个字段中的值需要被标准化，以允许节点/应用搜索由特定语言描述的服务。可能的选择包括：

●针对网络服务描述语言的WSDL；

●针对OWL-S的OWLS；

●针对OWL的OWL；

●针对通用描述、发现和集成的UDDI；

●针对通用即插即用的UPnP；等等。

字段searchKeywords具有与服务相关的可能关键字的列表。可以从原生服务描述提取这个信息，或可以简单地由服务、应用或节点当其发布服务时添加这个信息。在searchKeywords字段中的信息可以是简单关键字、XML属性-值对或RDF三元组。如果外部模块(经由服务或应用等)添加关键字，则其被放入如图7中所示的字段userDefinedKeyword(用户定义的关键字)内。

可选字段704包含可以被发布来用于服务发现的所有信息。可选字段704呈现用于便利高级搜索和发现的附加信息，并且可以不包含已经在必需字段中的字段。在可选字段中的所有实体实际上是可选的，并且可以包含在表2中描绘的以下条目。

表2

字段servicePublisher可以具有附加的子字段，即：servicePublisherName(服务发布者名称)，其包含：发布者的名称；textDescription(文本描述)，其包含关于发布者的文本描述和/或关键字(如果希望用户使用附加的关键字搜索，则服务通告可以添加这些附加的关键字)；以及contactInformation(联系信息)，其包含关于用于联系服务的方式的信息。

字段searchKeywords具有与服务相关并且未在必需字段中直接涵盖的可能关键字的列表。可以从原生服务描述提取这个信息，或可以简单地由服务、应用或节点当其发布服务时添加这个信息。在searchKeywords字段中的信息可以是简单关键字、XML属性-值对或RDF三元组。可能的示例包括OWL-S模式中的serviceParameter(服务参数)和serviceCategory(服务类别)字段。字段serviceParameter具有可以伴随OWL-S中的简档描述的可扩展的性质列表。其可以具有附加的子字段，即serviceParameterName(服务参数名称)(实际参数的名称)和sParameter(指向参数的值)。serviceCategory基于可能在OWL-S之外并且可能在OWL[OWL-S]之外的某种分类来描述服务的类别。其包含下面的字段：(a)categoryName(类别名称)：是实际类别的名称，(b)taxonomy(分类法)：存储分类方案的引用，(c)value(值)：指向特定分类法中的值，以及(d)code(码)：存储与用于每种类型服务的分类法相关联的码。serviceParameter和serviceCategory字段存在于OWL-S 1.1版的主要简档描述中，并且在从1.2版开始的更近版本中已经被弃用在Profile.owl外部。在这些版本中，可以分别在独立的文件ServiceParameter.owl和ServiceCategory.owl中找到这些字段。

根据在覆盖网络中发布的信息量，可以或可以不发布可选字段及其子字段。因此，必需字段和可选字段为覆盖网络提供了决定在覆盖网络中必须和可以发布什么来用于服务发现的方式。

publishWithKeyword字段706包含需要与从必需字段和可选字段提取的关键字一起发布的信息。publishWithKeyword字段706主要包括两种信息，即：keywordSpecificInfo(关键字特有信息)，其包含特定关键字特有的信息，并且仅与所选择的关键字一起被存储；以及serviceSpecificInfo(服务特有信息)，其包含关于正在被描述的服务的信息。与keywordSpecificInfo不同，serviceSpecificInfo是服务的性质，并且与从服务描述提取的所有关键字一起被存储。keywordSpecificInfo的示例是numberOfOccurrences(出现数)，其是特定关键字在文档或服务描述中出现的次数。这个信息对于基于相关性的搜索而言可能是有用的，其中，基于词频值来进行查询结果的排序。

serviceSpecificInfo的一些示例是serviceReputation(服务声誉)和contactInformation。serviceReputation指定服务的声誉。这个信息可以在搜索处理结束时呈现给用户，以帮助用户在不同的搜索结果中进行选择。这个声誉分数也可以用于对搜索结果进行排序。serviceReputation是在publishWithKeyword内的可选字段。与serviceReputation相反，contactInformation字段在publishWithKeyword中是强制的，并且必须与从必需字段和可选字段提取的每个关键字一起被发布。其必须包含至少一个条目，该至少一个条目可以在下述部分之中：overlayURI(覆盖网络URI)：覆盖网络中的服务描述文档的URI指针；weburi：作为服务或服务描述的指针的URL或URI(这可以不是覆盖网络特有指针)；contactNode(联系节点)：关于提供服务的节点的信息，例如节点标识符或节点ID(contactNode字段可以包含附加信息，例如节点的声誉评分和节点的location(位置)，以便利结果的范围界定和排序)；或contactPerson(联系人)：负责服务的人员的姓名和联系信息。在publishWithKeyword中包含的信息可以用于所获取的结果的排序和范围界定，并且与在关键字PUT命令的DocumentPointer(文档指针)和OtherInfo(其他信息)字段中的关键字一起被发布。

一种流行的服务描述语言是OWL-S。OWL-S提供了服务的上层本体。使用服务类来描述服务。类Service提供了对所声明的网络服务的组织引用点。Service的每个实例将呈现由ServiceModel(服务模型)描述的ServiceProfile(服务简档)描述，并且支持ServiceGrounding描述。ServiceProfile提供了代理发现服务所需要的信息，而一起获得的ServiceModel和ServiceGrounding为代理提供了足够信息来在找到服务后使用服务。服务简档以适合于服务寻找代理的方式来告知“服务会做什么”，以确定服务是否满足其需要。这种表示形式可以包括服务实现了什么的描述、服务适用性和服务质量上的限制，以及服务请求者要成功地使用服务必须满足的要求。在OWL-S中的ServiceProfile类提供了发现服务所需要的所有信息，因此这个信息对于发布而言是足够的。

如上所述的GSS 700封装和提供了对OWL-S中的ServiceProfile类的包装。因为GSS 700基于ServiceProfile，因此将OWL-S性质映射到GSS字段是直接的，如表3中所示。

表3

现在将讨论GSS 700应用于一些特定服务描述语言的示例。

在附录A中提供了示例性OWL-S服务描述，并且在附录B中提供了其向Genie可搜索模式700的转换。注意，在附录A中的示例中，在服务描述中有某些字段，例如“actor”，其结构和子字段未在OWL-S模式中直接地定义，而是在独立的文件http://www.daml.org/services/owl-s/1.0/ActorDefault.owl中定义并且使用命令<！ENTITY actor″http://www.daml.org/services/owl-s/1.0/ActorDefault.owl″>来指示。这样的条目未在GSS模式700中直接地定义，并且可以包括在searchKeywords字段中。

另一种流行的服务描述语言是WSDL。WSDL在两个基本阶段内描述网络服务：一个是抽象阶段，一个是具体阶段。在每个阶段内，该描述使用多个构造来促进描述的可重用性，并且分离独立的设计关注点。存在WSDL的两种流行版本，即WSDL 1.1和WSDL 2.0。在抽象级，WSDL就网络服务发送和接收的消息来描述网络服务；使用类型系统(通常是XML模式)来描述消息，而与特定的有线格式(wire format)无关。操作将消息交换样式与一个或多个消息相关联。消息交换样式识别所发送和/或接收的消息的序列和基数，以及在逻辑上它们被发送到谁和/从谁接收它们。接口将操作编组在一起，而没有对于传送或有线格式的任何约束。在具体级，绑定指定了用于一个或多个接口的传送和有线格式细节。端点将网络地址与绑定相关联。最后，服务将实现公共接口的端点编组在一起。

在WSDL的两个版本之间存在数个关键差别。这些差别包括：向描述语言添加另外的语义；对一些消息构造重命名，例如将portType(端口类型)改变为接口，将端口改变为端点等；以及移除/弃用在2.0版中使用XML模式类型系统指定的一些消息构造。除了在两个版本之间的这些关键差别之外，存在从WSDL 1.1到WSDL 2.0的一对一映射，并且已经存在数种转化器，来帮助用户将现有的WSDL 1.1文档改变为2.0版文件。在一个方案中，GSS 700提供了一种机制，用于将WSDL 2.0服务描述转换为GSS 700，而将WSDL 1.1到WSDL 2.0的转换留给所述转化器来进行。

与OWL-S的情况不同，WSDL没有ServiceProfile，并且需要从整个服务描述收集发现服务所需要的信息。在表4中，提供了细节以示出GSS字段和WSDL 2.0服务描述中可以从中提取这些GSS字段的部分。可以在该表格中看出，可以从WSDL服务的性质获得GSS 700中的一些字段，例如servicename和textdescription，并且可以从WSDL接口组件的性质导出一些其他的GSS字段，例如hasInput和hasOutput。

表4

在附录C中示出了WSDL 1.1服务描述的示例，并且分别在附录D和附录E中示出了其对应的WSDL 2.0和Genie可搜索模式700。

通用描述、发现和集成(UDDI)协议是包括网络服务栈的相关标准组的中心要素。UDDI规范定义了一种用于发布和发现面向服务的架构的基于网络的软件组件的标准方法。其发展由企业软件商和客户的OASIS协会所引领。

UDDI注册中心的功能用途是表示关于网络服务的数据和元数据。用于公共网络上或用于组织的内部基础设施内的注册中心提供了基于标准的机制，用于对网络服务进行分类、编目录和管理，以便其他应用可以发现和使用这些网络服务。作为在基于服务的应用中的间接的一般化策略的一部分，UDDI在设计时间和运行时间两者上向IT管理者提供了数种益处，包括提高代码重用和改善基础设施管理。

在数种XML模式中定义了由UDDI注册中心使用的核心信息模型。选择XML是因为其提供了数据的平台无关表示，并且允许以自然的方式来描述分层关系。选择XSD是因为其支持丰富的数据类型，并且其能够容易地基于在模式中表示的信息模型来描述和验证信息。UDDI XSD形成了UDDI注册中心的基本信息模型和交互框架。信息模型的主要组件包括：服务的商业功能的描述(称为businessService)；关于发布了服务的组织的信息(businessEntity)；服务的技术细节(bindingTemplate)，包括对于服务的编程接口或API的引用；以及各种其他属性或元数据，例如在tModels中定义的分类法、传送、数字签名等。在表5中，提供了细节以示出GSS字段和UDDI服务描述中可以从中提取这些GSS字段的部分。

表5

从短语“Universal Plug and Play(通用即插即用)”得出的UPnP是一组联网协议，其旨在为家庭和公司环境中的设备提供简单的对等联网。其通过基于开放的、基于因特网的标准(例如TCP/IP、HTTP、XML和SOAP)来定义协议而实现这个目的。UPnP协议定义了对等联网的几乎所有方面，包括用于寻址、服务发现、服务描述和对服务交换、事件通知与呈现进行控制的过程。

UPnP定义了两个功能实体类：Device(设备)，其提供服务；Controlpoint(控制点)，用户通过其可以控制由设备提供的服务。被称为简单服务发现协议(SSDP)的UPnP的服务发现协议使得新的设备可以将自己通告给其网络中的控制点。类似地，在控制点加入网络时，其使用SSDP来搜索网络中的感兴趣的设备。在控制点发现服务后，其从其在服务发现期间已经获得的URL获取服务的详尽描述(用XML表达)。这个服务描述文件包含嵌入的服务的列表，以及关于控制、事件通知和呈现的信息的URL。

在UPnP的情况下，当设备被添加到网络时或当它们更新其通告时，这些设备将NOTIFY(通知)消息进行多播(或单播)。该NOTIFY消息使用：

●由通用事件通知架构(GENA)定义的NOTIFY动词

●由IANA在HOST头部中为SSDP保留的多播地址和端口

●在CACHE-CONTROL头部中的通告持续时间

●LOCATION头部中的发现位置

●在NT(通知类型)头部中的通告的特定类型

●在NTS(通知子类型)头部中的子类型

○ssdp:alive，用于通告(参见附录F中的示例)

○ssdp:update，用于更新(参见附录G中的示例)

○ssdp:byebye，用于取消通告(参见附录H中的示例)

●在USN(唯一序列号)头部中该通告的唯一ID

以下面的格式给出NOTIFY消息：

NOTIFY*HTTP/1.1

HOST：(HostAddress):(ServicePort)

CACHE-CONTROL：max-age＝LifeTime

LOCATION：对根设备的UPnP描述的URL

NT：搜索目标

NTS：ssdp:alive

USN：唯一序列号

其中

NOTIFY指示这个消息是服务通告，

HOST提供所通告的服务的IP地址和端口号；设备通常将239.255.255.250：1900用于NOTIFY消息，

CACHE-CONTROL设置以秒为单位的所通告的服务的生存期，

LOCATION指定对根设备的UPnP描述的URL，

NT指定所通告的服务的搜索目标，

NTS指示SSDP的当前状态，

USN是唯一标识该通告的UUID

注意，与其他类型的服务描述语言不同，UPnP不将任何服务名称定义为NOTIFY消息的一部分。但是，NOTIFY消息在LOCATION字段中包含UPnP描述的URL，并且这个文档包含关于服务的附加信息，包括设备提供的服务的名称。

NOTIFY消息包含UPnP描述的URL。当节点发布服务时，其还需要从来自NOTIFY消息的LOCATION字段的UPnP描述提取信息，并且将其在覆盖网络上发布。用XML指定该信息。该描述分为两个部分：一部分针对该设备，一部分按照由设备提供的嵌套服务(nested service)。设备描述包含：设备的类型、容器性质和由设备指定的用户接口(UI)信息。设备描述是XML格式。服务是设备中的功能单元，并且被包含在容器中。服务描述文件包含方法和状态变量(或性质)，并且类似于在OWL-S或WSDL文件中包含的内容。

在附录I中给出了用于描述服务的示例性XML文件。在UPnP的情况下，设备需要发布两组信息。第一组信息导出自NOTIFY消息，并且包含关于服务描述的位置的信息和NT/ST值，它们是回答UPnP M-SEARCH查询所需要的信息。要发布的第二组信息来自设备/服务描述文件。为了使用GSS格式发布NOTIFY消息中的信息，发布节点应当创建图8中描绘的GSS800。

NOTIFY消息用于在覆盖网络中通告、更新和删除设备。下一步骤是发布设备/服务描述文件。附录I提供了以XML编写的UPnP设备描述文件的示例，并且在附录J中示出了对应的GSS。可以在其中看出，该设备描述文件包含关于设备、模型、模型名称、制造商和模型URI的信息。除了该信息之外，设备描述文件包含放入<service></service>字段中关于设备提供的服务的信息。这个字段包含关于服务的另外的信息，其中包括服务描述文件的URI。作为发布处理的一部分，服务提供对等方也需要提取这个信息，并且以GSS的形式在覆盖网络上将其发布。

可能有两种不同的模式(或甚至同一模式的两个不同版本(例如在这个示例中的WSDL))以不同的方式描述同一文档/查询，而它们指的是同一事物。例如，可以使用具有servicename＝“myprinter”的模式1来在覆盖网络中通告打印机服务(称为服务1)，并且可以使用模式2来发出搜索请求，以找到具有属性printemame＝“myprinter”的所有服务描述。简单搜索系统不返回服务1，因为它具有不同的与值“myprinter”相关联的属性，这是由于在描述服务和编制查询中使用的模式不同。在OWL-S和WSDL的情况下的另一个示例是这些模式分别使用不同的属性名称，例如textDescription和documentation，来指代通用字段。一种处理这样的情境的方式是具有一种简化的一般模式，并且使所有的服务和查询遵从这个模式。但是，这样的解决方案太受限，并且可能无法应对新的和仍待定义的语言的要求。

GSS 700采取简单的手段来处理这个问题。GSS 700针对通用属性定义了标准属性名称的列表，例如如上所述的servicename、textdescription、hasInput、hasOutput等。对于这些属性，GSS 700从原生服务描述模式提取对应值，并且将它们在覆盖网络中与标准属性名称一起发布。对于未在列表中专门定义的其他属性，GSS 700直接地发布在原生模式中定义的属性名称。上文定义的插件206(图2)帮助该发布处理，并且将原生属性名称转换为标准属性名称。

查询遵从与发布相同的步骤。给定关于原生属性名称的查询，插件206检查标准属性的列表，并且如果存在，则将原生属性名称转换为标准属性名称。使用具有标准属性名称的SEARCH(搜索)命令来将该查询发送到覆盖网络。在如上所述的打印机服务的示例中，对于形式为“printemame＝myprinter”的查询，该插件将该查询转换为“servicename＝myprinter”，并且在覆盖网络上发送修改后的查询。搜索的输出现在将包含服务1，因为它具有相同的与“myprinter”相关联的属性。

因此，规范化覆盖网络模式209的一个示例包括上述的GSS 700，但是应当明白，可以开发包含规范化覆盖网络模式209的上述功能的其他特定模式。

如本申请中所使用的，术语“组件”、“模块”、“系统”等意图包括计算机相关的实体，例如但不限于，硬件、固件、硬件和软件的组合、软件或执行中的软件。例如，组件可以是、但不限于：处理器上运行的进程、处理器、目标程序(object)、可执行程序(executable)、执行线程、程序和/或计算机。作为举例说明，计算设备上运行的应用程序和计算设备都可以是组件。一个或多个组件可以驻留在程序和/或执行线程内，并且组件可以位于一个计算机上，和/或被分布在两个或更多计算机之间。此外，可以从其上存储有各种数据结构的各种计算机可读介质执行这些组件。这些组件可以例如根据具有一个或多个数据分组的信号通过本地和/或远程处理的方式进行通信，例如，通过该信号，来自一个组件的数据与本地系统、分布式系统中的另一组件进行交互，和/或跨越诸如因特网这样的网络与其它系统进行交互。

此外，本文中结合终端描述了各种方案，所述终端可以是有线终端或无线终端。终端也可以被称为系统、设备、用户单元、用户站、移动站、移动装置、移动设备、远程站、远程终端、接入终端、用户终端、终端、通信设备、用户代理、用户装置、或用户设备(UE)。无线终端可以是蜂窝电话、卫星电话、无绳电话、会话发起协议(SIP)电话、无线本地环路(WLL)站、个人数字助理(PDA)、具有无线连接能力的手持设备、计算设备、或连接到无线调制解调器的其它处理设备。此外，本文中结合基站描述了各种方案。基站可以用来与无线终端进行通信，并且也可以被称为接入点、节点B或者一些其它术语。

此外，术语“或”意思是包含性的“或”而非排他性的“或”。即，除非另外指明或者可以从上下文清楚看出，否则短语“X采用A或B”意思是自然包含的排列(permutation)中的任意一个。即，以下实例中的任意一个都满足短语“X采用A或B”：X采用A；X采用B；或X采用A和B。此外，除非另外指明或者可以从上下文清楚看出指的是单数形式，否则本申请和所附权利要求中所使用的冠词“一个”应该被一般地解释成表示“一个或多个”。

本文描述的技术可以用于各种无线通信系统，例如，CDMA、TDMA、FDMA、OFDMA、SC-FDMA以及其它系统。术语“系统”和“网络”通常可互换使用。CDMA系统可以实现诸如通用陆地无线接入(UTRA)、cdma2000等的无线电技术。UTRA包括宽带CDMA(W-CDMA)和CDMA的其它变体。此外，cdma2000涵盖了IS-2000、IS-95和IS-856标准。TDMA系统可以实现诸如全球移动通信系统(GSM)这样的无线电技术。OFDMA系统可以实现诸如演进型UTRA(E-UTRA)、超移动宽带(UMB)、IEEE802.11(Wi-Fi)、IEEE 802.16(WiMAX)、IEEE 802.20、Flash-OFDM等的无线电技术。UTRA和E-UTRA是通用移动电信系统(UMTS)的部分。3GPP长期演进(LTE)是使用E-UTRA的UMTS版本，该版本在下行链路上采用OFDMA，在上行链路上采用SC-FDMA。在来自名为“第三代合作伙伴计划”(3GPP)的组织的文献中描述了UTRA、E-UTRA、UMTS、LTE以及GSM。另外，在来自名为“第三代合作伙伴计划2”(3GPP2)的组织的文献中描述了cdma2000和UMB。此外，这些无线通信系统还可以包括对等(例如，移动设备对移动设备)的ad hoc网络系统，后者通常使用不成对的非授权频谱、802.xx无线LAN、蓝牙以及任何其它短距离或长距离无线通信技术。

各种方案或特征将根据可以包括多个设备、组件、模块等的系统来加以阐明。应该理解并意识到，各种系统可以包括附加的设备、组件、模块等，和/或可以不包括结合附图所讨论的所有设备、组件、模块等。也可以使用这些方式的组合。

结合本文公开的方案所描述的各种说明性的逻辑、逻辑块、模块以及电路可以用被设计为执行本文所描述的功能的通用处理器、数字信号处理器(DSP)、专用集成电路(ASIC)、现场可编程门阵列(FPGA)或其它可编程逻辑器件、分立的门或晶体管逻辑、分立的硬件组件、或者其任意组合来实现或执行。通用处理器可以是微处理器，但是可替代地，处理器可以是任何常规的处理器、控制器、微控制器或状态机。处理器还可以实现为计算设备的组合，例如，DSP和微处理器的组合、多个微处理器、与DSP核心协同工作的一个或多个微处理器，或者任何其它这样的配置。此外，至少一个处理器可以包括一个或多个用于执行上面描述的一个或多个步骤和/或操作的模块。

此外，结合本文公开的方案所描述的方法或算法的步骤和/或操作可以用硬件、处理器执行的软件模块，或者两者的组合来直接实施。软件模块可以驻留在RAM存储器、闪存、ROM存储器、EPROM存储器、EEPROM存储器、寄存器、硬盘、可移动盘、CD-ROM或本领域已知的任何其他形式的存储介质中。示例性存储介质可以被耦合到处理器，从而处理器可以从该存储介质读取信息，并将信息写入其中。可替换地，存储介质可以集成到处理器中。此外，在一些方案中，处理器和存储介质可以位于ASIC中。另外，ASIC可以位于用户终端中。可替换地，处理器和存储介质可以作为分立组件而位于用户终端中。另外，在一些方案中，方法或算法的步骤和/或操作可以作为代码和/或指令中的一个或者任意组合或集合而位于机器可读介质和/或计算机可读介质上，所述介质可以被包括在计算机程序产品中。

在一个或多个实例中，所描述的功能可以用硬件、软件、固件或它们的任意组合来实现。如果用软件实现，则这些功能可以作为一个或多个指令或代码在计算机可读介质上存储或传输。计算机可读介质包括计算机存储介质和通信介质，通信介质包括便于计算机程序从一个位置到另一个位置的传送的任何介质。存储介质可以是计算机可以访问的任何可用介质。作为实例而非限制，这种计算机可读介质可以包括RAM、ROM、EEPROM、CD-ROM或者其它光盘存储、磁盘存储或其它磁存储设备，或者可以用来携带或存储指令或数据结构形式的期望的程序代码并且可以被计算机访问的任何其它介质。此外，任意连接都可能称作计算机可读介质。例如，如果使用同轴电缆、光缆、双绞线、数字用户线路(DSL)或无线技术(例如，红外、无线电和微波)从网站、服务器或其它远程源发送软件，那么这些同轴电缆、光缆、双绞线、DSL或无线技术(例如，红外、无线电和微波)被包括在介质的定义中。如这里所使用的，磁盘(disk)和光盘(disc)包括致密盘(CD)、激光盘、光盘、数字通用盘(DVD)、软盘以及蓝光盘，其中，磁盘(disk)通常磁性地复制数据，而光盘(disc)通常用激光来光学地复制数据。上述的组合也应该被包括在计算机可读介质的范围内。

尽管前面的公开讨论了说明性的方案和/或实施例，但是应该注意到，可以在不偏离所附权利要求所定义的所述方案和/或实施例的范围的情况下，作出各种改变和修改。此外，尽管所描述的方案和/或实施例的部件可能被描述或要求为单数形式，但是除非明确声明限制为单数形式，否则可以设想为复数形式。另外，除非另外声明，否则任何方案和/或实施例的全部或部分都可以与任何其它方案和/或实施例的全部或部分一起使用。

附录A

用于Bravo空中服务的OWL-S模式

附录B

用于Bravo空中服务的Genie可搜索模式

附录C

用于库存配额服务的WSDL 1.1模式

附录D

将库存配额服务的WSDL 1.1模式转换为WSDL 2.0

来自[WSDL示例]的示例

附录E

用于库存配额服务的GSS模式

附录F

使用NOTIFY来发布UPnP设备

下面指定用于发布UPnP服务的UPnP命令

NOTIFY*HTTP/1.1

HOST：(HostAddress):(ServicePort)

CACHE-CONTROL：max-age＝LifeTime

LOCATION：对根设备的UPnP描述的URL

NT：搜索目标

NTS：ssdp:alive

USN：唯一序列号

用GSS来表示这个信息如下：

一旦这个信息被转换为GSS，发布节点需要根据LOCATION(位置)字段下载XML设备/服务描述文件，并且将其在覆盖网络上独立地发布。

附录G

使用NOTIFY更新UPnP设备

下面指定用于更新UPnP服务的UPnP命令

NOTIFY *HTTP/1.1

HOST：(HostAddress):(ServicePort)

CACHE-CONTROL：max-age＝LifeTime

LOCATION：对根设备的UPnP描述的URL

NT：搜索目标

NTS：ssdp:update

USN：唯一序列号

与如何发布服务类似地，用GSS来表示这个信息如下：

一旦这个信息被转换为GSS，发布节点还需要根据LOCATION(位置)字段下载XML设备/服务描述文件，并且将其再一次在覆盖网络上发布，以保证覆盖网络具有更新的信息。

附录H

使用NOTIFY来删除UPnP设备

下面指定用于删除UPnP服务的UPnP命令

NOTIFY *HTTP/11

HOST：(HostAddress):(ServicePort)

NT：搜索目标

NTS：ssdp:byebye

USN：唯一序列号

负责服务的对等方需要维护具有服务列表的表，该表连同所述服务列表还提供设备/服务描述文件的位置。一旦使用NOTIFY消息(如上文所述)发出删除命令，负责的对等方需要获得设备/服务描述文件，并且发送针对该文件中的每个关键字的删除命令。可替代地，当生存期期满时，存储节点可以删除关键字。

附录I

用于UPnP设备的示例XML模式

附录J

将XML模式转换为GSS