使用 UDDI 的 Web 服务描述和发现（第一部分）
Karsten Januszewski
Microsoft Corporation
2001年10月3日

查看和下载本文的源代码（英文）。

简介

到目前为止，At Your Service 专栏已经介绍了如何建立 Web 服务的实际案例：从最初的设计文档到业务关联，直至最终的部署。下一步就是要考虑如何发布 Web 服务，以便感兴趣的客户能够轻松地发现该服务并将其应用到自己的应用中。现在已经有了实现这种要求的发现机制：通用说明、发现和集成 (UDDI)，这是业界支持跨技术、跨平台的 Web 服务发现的第一步。
At Your Service 的作者诚恳地邀请我为专栏撰文，介绍 UDDI 及其注册步骤，我非常乐于接受这项工作。首先我将从技术和业务两方面来介绍 UDDI 的含义。随后我将讨论一下 UDDI 和 Web 服务说明语言 (WSDL) 之间的关系。最后，我将带您体验 UDDI 的注册过程，并介绍一些充分发挥 UDDI 潜力所需考虑的问题。在下一期专栏，即本文的第二部分中，我将介绍 At Your Service 小组是如何充分利用 UDDI 的。

UDDI - Web 服务的全球注册表

UDDI 是一个公共的注册表，旨在以一种结构化的方式来保存有关各公司及其服务的信息。通过 UDDI，人们可以发布和发现有关某个公司及其 Web 服务的信息。这些数据使用标准的分类法进行分类，因此可以按分类来查询信息。最重要的是，UDDI 包含有关公司服务的技术接口的信息。通过一套基于 SOAP 的 XML API 调用，用户可以在设计时和运行时与 UDDI 进行交互以发现技术数据，从而调用和使用这些服务。通过这种方法，UDDI 可以用作基于 Web 服务的软件系统的基础结构。
为何使用 UDDI？为何需要这种注册表？当我们面对具有数千甚至数百万个 Web 服务的软件系统时，将面临以下的严峻挑战：

• 如何发现 Web 服务？
• 如何按照某种合理的方式分类信息？
• 对本地化有什么影响？
• 对专用技术有什么影响？如何保障发现机制的互操作性？
• 当应用依赖于某项 Web 服务时，如何在运行时与该发现机制进行交互？

UDDI 的出现正是为了应对这些挑战。为了解决这些问题，许多公司，其中包括 Microsoft、IBM、Sun、Oracle、Compaq、HP、Intel、SAP 以及三百多家其他公司（请参阅 UDDI: Community（英文）以获得这些公司的完整列表），共同制定了一种基于开放式标准和非专用技术的规范。该规范的 Beta 版于 2000 年 12 月发布，正式产品于 2001 年 5 月推出。它是一个全球业务注册表，建立在多个运营商节点上，用户可以通过这些节点免费搜索和发布信息。
通过 Web 服务的这种基础结构，现在就能够以一种通用的、与供应商完全无关的方式找到有关 Web 服务的数据，而且数据一致并且可靠。使用可扩展的分类系统和标识，用户可以进行精确的分类查询。运行时 UDDI 集成可以被合并到应用程序中去。因而大大繁荣了 Web 服务软件环境。

工作原理

UDDI 数据存放在运营商（即承诺运营一个公共节点的公司）节点上。这种公共节点遵循 UDDI.org 组织管理的规范。目前已经建立了两个遵循 UDDI 规范版本 1 的公共节点：一个属于 Microsoft；另一个属于 IBM。HP 也承诺将建立一个遵循规范版本 2 的节点。数据寄存运营商之间必须能通过安全通道复制数据，从而为整个 UDDI 云团提供数据冗余。将数据发布到一个节点上后，通过复制，就可以在另一个节点上发现这些数据。目前，每隔 24 小时就进行一次复制；在将来，由于有更多的应用程序要依赖 UDDI 数据，复制的时间间隔还将缩短。
值得一提的是，对于数据寄存运营商实现其节点的方式，不存在一些专用的要求，只要节点遵循 UDDI 规范即可。例如，Microsoft 的节点 http://uddi.microsoft.com/default.aspx（英文）完全用 C# 写成，并运行于 .NET Beta 2 公共语言运行时环境下。其代码基础充分利用了 .NET 系统类提供的本地 SOAP 支持和序列化。在后端，Microsoft 运营商节点使用 Microsoft® SQL Server 2000 作为其数据仓库。而 IBM 使用其他技术来运行其节点！但是，这两个节点的行为是相同的，因为它们都遵循相同的一套基于 SOAP 的 XML API 调用。客户端工具可以和这些节点进行无缝的交互操作。因此，UDDI 公共云团是一个最佳方案，它展示了 XML Web 服务模型如何跨异类环境进行工作。
为了了解 UDDI，下一步我们来看看 UDDI 中存储的数据及其存储结构。UDDI 相对来说是轻量的，它被设计为“注册表”，而不是“储备库”。两者之间的差别很微妙，但却很重要。注册表将用户重定向至资源，而储备库则完全是一个信息库。我们以 Microsoft® Windows® 注册表为例：它包含基本设置和参数，但最终把应用程序引导至资源或二进制代码。基于 Prog ID 搜索 COM 组件时，将引导至一个 Class ID，然后通过 Class ID 再引导至二进制代码本身所在的位置。
UDDI 的行为与之类似：与 Windows 注册表一样，它依靠全局唯一标识符 (GUID) 来搜索并定位资源。UDDI 查询最终指向一个接口（.WSDL、.XSD 和 .DTD 文件等等），或指向其他服务器上的实现（例如 .ASMX 或 .ASP 文件）。UDDI 因此可以回答以下问题：

