使用UDDI的Web服务描述和发现（第一部分）

申请免费试用、咨询电话：400-8352-114

使用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 条目之前应准备好几个关键数据。

确定 Web 服务实现所需使用的 tModel（WSDL 文件）。

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

另一方面，如果 Web 服务所基于的 WSDL 文件尚未在 UDDI 上注册，就需要准备创建一个新的 tModel 来代表这个接口。此 tModel 应具有统一资源标识符 (URI) 格式 (MyCompany-com:SampleWebService-interface:v1) 的名称，并指向 WSDL 文件所在的位置。

如果 Web 服务是 Microsoft? Visual Studio? .NET 服务，则可以使用 .ASMX 文件（也就是：<http://www.mycompany.com/SampleWebService.asmx?wsdl>）中的查询字符串来生成 WSDL 说明。但是，Visual Studio .NET 生成的 WSDL 文件与调用 Web 服务的访问点紧密耦合在一起，如果 Web 服务接口有多个实现，访问点可能就不适用了。如果不希望 WSDL 文件有多个实现，这就不是问题。

如果需要，可以用多种语言确定公司的名称和简介，以及公司 Web 服务的主要联系方法。

UDDI 支持 xml:lang 名称空间，它允许公司用多种语言提供公司简介。另外，UDDI 还允许列出联系方式，包括电子邮件、电话和地址信息。联系列表用于列出公司内与 Web 服务相关的资源。例如，如果有人想要使用您的 Web 服务，并需要联系相应的业务关系经理，应该联系谁？使用公司的 Web 服务时，有关技术问题和谁联系？该联系人也应该列出。

为公司确定适当的分类和标识。

通过 Microsoft UDDI 节点 http://uddi.microsoft.com/default.aspx（英文）浏览当前支持的 UDDI 分类法。当前支持的分类法有北美行业分类系统 (NAICS)、通用标准产品和服务代码 (UNSPSC)、ISO 3166、标准行业分类 (SIC) 和 GeoWeb 地理分类。请选择一种最适于您的公司的分类。

确定公司通过 UDDI 提供的 Web 服务。
下一步，确定公司要在公共 UDDI 节点上注册的 Web 服务。这项服务有多个访问点吗？是否要给使用此 Web 服务的客户提供其他必需的参数和信息？

注意，在 UDDI 上注册 Web 服务并不意味着每个人都有访问权。可以为 UDDI 注册表条目依次设置安全、授权和身份验证。仅知道 Web 服务的存在并不意味着就可以实际调用该服务。在授权访问 Web 服务之前，公司之间通常需要进行一些额外的交流。

为服务确定适当的分类。

如同可以将公司分类一样，也可以将 Web 服务分类。因此，公司可能按商业级别被分类为 NAICS: Software Publisher (51121)，而其旅馆预约 Web 服务的服务级别可能被分类为 NAICS: Hotels and Motels (72111)。

步骤 2：注册 UDDI 条目

