UDDI V3 注册中心的查询 API

查询 API 中提供四种格式的查询,它们遵循匹配软件需求的广泛使用约定,即注册表中使用的惯例。

查询的四种格式是:
  • 浏览器模式
  • 向下钻取模式
  • 调用模式
  • 查询 API 函数

UDDI 注册中心的浏览模式

用来研究和检查数据(尤其是分层数据)的软件要求具备浏览器能力。浏览模式的特征体现为从一些主要信息开始、执行搜索、查找常规结果集,然后选择有关向下钻取模式的更具体信息。

UDDI API 规范通过 find_xx API 调用来提供浏览模式。这些调用形成 API 提供的搜索能力。这些调用与总结返回消息(其返回有关与查询消息类型和查询中指定的搜索条件相关联的已注册信息的概述信息)相匹配。

典型浏览顺序可能涉及到了解是否为您知道的业务注册了任何信息。此顺序开始时调用 find_business,可能会传递已知的业务名的首字符。此操作返回 businessList 结果。这将导致从已注册的 businessEntity 信息派生而来的概述信息(密钥、名称和描述)与您提供的名称片段相匹配。如果此表中包含要查找的业务,那么可以使用 find_service API 调用向下钻取相应的业务服务信息,并查找特定的技术模型,如购买或装运。同样地,如果知道特定软件界面的技术指纹,即 tModel 签名,而且您要查看查找的业务是否提供支持该界面的 Web 服务,那么可以使用 find_binding 查询消息。

UDDI 注册中心的下钻模式

当您具备 UDDI 注册中心管理的四种主要数据类型中一种类型的密钥时,就可以使用该密钥访问特定数据实例的全部注册详细信息。这四种 UDDI 数据类型是 businessEntity、businessService、bindingTemplate 和 tModel。可以通过将相关的密钥类型传递给其中一个 get_xx API 调用,从而访问任何这些结构的所有已注册信息。

继 续之前部分的示例,按照所有 find_x 返回设置返回的一个数据项是密钥信息。 对感兴趣的业务,businessList 结构内容中返回的 businessKey 值可以作为自变量被传递到 get_businessDetail 消息。businessDetail 消息成功返回到此消息,其中包含实体的完整注册信息以及传递的密钥值。 此信息将是完整的 businessEntity 结构。

UDDI 注册中心的调用模式

对利用由其他业务或实体注册在 UDDI 注册中心的远程 Web 服务的应用程序,必须准备该应用程序以使用在注册中心找到的正在调用的特定服务信息。

从 UDDI 注册中心获取的 bindingTemplate 数据表示有关给定接口类型的实例的特定详细信息,包含程序开始与此服务交互的位置。只要调用应用程序需要与服务实例通信,该调用应用程序或程序就会高速缓存此信息,并使用此信息与已注册的地址处的服务联系。

在以前特别流行的远程过程技术中,各种工具会自动完成与高速缓存、硬编码或位置信息相关的任务。但是,如果远程服务移动了位置而调用者并不知道这种情况,那么就会发生问题。有很多原因可能会造成远程服务进行移动,例如:服务器升级、灾难恢复、获取服务或者更改了业务名。

调用使用先前从 UDDI 注册中心获得的高速缓存信息失败时,正确的做法是查询 UDDI 注册中心以获取刷新 bindingTemplate 信息。如果返回的数据与高速缓存的信息不同,那么服务调用可以使用新信息,自动尝试再次调用。如果重试此调用成功,那么新信息就会替换高速缓存的信息。

通过将此模式与 Web 服务配合利用,让使用 UDDI 注册中心的业务可以自动恢复很多伙伴,无需不必要的通信和协作开销。例如,如果企业激活灾难恢复站点,那么当伙伴尝试调用失败站点上的服务时,他们发出的大部分调用都失败。 通过使用提供服务的新地址来更新 UDDI 信息,使用调用模式的那些伙伴就会自动找到新的服务信息,并且无须执行更多管理操作就可以恢复。


指示主题类型的图标 概念主题



时间戳记图标 最近一次更新时间: last_date
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=cwsu_inquiry_api
文件名:cwsu_inquiry_api.html