在运行时使用 UDDI （微软）

在上述情况下，UDDI 在提供基础结构以支持运行时 Web 服务方面能够扮演十分重要的角色。UDDI 通过定义调用规则来解决这些“服务质量”问题，该调用规则包括缓存绑定信息（如 Web 服务的入口点）以及针对此特定实现方式的其他参数。发生故障时，客户端可以发出运行时 UDDI 查询，用最新信息刷新缓存的信息。

上述规定的模式如下：

1. 在 UDDI 中查找 Web 服务。使用此 Web 服务（以 UDDI tModel 表示）的 WSDL 文件以及入口点和其他配置信息的实现细节，所有这些信息都包含在 UDDI bindingTemplate 中。
2. 为特定的 Web 服务准备一个客户端应用程序。在客户端应用程序中，缓存 Web 服务的唯一 bindingKey，以便在首次使用该应用程序时，从 UDDI 检索所需的所有信息。
3. 当应用程序调用远程 Web 服务时，使用从 UDDI Web 注册表获得的缓存数据。
4. 如果调用失败，则使用 bindingKey 值和对 UDDI 注册表的 get_bindingTemplate API 调用以获取新的绑定信息。
5. 对新旧信息进行比较：如果不同，则重试失败的调用。如果重试成功，则用新数据替换缓存的数据并存储新数据以便以后调用。不过，如果返回的绑定信息相同，则提供者不进行任何更新，且应用程序将发生错误。同样，如果有新的绑定信息，但调用仍然失败，应用程序也会发生错误。

从 Web 服务提供者的角度来说，提供者应当知道何时可以更新该 Web 服务的 UDDI 项。当 Web 服务的提供者需要将流量重定向到新位置或者需要备份系统时，提供者只需激活备份系统，然后在 UDDI 注册表中更改入口点。此方法称为失败时重试，为客户端提供了一种在运行时从故障中恢复的机制。

示例方案

我们可以看一个示例，以了解此模式的工作原理。此示例方案涉及的是一家虚构公司的方案，该公司需要向其内部部门提供实时销售数据。因此，此 Web 服务不能公开，而只在防火墙内部使用。