( 本文是我在 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 结构的 accessPoint 信息被用于调用一个远程的合作伙伴所提供的服务 ) ，该应用可以通过被缓存的信息中的 bindingKey 来得到一个 bindingTemplate 信息的最新副本。这种缓存操作可以避免多余的对注册中心的访问。
需要使用 hostingRedirector 的特殊情况
两种不能被 bindingTemplate 中 accessPoint 信息直接支持的特殊需求是：
§ ** Web ** ** 服务在技术上由第三方提供主机 ** ：一个企业可以选择这样一种方式来发布一种服务，该服务逻辑上属于本企业，但实际上该服务是在远程的或者第三方的主机上运行的 ( 比如 ASP 模式的企业应用 ) 。应用服务提供商和网络交易市场运营商是这种情况的典型代表。在这种情况下，实际上是作为第三方的应用服务提供商和网络交易市场运营商实际上控制了绑定信息 bindingTemplate 的运行时态的取值。
§ ** 由用户指定的对绑定位置的访问控制 ** ：在其他情况中，比如与调用上下文相关的重定向是基于调用者的用户标识的 ( 比如具备某种权限的用户被重定向入一个管理入口，而其他用户被重定向入一个普通入口 ) ，或者甚至是每天的路由，此时，提供更动态的对远程服务的实际联络信息的方式是非常必需的，相比起缓存 accessPoint 数据以支持调用的方式更为必要。
由于这些原因， bindingTemplate 结构包括了另一个数据元素，被称为 hostingRedirector 。 hostingRedirector 元素的存在表明了调用者如果需要调用由指定 bindingTemplate 所表示的 Web 服务时必须使用一个额外的步骤去获得 accessPoint 信息 ( 即，调用地址 ) 。当在解析一个 hostingRedirector 引用时，需要经过两个步骤。