在运行时使用 UDDI （微软）

请注意如何在运行时为 Web 服务代理类设置入口点。因为所有代理类都是从 System.Web.Services.Protocols.SoapHttpClientProtocol 中衍生出来的，所以代理类会公布一系列属性，.Url 属性就是其中之一。设置此属性使我们能够在运行时指定入口点。然后，我们可以通过线路发送 SOAP 请求。如果没有发生异常，则表示一切正常并且从 Web 服务返回的数据显示在窗体中。但如果确实发生异常，此函数返回“假”，调用代码将尝试从 UDDI 刷新入口点，以重新使用 RefreshCacheFromUDDI() 函数。

重新查询 UDDI 之后，我们会将 UDDI 返回的入口点与原入口点进行比较。如果入口点相同，则提供者尚未使用新信息更新 UDDI，我们所能做的只有尝试与 Web 服务的提供者联系，告诉他们 Web 服务不响应。但是，如果从 UDDI 检索到的入口点不同，则可以尝试再次调用 Web 服务。

为模拟故障，可以更改 Web 服务的名称。尝试运行应用程序。然后，用 Web 服务的新名称更新 UDDI 项。再次运行应用程序。应用程序将在 UDDI 中找到新的入口点，成功查询新服务，然后保存此信息。如果您完全关闭应用程序，再重新打开，则第一次尝试时应该能够再次调用 Web 服务。

其他方案

这个“失败时重试”示例讨论的是 UDDI 可在运行时用作 Web 服务客户端的支持基础结构。在以后的专栏中，我们将讨论其他方案，包括：

• 优化入口点查找 - 可能有多个 Web 服务支持驻留在不同服务器上的公共接口，这些服务器又位于不同的物理位置。客户端应使用最近的 Web 服务。通过运行时 UDDI 查找，客户可以根据不同服务的地理分类或与该实现关联的其他元数据来确定最佳入口点。
• 基于公共接口聚合数据 - WSDL 中可能定义了一种用于搜索目录的标准 Web 服务接口。该行业的很多供应商都可以实现 Web 服务接口，并在 UDDI 中发布入口点。在运行时，客户端应用程序可以动态搜索这些入口点并发出查询以收集这种编录数据。通过这种方式，轮询应用程序可以利用运行时 UDDI 数据。

此外，我们还将讨论如何优化 WSDL 文件，使其真正充当接口说明文件。

总结

UDDI 提供了重要的运行时功能，可以集成到应用程序中以创建更强壮的动态客户端。通过将 UDDI 用作 Web 服务体系结构中的基础结构，可以编写更加可靠的应用程序。