用于发布基于结构化元数据的发现的插件模型的方法和装 置 根据 35U.S.C.§119 要求优先权
本专利申请要求于 2009 年 6 月 11 日递交的、 题为 “METHODS AND APPARATUS FOR A PLUG-IN MODEL FOR PUBLISHING STRUCTURED DATAINADISTRIBUTED 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 Description Format)(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 用 作 服 务 发 布 中 的 中 间 步 骤。 其 包 含 连 同 附 加 边 信 息 (side information) 列表一起从原始服务描述提取的关键字列表， 该附加边信息可以与这些关键
字一起被发布。 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( 设备 )， 其提供服务 ； Control point( 控制
点 )， 用户通过其可以控制由设备提供的服务。 被称为简单服务发现协议 (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 的信息。除了该信息之外， 设备描述文件包含放入
字段中 关于设备提供的服务的信息。这个字段包含关于服务的另外的信息， 其中包括服务描述文 件的 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