UDDI 的工作原理

　　UDDI 注册中心包含了通过程序手段可以访问到的对企业和企业支持的服务所做的描述。此外，还包含对 Web 服务所支持的因行业而异的规范、分类法定义（用于对于企业和服务很重要的类别）以及标识系统（用于对于企业很重要的标识）的引用。UDDI 提供了一种编程模型和模式，它定义与注册中心通信的规则。UDDI 规范中所有 API 都用 XML 来定义，包装在 SOAP 信封中，在 HTTP 上传输。

　　图 2. UDDI 消息在客户机和注册中心之间的流动

 
　　图 2 说明了 UDDI 消息的传输，通过 HTTP 从客户机的 SOAP 请求传到注册中心节点，然后再反向传输。注册中心服务器的 SOAP 服务器接收 UDDI SOAP 消息、进行处理，然后把 SOAP 响应返回给客户机。就注册中心条例而言，客户机发出的要修改数据的请求必须确保是安全的、经过验证的事务。

　　图 3. UDDI 工作原理

 
　　图 3说明了如何往 UDDI 注册中心送入数据，顾客又如何能发现和使用这一信息。UDDI 注册中心建立在顾客提供的数据的基础之上。要使数据能在 UDDI 中物尽其用需要几个步骤。如第 1 步中所示，在软件公司和标准组织定义关于在 UDDI 中注册的行业或企业的规范时，开始向注册中心发布有用的信息。这些规范叫做技术模型或者更常见的说法是 tModel 。

　　在第 2 步中，公司还会注册关于其业务及其提供的服务的描述。如第 3 步中所示，UDDI 注册中心会给每个实体指定一个在程序中唯一的标识符，叫做唯一通用标识符（Unique Universal Identifier，UUID）键，从而能随时了解所有这些实体的情况。UUID 键必须是唯一的，并且在一个 UDDI 注册中心中从来都不会变化。这些键看上去象格式化好的十六进制随机字符串（例如 C0B9FE13-179F-413D-8A5B-5004DB8E5BB2）。可以利用这些键来引用与之相关联的实体。在一个注册中心中创建的 UUID 键只在该注册中心的上下文中有效。

　　在第 4 步，诸如电子交易场所（e-Marketplace）和搜索引擎等其它类型的客户机与商业应用程序（例如，基于工作流聚合起来的 Web 服务）使用 UDDI 注册中心来发现它们感兴趣的服务。接着，另外的企业就可以调用这些服务，简便的进行动态集成，如第 5 步中所述。

　　UDDI 注册中心里的数据从概念上可以分为四类，每一类表示 UDDI 最上层的一种实体。每个这样的实体都指定有自己的 UUID，利用这个标识符总能在 UDDI 注册中心的上下文中找到它：

　　技术模型（Technical model）
　　企业（Business）
　　企业服务（Business service）
　　服务绑定（Service binding）

　　我们可以把企业与服务的注册信息分成以下三组：白页、黄页和绿页。

　　白页表示有关企业的基本信息，如企业名称、经营范围的描述、联系信息等等。它还包括该企业任何一种标识符，如 Dun & Bradstreet D-U-N-S® 号码。

　　黄页信息通过支持使用多种具有分类功能的分类法系统产生的类别划分，使您能够在更大的范围内查找在注册中心注册的企业或服务。这样的类别划分不仅可以关联企业及其服务，还可以关联 tModel。单提供白页和黄页中的一种或者这两种都提供，那么对于通过程序发现和使用服务，注册中心的条目的价值就很有限。为此，有关怎样、哪里能通过程序的方式调用服务的信息就很有必要了，而绿页就提供了这样的信息。

　　绿页是指与服务相关联的绑定信息，并提供了指向这些服务所实现的技术规范的引用和指向基于文件的 URL 的不同发现机制的指针。

　　UDDI 注册中心由 UDDI 规范的一种或多种实现组成，它们可以互操作以共享注册中心数据。有一种特殊的 UDDI 注册中心是由一组对外公开访问的叫做节点的 UDDI 实现构成。它们互操作以共享注册中心数据，合在一起就形成了 UDDI 业务注册中心。该注册中心免费向大众开放。在所有的运营商（Operator）站点上都冗余的放着 UDDI 业务注册中心的全部条目，但只有在创建条目的站点才能对条目进行更改。

　　IBM 和 Microsoft 共同经营第 1 版的 UDDI 业务注册中心节点，这两个公司以及 HP 和 SAP 目前正在经营能支持大部分的第 2 版 UDDI 规范的 beta 测试站点。这四家公司计划于 2002 年年中支持版本 2 生产注册中心。每家公司都支持由 UDDI 规范定义的 SOAP API。通过商务合同来确保一致。几家公司可以自由提供超出规范所要求的服务范围之外的附加服务，比如，基于浏览器的用户界面（所有公司都做到了这一点）。