理解UDDI(3):bindingTemplate与Web服务调用（下）

MILY: 黑体; mso-ascii-font-family: 'Arial Black'">(本文是我在developerWorks专栏发表的bindingTemplate与Web服务调用
的缩减版，需要浏览未缩减版原文，请访问http://www.ibm.com/developerWorks/cn/)

基于bindingTemplate的调用模式

当我们需要编制实现一个应用程序：这个应用程序需要使用一个已被其它商业实体注册在UDDI注册中心的远端Web服务，那么你需要从注册中心中发现为调用指定服务所需要的调用规范信息，并在程序编制时使用。这种类型的跨商业实体的服务调用在传统上将被视为是开发阶段的任务。尽管，这样的开发模式并不会因UDDI注册信息的出现而完全改变，但起码，如果使用了UDDI注册所支持的特别的调用模式，将可以解决一个非常显著而重要的问题。

从UDDI注册中心中获得的bindingTemplate信息集中的数据表示了一个指定的远端Web服务的调用规范实例。程序应当缓存该信息并且使用这个调用规范通过该Web服务注册的地址来访问这个Web服务。使用以前流行的远程过程调用技术的工具已经能够将这样一种工作自动化地实现，无论是通过缓存其调用位置或是通过写入固定代码的方式，都可以做到。然而，当远程服务在没有通知调用者的情形下发生了迁移，那么就会引起问题，该程序无法自动地更新访问代码或访问地址。这样的迁移可以是由各种原因造成的，包括服务器升级，灾难恢复以及服务入口或企业名称的改变等。

当使用从UDDI注册表中获得并缓存下来的信息进行调用发生失败时，正确的做法是去查询当初获得该数据的UDDI注册中心并获取与其对应的更新了的bindingTemplate信息。正确的调用是使用get_bindingDetails，并传入原始的bindingKey键值。如果返回的数据与缓存的信息不同，那么应该使用新的调用信息来重新尝试服务调用。如果这一重试操作获得成功的话，新的信息应当取代原先缓存的信息进入当前的缓存。

在使用Web服务中，使用这样的调用模式，那么使用UDDI操作入口站点(Operator Site)的商业实体就得以在不加重通信与协调开销的情况下自动完成与大量合作伙伴的服务恢复。例如，如果一个企业激活了一个灾难恢复站点以取代某个崩溃的原服务提供站点，来自合作伙伴的大部分调用想访问那个已经崩溃的服务提供站点时，会遭遇失败。通过把新的提供服务的地址更新到UDDI信息中，那些使用调用模式的合作者将可以自动地获取新的服务调用信息并在无需管理员介入的情况下恢复系统连接。

这一过程的详细程序式描述如下：

1.    服务提供者使用save_xx在UDDI注册中心中注册了Web服务S；

2.    调用者使用find_xx查询UDDI注册中心，获得所需的服务S的概要信息；

3.    调用者使用get_xx再一次查询UDDI注册中心，获得所需服务S的详细信息；

4.    调用者缓存服务S的bindingTemplate信息，通过服务绑定，实施对服务S的调用；

5.    服务S由于某种原因出现问题，无法继续提供服务；

6.    服务提供者在新的位置重新部署了服务S，同时更新了UDDI注册中心的关于Web服务S的技术描述；

7.    调用者使用缓存的服务S的bindingTemplate信息再一次进行调用，调用失败；(服务S的部署位置已经更改)

8.    调用者使用缓存的bindingTemplate的bindingKey键值查询UDDI注册中心，获得服务S的更新后的bindingTemplate信息。

9.    调用者缓存服务S的新的bindingTemplate信息，通过服务绑定，重新实施对服务S的调用。

服务重定向

在许多情况下，在get_bindingDetail消息中定义的API是直接的。当一个企业或应用程序知道需要调用的服务时，该服务相关的bindingTemplate信息就可以被缓存以供使用。如果缓存信息在真正需要被调用时发生失败的话(比如被缓存的bindingTemplate结构的aclearcase/" target="_blank" >ccessPoint信息被用于调用一个远程的合作伙伴所提供的服务)，该应用可以通过被缓存的信息中的bindingKey来得到一个bindingTemplate信息的最新副本。这种缓存操作可以避免多余的对注册中心的访问。

需要使用hostingRedirector的特殊情况

两种不能被bindingTemplate中accessPoint信息直接支持的特殊需求是：

§         Web服务在技术上由第三方提供主机：一个企业可以选择这样一种方式来发布一种服务，该服务逻辑上属于本企业，但实际上该服务是在远程的或者第三方的主机上运行的(比如ASP模式的企业应用)。应用服务提供商和网络交易市场运营商是这种情况的典型代表。在这种情况下，实际上是作为第三方的应用服务提供商和网络交易市场运营商实际上控制了绑定信息bindingTemplate的运行时态的取值。

§         由用户指定的对绑定位置的访问控制：在其他情况中，比如与调用上下文相关的重定向是基于调用者的用户标识的(比如具备某种权限的用户被重定向入一个管理入口，而其他用户被重定向入一个普通入口)，或者甚至是每天的路由，此时，提供更动态的对远程服务的实际联络信息的方式是非常必需的，相比起缓存accessPoint数据以支持调用的方式更为必要。

由于这些原因，bindingTemplate结构包括了另一个数据元素，被称为hostingRedirector。hostingRedirector元素的存在表明了调用者如果需要调用由指定bindingTemplate所表示的Web服务时必须使用一个额外的步骤去获得accessPoint信息(即，调用地址)。当在解析一个hostingRedirector引用时，需要经过两个步骤。