• “已经发布了哪些基于 WSDL 并是为指定行业建立的 Web 服务接口？”
• “哪些公司已经为其中一个接口写好了实现？”
• “目前提供的 Web 服务（以某种方式分类）有哪些？”
• “某个公司提供了哪些 Web 服务？”
• “如果要使用某个公司的 Web 服务，需要与谁联系？”
• “某个 Web 服务的实现细节是什么？”

WSDL 和 UDDI

WSDL 已成为 Web 服务协议堆栈的重要组成部分。因此，有必要掌握 UDDI 和 WSDL 如何协同工作，以及每个协议如何解决接口和实现这两个相对的概念。WSDL 和 UDDI 都是为清楚说明抽象的元数据和具体实现之间的关系而设计的，了解为什么要这么划分是理解 WSDL 和 UDDI 的基础。
例如，WSDL 明确区分消息和端口：消息（Web 服务所需的语法和语义）始终是抽象的，而端口（调用 Web 服务的网络地址）始终是具体的。在 WSDL 文件中不需要提供端口信息。WSDL 可以只包含抽象的接口信息，而不提供任何具体的实现数据。这样的 WSDL 文件被认为是有效的。这样，WSDL 文件便从实现中分离出来。
其重要意义之一在于：一个 WSDL 接口可以有多个实现。这种设计允许不同的系统为同一接口编写自己的实现，从而保证系统之间能进行对话。如果三个不同的公司实现了相同的 WSDL 文件，一个客户端软件根据这个 WSDL 接口创建了代理/存根代码，那么这个客户端软件就可以使用相同的代码基础与所有这三个实现进行通信，只要更改访问点即可。
UDDI 通过 tModel 的概念描绘了抽象和实现之间的这种区别。tModel 结构（“技术模型”的简称）代表了技术指纹、接口和元数据的抽象类型。使用 tModel 的必然结果是绑定模板，它是一个或多个 tModel 的具体实现。在绑定模板内，要为 tModel 的特定实现注册访问点。如同 WSDL 架构允许分离接口和实现一样，UDDI 也提供了相似的机制，因为 tModel 可以独立于引用它的绑定模板而单独发布。例如，某标准化组织或行业组织可能为特定行业发布规范接口，然后多个公司可以为该接口编写实现。因此，各个公司的实现都需要引用同一个 tModel。WSDL 文件是 UDDI tModel 的完美示例。

用 UDDI 进行注册

发布到 UDDI 是一个比较直接的过程。第一步是确定在 UDDI 上为公司及其服务建立模型所需的基本信息。之后便可以进行实际注册。这可通过基于 Web 的用户界面或编程两种方法完成。最后测试您的注册条目以确保注册正确，并且在不同类型的搜索和工具中都能按要求显示。

步骤 1：为 UDDI 条目建立模型

考虑上述数据模型，在建立 UDDI 条目之前应准备好几个关键数据。

1. 确定 Web 服务实现所需使用的 tModel（WSDL 文件）。
   与开发 COM 组件类似，开发 Web 服务时可以使用现有的接口，也可以使用自己设计的接口。如果 Web 服务基于现有 WSDL，则需要确定该 WSDL 文件是否已经在 UDDI 上注册。如果是，就需要记录其名称和 tModelKey，这是注册 WSDL 文件时 UDDI 所生成的 GUID。
   另一方面，如果 Web 服务所基