在完成建模之后，下一步就是注册您的公司。您需要获取一个可访问 UDDI 注册表的帐号，这不能通过编程来完成，因为必须要同意“使用规定”声明。Microsoft 节点使用 Passport 进行验证，您需要获取一份 Passport (http://www.passport.com/Consumer/default.asp) （英文）来完成注册。

这里有两种选择：使用 Microsoft 节点提供的 Web 用户界面，或者通过使用 SOAP API 调用节点自身以编程进行注册。如果不希望更改注册表条目，或条目相对简单，则使用 Web 用户界面就足够了。但是，如果希望频繁更新，或条目很复杂，请使用 Microsoft UDDI SDK 制作注册过程的脚本。另外，由于没有针对其他语言对 Microsoft 用户界面进行本地化，所以如果想利用 UDDI API 的多语言功能，需要通过编程的方法进行注册。

注意：您可以在模拟环境中练习注册过程，地址是 http://test.uddi.microsoft.com/default.aspx（英文），这是实际投入使用节点的复本。这对于在正式使用之前熟悉注册过程很有帮助。

使用 Microsoft 的 Web 用户界面

使用 Microsoft 的 Web 用户界面来注册是一个相对直观的过程。首先导航至管理员页面 http://uddi.microsoft.com/administer.aspx（英文）。登录后，将显示注册 tModel 和公司的选项。下面是继续操作时需要了解的几个事项：

在注册服务之前，确保将 WSDL 文件注册为 tModel，因为在以后的过程中会需要 tModel。

将 WSDL 文档注册为 tModel 时，应该使用“UDDI 类型分类法”对 tModel 分类。至少应将 WSDL 分类为“Specification for a Web Service”(wsdlSpec)。

使用这种分类方法，可以确保 tModel 的分类符合“Using WSDL in a UDDI Registry”最佳实践文档（英文）的原则。因为 tModel 能包含对 WSDL 文件以外的文档的引用，所以给 tModel 提供一些分类是很重要的。很多工具（例如 Visual Studio .NET）靠这些分类来缩小查询的结果集。

将 WSDL 接口注册为 tModel 后，需要给公司业务添加相应的联系信息以及分类信息。只要您认为合适，可以添加任意多的分类。

继续添加要通过 UDDI 公开的 Web 服务。因为服务可以有多种实现，所以需要给每个添加的服务添加一个绑定。对于每个绑定，需要提供 Web 服务的访问点，即 < http://www.mycompany.com/SampleWebService.asmx>。

每个绑定都需要为所支持的接口创建一个引用。Microsoft UI 将这些作为“规范签名”来调用。规范签名就是包含 WSDL 接口的 tModel。Microsoft UI 会提供一个屏幕，允许您基于其 URN 来搜索 tModel。这个 tModel 可以是在步骤 1 中注册的，也可以是别人注册的 WSDL 文件的 tModel。

最后，系统会显示选项，要求提供一个关于特定 Web 服务的概述文档的 HTTP 地址，以及任何相关的实例参数。

使用 Microsoft UDDI .NET SDK 编程进行注册

注册过程的另一种选择是通过编程进行注册。使用 Microsoft UDDI SDK 可以轻而易举地完成该过程。您必须使用 Web UI 获取一个 UDDI 帐号。完成该任务后，其余过程就交给脚本来处理。首先，下载并安装 UDDI SDK，地址是 http://www.microsoft.com/downloads/release.asp?ReleaseID=30880（英文）。然后，使用 Visual Studio .NET 创建一个新的 C# 控制台应用程序。添加一个对 Microsoft UDDI SDK dll 的引用，其默认安装位置是 C:Program FilesMicrosoft UDDI SDKVS7Microsoft.Uddi.Sdk.dll。然后，在代码顶部添加一些名称空间引用：

using Microsoft.Uddi;
using Microsoft.Uddi.Binding;
using Microsoft.Uddi.Business;
using Microsoft.Uddi.Service;
using Microsoft.Uddi.ServiceType;

在 static void Main (string[] args) 函数中添加下列代码：

// 您最好先运行这个程序，在 https://test.uddi.microsoft.com/publish
// 上进行注册测试
Publish.Url = "https://uddi.microsoft.com/publish";
Publish.User = "您的帐户";
Publish.Password = "************";

这将为您的帐户建立身份验证。下一步，添加以下代码将 WSDL 文件发布为 tModel：

// 创建 tModel
SaveTModel stm = new SaveTModel();
stm.TModels.Add();
stm.TModels[0].Name = "此处插入 URN";
stm.TModels[0].Descriptions.Add("zh","此处插入说明");
stm.TModels[0].OverviewDoc.OverviewURL = "此处插入 WSDL 的 URL";
// 下一行是给 tModel 正确分类所必需的
stm.TModels[0].CategoryBag.Add
( "uddi-org:types",
"wsdlSpec",
"uuid:c1acf26d-9672-4404-9d70-39b756e62ab4" );

string sTModelKey = "";

// 发送到 UDDI
try
{
TModelDetail tmd = stm.Send();
sTModelKey = tmd.TModels[0].TModelKey;
}
catch (UddiException ue)
{
Console.WriteLine ( ue.Message );
return;
}
catch (Exception e)
{
Console.WriteLine ( e.Message );
return;
}

成功保存后，UDDI 将生成一个新的唯一的 tModelKey，以后在 Web 服务的绑定中需要用到它。下一步，创建公司条目：

// 创建公司
SaveBusiness sb = new SaveBusiness();
sb.BusinessEntities.Add();
sb.BusinessEntities[0].Name = "此处插入公司名称";
sb.BusinessEntities[0].Descriptions.Add("zh","此处插入说明");

// 创建公司服务
sb.BusinessEntities[0].BusinessServices.Add();
sb.BusinessEntities[0].BusinessServices[0].Name = "此处插入服务名称";
sb.BusinessEntities[0].BusinessServices[0].Descriptions.
Add("zh","此处插入服务说明");

// 创建绑定模板
sb.BusinessEntities[0].BusinessServices[0].BindingTemplates.Add();
sb.BusinessEntities[0].BusinessServices[0].BindingTemplates[0].
Description.Add("zh","此处插入绑定说明");
sb.BusinessEntities[0].BusinessServices[0].BindingTemplates[0].
AccessPoint.Text = "此处插入访问点";
sb.BusinessEntities[0].BusinessServices[0].BindingTemplates[0].
AccessPoint.URLType = Microsoft.Uddi.Api.URLTypeEnum.Http;

// 创建 tModel 实例信息
sb.BusinessEntities[0].BusinessServices[0].BindingTemplates[0].
TModelInstanceDetail.TModelInstanceInfos.Add();
sb.BusinessEntities[0].BusinessServices[0].BindingTemplates[0].
TModelInstanceDetail.TModelInstanceInfos[0].Descriptions.
Add("zh","此处插入说明");
// 使用上面的 tModelKey 字符串
sb.BusinessEntities[0].BusinessServices[0].BindingTemplates[0].
TModelInstanceDetail.TModelInstanceInfos[0].TModelKey = sTModelKey;

// 发送到 UDDI
try
{
BusinessDetail bd = sb.Send();
// 显示 xml
Console.WriteLine ( bd );
}
catch (UddiException ue)
{
Console.WriteLine ( ue.Message );
return;
}
catch (Exception e)
{
Console.WriteLine ( e.Message );
return;
}

此时，WSDL 定义和公司信息都已经保存到了 UDDI 中。通过传递适当的键，以后您可以随时编辑这些条目。

步骤 3：在 UDDI 中搜索条目
在 UDDI 中注册条目后，进行以下三种检查是比较有意义的。第一，使用 Microsoft Web 用户界面，根据名称和分类来搜索您的公司，确认其存在于返回的结果集中。第二，打开 Visual Studio .NET 并确保它是通过“Add Web Reference”对话框显示的。如果没有显示，则可能没有正确使用上述的 uddi-org:types 分类法对您的 tModel 进行分类。您应该能将 Web 服务添加到工程中，并基于 WSDL 文件生成代理代码。第三，等待 24 小时，您的条目将复制到 IBM 节点上，这可以通过其 UI 来查询，地址是 https://www-3.ibm.com/services/uddi/protect/find（英文）。

总结

UDDI 和 WSDL 作为免费的规范，可以帮助建立基于 Web 服务的软件系统。WSDL 提供了与供应商无关的正式方法来定义 Web 服务，这样便可以实现下一代远程过程调用。而 UDDI 提供了一种广泛的、标准化的基础结构，允许人们去描述和发现 Web 服务。这两个标准的结合将带来一个繁荣的 Web 服务生态系统。

浏览：使用UDDI的Web服务描述和发现（第二部分）