http://www-128.ibm.com/developerworks/cn/webservices/ws-featuddi/
跟上规范的不断发展
Tom Bellwood
资深技术人员, IBM
2002 年 7 月
统一描述、发现和集成（Universal Description, Discovery, and Integration，UDDI）项目继续丰富企业用于在 UDDI 业务注册中心表示 Web 服务并建立其模型的工具集。本文将介绍 UDDI 和它在 Web 服务发展过程中所起到的促进作用。您可以了解到 UDDI 的工作原理，并发现 UDDI 规范新的即将出现的功能。
何为 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 规范。公共规范是机构成员在开放的、兼容并蓄的过程中开发出来的。目的在于先生成并实现这个规范的三个连续版本，之后再把将来开发得到的成果的所有权移交给一个独立的标准组织。UDDI 版本 1 规范于 2000 年 9 月发布，版本 2 于 2001 年 6 月发布。版本 3 还在开发中，预计到 2002 年年中发布。版本 1 打下了注册中心的基础，版本 2 则添加了企业关系等功能，版本 3 接下去要解决正在进行的 Web 服务开发中的重要领域内的问题，如安全性、改善了的国际化、注册中心之间的互操作性以及为进一步改进工具而对 API 进行的各种改进。
图 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 把自身归为三种查询模式：
|
UDDI 版本 2.0
UDDI 在数据模型内定义了四种核心数据元素：
- businessEntity（建立企业信息模型）
- businessService（描述服务）
- tModel（描述规范、分类或标识）
- binding Template（在 businessService 和描述其技术特征的 tModel 集之间进行映射）
除这些核心元素之外，版本 2 添加了建立企业之间的关系模型的支持。
UDDI 规范和 UDDI 业务注册中心提供了一组参考实现，它们之间互操作共享注册、依据客户机需要启用支持设计时或运行时发现服务的编程模型。IBM Web 服务倡议（Web Services Initiative）的即时集成价值取向加上其它重要的使能技术（例如 WSDL）允许机构执行在运行时动态发现和绑定 Web 服务。
UDDI 规范一直以来的不断发展解决了关键领域内的问题（例如数据完整性、访问控制、身份识别、认证、互操作性、改进的数据建模能力、查询和本地化）进一步增加了 UDDI 注册中心的价值。
|
- 浏览器模式需要使用查找操作，查找操作允许您在浏览条目时使用不同类型的标准，例如分类法类别、标识符或利用
find_xxx API 查找不完整的名称信息。
- 逐步深入模式涉及到获得有关您已经找到的条目的详细信息。
get_xxx API 支持这一功能。
- 调用模式是最后一种模式。调用服务需要使用绑定模板信息，通常客户机将这一信息放在缓存区以供重复使用，不需要客户机在每次需要时再回到注册中心去获取同样的信息。如果绑定信息变化了，那么一旦无法获得或使用服务，客户机就会返回到注册中心以更新这一信息。这被称为调用模式。
虽然每个顶层实体都可以被保存和删除（利用 save_xxx 和 delete_xxx API），而且主要是自动说明的，但是应该注意，通常 UDDI 中的保存操作的行为具有破坏性。举个例子，再次保存同一个服务，但信息有所不同，结果以前代表该服务的那个实体会被完全替换掉。
与 authTokens 有关的操作要求您向某个 UDDI 业务注册中心节点预注册，提供确认发布者身份所必需的凭证。这些凭证用于获取用于执行发布操作（利用 save_xxx API）的 authToken 。如果我们假定 authToken 没有过期，在紧紧相随的发布操作期间有一小段时间内它是可以重用的。运营商制订的规定将决定 authToken 的内容和寿命。
UDDI 版本 2 中有哪些新内容？
UDDI 版本 2 引入了一些很关键的功能，有了这些功能可以提高版本 1 规范 UDDI 注册中心的使用质量和效率。下面会分几部分描述版本 2 中的新功能：
- 为复杂机构提供建模支持
- 更强大的客户机分类和标识符支持
- 增强的查询
- 国际化功能
- 基于对等的复制
支持建模
有关支持建模的更新主要目的在于帮助大的机构更高效的建立其企业和服务的模型。从牵涉到不同种类的风险的大型集团企业到集中精力经营一种业务而且希望按它们服务的地理区域来划分其 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 调用返回的一部分。通过与服务相关联的具有所有权的企业键，您可以把投影服务与真正的服务区分开来。这个键始终与拥有服务的真正企业相匹配，而不是与创建服务投影的企业相配。
强大的分类功能
在版本 1 中提供了三种内置的分类法供为企业和服务分类使用。它们是 NAICS 行业分类法、UNSPC 项目和服务分类法和 ISO-3166-2 地理分类法。UDDI 注册中心会在内部检查这些分类法的使用情况；试图保存无效的代码会遭到拒绝。在 UDDI 中有针对性的分类法的重要性再怎么强调也不会过分。既然查找感兴趣的有用信息功能最为强大的方法只有这一种，那么提高业界创建和控制新的分类法的能力将继续占有较高的优先级。
版本 2 新增的能力使机构能定义新的外部检查的分类法，可以在 UDDI 中提供这些分类法供大众使用。这些外部分类法提供者必须支持 validate_values Web 服务，并使 UDDI 业务注册中心能够访问该服务，以支持对客户机想要与它们在注册中心中的条目相关联的分类法值进行外部检查和验证。这是一个受控的过程。只有得到 UDDI 业务注册中心运营商的批准，外部验证的分类法才能完成注册。
这个验证新功能允许分类法提供者以灵活的方式来保证使用它们的分类法客户机只能保存那些有效的分类法值。当客户机请求使用提供者的分类法的时候，提供者在验证请求者是否是合法使用分类法之外，还可以选择进行有上下文的验证。更为常见的无上下文方案也支持将分类法数据缓存在 UDDI 业务注册中心以减少对提供者的外部分类法服务的依赖。
增强的查询
版本 2 在以前提供的查询能力的基础上添加了一些强大的功能来按更复杂的要求进行查询。为了增强现有的 find_xxx 查询 API 添加了几种新的过滤条件（查找限定符），包括 orLikeKeys 、 orAllKeys 、 combineCategoryBags 、 serviceSubset 和 andAllKeys 。其中，我们特别感兴趣的有 combineCategoryBags 、 serviceSubset 和 orLikeKeys 。
combineCategoryBags 限定符允许您将与一个企业相关联的所有分类法数据以及该企业所包含的所有服务（包括任何服务投影）分在一个集合内，然后就对这个集合执行搜索。这个限定符有用的原因在于，通过同时查看企业和它所包括的服务减少了查找感兴趣的企业的步骤。
同样， serviceSubset 过滤器允许您使用分类法标准来搜索企业，只对与构成企业的服务相关联的分类进行这样的测试。在这种搜索方法中不包括与企业本身相关联的分类。
最后， orLikeKeys 限定符特别有用，因为它支持复杂的伪码查询。例如，您可以查找位于美国、墨西哥或者加拿大同时提供冷藏服务或一般的运输服务的企业。这使您可以搜索分在不同特征级别的类别中的企业，同时允许一个查询条件引用多种不同分类法。
国际化
一直以来都在努力改进 UDDI 的国际化程度，现在已经添加了一些新功能。已经给 businessEntity 和 businessService 增加了对多个名字和 xml:lang 代码的支持。虽然您必须提供至少一个名字，但是也可以提供多个名字（每个名字使用一种不同的语言代码）。
版本 2 中的另一个国际化功能是新增了一类分类法，叫做 postalAddress ，它能让您创建描述本地化邮政地址的 tModel，然后把它们与在业务实体中找到的地址相关联。
复制
虽然 UDDI 客户机不能直接看到，但版本 2 已经对注册中心运营商之间的复制操作做了重大改进。UDDI 版本 1 仅支持基于文件的复制模式，随参与到 UDDI 注册中心中的注册中心节点实现数目的增长，其复杂程度以 n 的平方增长。版本 2 能满足数目更多的参与节点，它们相互复制。复制可以以一种基于对等的方式进行，在任何一个节点上都可以获得在其它所有节点上发生的注册中心更新。现在由于定义了一组允许处理更改和过程管理的 API，复制得到了更进一步的支持。
下一步
UDDI 规范的下一版本计划在 2002 年年中推出，重点在安全性、高级数据管理以及进一步的国际化上。通过增强访问控制、身份标识和认证提高 UDDI 数据完整性从而使安全性问题得以解决。这要包括支持如 W3C 和 OASIS 这样的机构提供的现有的和新兴的安全性技术。高级数据管理功能将继续增强搜索能力以提供更为精确和命中率更高的查询、更好的解释查询结果、对企业和服务更为丰富且更有意义的描述的捕捉能力以及更好管理现有数据。对国际化的改进将包括支持跨国公司描述其在国际业务分支所进行全球操作，还将解决 UDDI 数据和服务的本地化问题。
结束语
UDDI 继续快速发展。由多家 UDDI 业务注册中心运营商于 2001 年提供 UDDI 版本 2 对公众开放测试版实现。随着这个规范的版本 3 将于 2002 年年中出现，注册中心会继续添加通过 Web 做生意、解决安全性和逐步提高的国际化等领域的问题所需要的功能，及一些附加功能以支持使用注册中心和互操作性。
参考资料
关于作者
 Tom Bellwood 是在 IBM 工作的一位资深技术人员，很多年都从事技术方面的工作，范围从半导体设计领域和设计自动化到开发系统和应用程序。他是一位 UDDI 和 UDDI 如何支持不断发展的 Web 服务世界方面的专家。他还是 IBM UDDI 业务注册中心的技术主管，曾多次在技术会议上发言。 |