理解 UDDI(统一描述、发现和集成)
【导读】统一描述、发现和集成（Universal Description, Discovery, and Integration，UDDI）项目继续丰富企业用于在 UDDI 业务注册中心表示 Web 服务并建立其模型的工具集。本文将介绍 UDDI 和它在 Web 服务发展过程中所起到的促进作用。
何为 UDDI？
UDDI 项目鼓励 Web 服务相互操作和相互采用。它是一种工商界居于领先地位的企业之间的伙伴关系，这种关系最早是由 IBM、Ariba 和 Microsoft 建立的。现在参加的公司已逾 300 家。UDDI 提供了一组基于标准的规范用于描述和发现服务，还提供了一组基于因特网的实现。UDDI 继续快速发展，并赢得了业界的支持。这一规范之所以发展很快，是因为有快速实现在背后提供支持，不仅证明了思想，而且为进一步完善规范提供了丰富的实践基础。
UDDI 解决了企业遇到的大量问题。首先，它能帮助拓展商家到商家（B2B）交互的范围并能简化交互的过程。对于那些需要与不同顾客建立许多种关系的厂家来说，每家都有自己的一套标准与协议，UDDI 支持一种适应性极强的服务描述，几乎可以使用任何接口。对于一家地处澳洲的花店，虽然很希望能进入世界上的所有市场，但苦于不知道怎样才能成功，UDDI 提供了一种能实现这一目标的办法。规范允许企业在注册中心中发布它所提供的服务，这样发现企业及服务就变得高效而且简单了。
对于 B2B 交易场所提供者，他们需要获得这一行业内的供应商的分类数据，以及它们与计费服务、包装商、运输商、保险公司等之间的关系，UDDI 允许动态发现相关的 Web 服务并将其集成到聚合的业务过程中。UDDI 提供一站式搜索有关企业和电子化服务的信息。在 UDDI 中发布企业与服务信息使其它企业能大范围的访问到这些信息。
UDDI 基于现成的标准，如可扩展标记语言（Extensible Markup Language，XML）和简单对象访问协议（Simple Object Access Protocol，SOAP）。UDDI 的所有兼容实现都支持 UDDI 规范。公共规范是机构成员在开放的、兼容并蓄的过程中开发出来的。目的在于先生成并实现这个规范的三个连续版本，之后再把将来开发得到的成果的所有权移交给一个独立的标准组织。
图 1. UDDI 的分层 Web 服务协议栈
如 图 1中所示，UDDI 包含于完整的 Web 服务协议栈之内，而且是协议栈基础的主要部件之一，支持创建、说明、发现和调用 Web 服务。
UDDI 构建于网络传输层和基于 SOAP 的 XML 消息传输层之上。诸如 Web 服务描述语言（Web Services Description Language，WSDL）之类的服务描述语言提供了统一的 XML 词汇（与交互式数据语言（Interactive Data Language，IDL）类似）供描述 Web 服务及其接口使用。您可以通过添加分层的功能搭起整个基础，比如使用 Web 服务流程语言（Web Services Flow Language，WSFL）的 Web 服务工作流描述、安全性、管理和服务质量功能，从而解决系统可靠性和可用性问题。
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。通过商务合同来确保一致。几家公司可以自由提供超出规范所要求的服务范围之外的附加服务，比如，基于浏览器的用户界面（所有公司都做到了这一点）。
UDDI 规范一窥
UDDI 规范是由一些文档组成的。API 规范描述允许您执行发现和发布操作的 SOAP API。还描述了请求／响应语义和错误处理。此外，还有大量关于约定和用法的信息。附带的文档包括数据结构规范（Data Structure specification）和 API Schema，它们定义了消息和数据语义。
UDDI API 属于 Inquiry 或 Publishing 类别。第 1 版支持 API 操作，如 清单 1中所示。
清单 1. UDDI V1 API 综述
Inquiry Operations: Publishing Operations:
Find Save
find_business save_business
find_service save_service
find_binding save_binding
find_tModel save_tModel
Get details Delete
get_businessDetail delete_business
get_serviceDetail delete_service
get_bindingDetail delete_binding
get_tModelDetail delete_tModel
get_registeredInfo get_registeredInfo
Security
get_authToken
discard_authToken
|
查询 API 把自身归为三种查询模式：
- 浏览器模式需要使用查找操作，查找操作允许您在浏览条目时使用不同类型的标准，例如分类法类别、标识符或利用 find_xxx API 查找不完整的名称信息。
- 逐步深入模式涉及到获得有关您已经找到的条目的详细信息。 get_xxx API 支持这一功能。
- 调用模式是最后一种模式。调用服务需要使用绑定模板信息，通常客户机将这一信息放在缓存区以供重复使用，不需要客户机在每次需要时再回到注册中心去获取同样的信息。如果绑定信息变化了，那么一旦无法获得或使用服务，客户机就会返回到注册中心以更新这一信息。这被称为调用模式。
虽然每个顶层实体都可以被保存和删除（利用 save_xxx 和 delete_xxx API），而且主要是自动说明的，但是应该注意，通常 UDDI 中的保存操作的行为具有破坏性。举个例子，再次保存同一个服务，但信息有所不同，结果以前代表该服务的那个实体会被完全替换掉。
与 authTokens 有关的操作要求您向某个 UDDI 业务注册中心节点预注册，提供确认发布者身份所必需的凭证。这些凭证用于获取用于执行发布操作（利用 save_xxx API）的 authToken 。如果我们假定 authToken 没有过期，在紧紧相随的发布操作期间有一小段时间内它是可以重用的。运营商制订的规定将决定 authToken 的内容和寿命。
支持建模
有关支持建模的更新主要目的在于帮助大的机构更高效的建立其企业和服务的模型。从牵涉到不同种类的风险的大型集团企业到集中精力经营一种业务而且希望按它们服务的地理区域来划分其 Web 产品的公司，许多都希望它们在 Web 上表现为独立却相互关联的企业。在 UDDI 版本 1 中，对于这些情况，唯一的选择就是保持企业独立但却毫无关系。版本 2 允许您定义企业之间的关系，例如 父－子关系、 伙伴－伙伴关系和 等同关系。这样，您就能根据具体情况为有下属子公司、外部业务伙伴或者内部的各种部门的公司建立模型。任意两个企业（据其独一无二的企业键的定义）之间都可能会形成关系。新建的 Business Relationship 类型的规范的 tModel 支持这一能力，而且还有一些新的发布 API，允许您定义、删除和请求关系的状态，如 清单 2中所示。
名叫 find_relatedBusinesses 的新查询 API 使您能就给定的公司匿名搜索涉及到它的关系。 清单 2中的其它新的发布 API 都与特定的发布者创建并拥有的关系有关，并且这些关系都不能通过匿名查询来访问。一个企业关系由一对相同的关系断言组成，每个关系断言都会将这两家企业连在一起，并标志所建立的特定关系。为了形成外部可见的企业关系，所涉及的两家企业每家必须声明相同的关系断言。只有那些匹配的关系断言才会作为 find_relatedBusinesses() 查询结果返回。
下面的示例展示了关系怎样形成，日后怎样发现关系。首先，您会得到一个发布授权令牌：
清单 2. 得到一个 authToken
<Envelope xmlns="http://schemas.xmlsoap.org/soap/envelope/">
<Body>
<get_authToken generic="2.0"
xmlns="urn:uddi-org:api_v2"
userID="businessA_UserId"
cred="businessA_Password" />
</Body>
</Envelope> |
其返回内容如下：
清单 3. 得到 authToken 的响应
<Envelope xmlns="http://schemas.xmlsoap.org/soap/envelope/">
<Body>
<authToken generic="2.0"
operator="www.ibm.com/services/uddi"
xmlns="urn:uddi-org:api_v2" >
<authInfo>businessA_AuthToken</authInfo>
</authToken>
</Body>
</Envelope>
|
接着，您建立一个企业断言将企业 A 和企业 B 联系起来，在此我们不使用典型的 UUID 格式，而是把它们的 businessKeys 分别简写为 businessKeyA和 businessKeyB 。为了简洁起见，我们不再展示 SOAP 信封。
<add_publisherAssertions generic="2.0"
xmlns="urn:uddi-org:api_v2">
<authInfo>businessA_AuthToken</authInfo>
<publisherAssertion>
<fromKey>"businessKeyA"</fromKey>
<toKey>"businessKeyB"</toKey>
<keyedReference keyValue="parent-child"
keyName="Subsidiary"
tModelKey="uuid:c1acf26d-9672-4404-9d70-39b756e62ab4"/>
</publisherAssertion>
</add_publisherAssertions>
|
一旦企业 B 的主人也建立了一个相同的断言，就能在注册中心中看到一个对大众公开可见的企业关系。然后，您可以利用 find_relatedBusinesses() API 执行一个简单的查询：
<find_relatedBusinesses generic="2.0"
xmlns="urn:uddi-org:api_v2">
<businessKey>"businessKeyA"</businessKey>
</find_relatedBusinesses>
|
清单 3展示了返回的 XML。更加细粒度的查询可能会包括一个标识正在查找的特定关系的 keyedReference 。
版本 2 中为支持大企业的建模需求而新增的另一项重要功能叫做服务投影（Service Projection），它允许一家企业创建对另一家企业拥有的服务的引用。这在有些情况下是很有用的，例如，对于在两个或以上的行业内提供相同的服务的公司和通用服务（例如过夜运输）都很有用，有许多企业都想要把某个通用服务链接到它们自己提供的服务上来鼓励使用这种服务。
投影的服务引用的功能不过如此。服务投影的创建者不能改变所引用的真正服务，但在其它所有方面，这个服务都好象真的是创建投影的企业所拥有一样。服务是 get_businessDetail() 或 get_serviceDetail() API 调用返回的一部分。通过与服务相关联的具有所有权的企业键，您可以把投影服务与真正的服务区分开来。这个键始终与拥有服务的真正企业相匹配，而不是与创建服务投影的企业相配。
国际化
一直以来都在努力改进 UDDI 的国际化程度，现在已经添加了一些新功能。已经给 businessEntity 和 businessService 增加了对多个名字和 xml:lang 代码的支持。虽然您必须提供至少一个名字，但是也可以提供多个名字（每个名字使用一种不同的语言代码）。