本文就UDDI服务(UDDI Operator Site / UDDI Registry)的实施体系架构、信息模型和API等技术元素在架构上的关系作了初步的阐述，其中着重介绍了基于P2P(Peer to Peer)体系架构的UDDI操作入口站点(Operator Site)之间的数据协同和复制机制。本文在技术上给于读者一个UDDI在实现上的概览，为作者以后的文章打下一个总体的基础。

　　统一描述、发现和集成协议(UDDI, Universal Description, Discovery and Integration)是一套基于Web的、分布式的、为Web服务提供的信息注册中心的实现标准规范，同时也包含一组使企业能将自身提供的Web服务注册以使得别的企业能够发现的访问协议的实现标准。

　　Web服务是下一代的WWW，它允许在Web站点上放置可编程的元素，使得能进行基于Web的分布式计算和处理。UDDI注册中心的创建目的就是为促进企业的Web服务的发展及为企业发现适当的Web服务。

　　本文主要描述了基于UDDI标准规范的UDDI注册中心的实施的体系架构，以及那些基于UDDI和SOAP的Web服务的实现架构。

　　本文所引用的资源主要包括两类，一类是UDDI的规范、白皮书及相关文档，另一类是协助UDDI规范解决B2B电子商务应用交互和集成的系列技术标准规范，他们与UDDI是一个不可分割的技术体系，包括SOAP、WSDL、XML等。本文的最后给出了这些资源的链接，有兴趣的读者可以通过这些 资源链接找到所需的内容。

　　UDDI基本概念

　　UDDI规范：UDDI规范V1版包括两个规范文本，UDDI Programmer’s API V1.0(UDDI程序员API规范1.0)和UDDI Data Structure Reference V1.0(UDDI数据结构参考1.0)。前者定义了UDDI Operator Site能够支持的API接口，而后者则描述了在API中具体XML描述的数据结构的具体定义。UDDI规范是UDDI Operator Site是实现蓝本，也是需要访问UDDI Registry的Web服务的参考规范。

　　UDDI Registry (UDDI注册中心)：UDDI Registry是所有提供公共UDDI注册服务的站点的通称。UDDI Registry是一个逻辑上的统一体，在物理上则是以分布式系统的架构实施的，而不同站点之间是采用P2P(对等网络)架构实施的，因此访问其中任意一个站点就基本等于访问了UDDI Registry。

　　UDDI Operator Site (UDDI注册中心操作入口站点，简称UDDI操作入口): UDDI Operator Site是UDDI Registry中每一个对等结点，对于UDDI Operator Site的查询所获得的结果是覆盖全UDDI Registry中的信息的，信息查询无需身份认证；而在UDDI Operator Site上进行信息发布则必须使用该UDDI Operator Site自身的用户方能实施，同时以后的更新、删除都必须通过这个Operator Site，并使用初始发布时使用的用户进行权限认证。

　　Compatible UDDI Registry(兼容的UDDI注册中心): 所有兼容UDDI规范但并非属于提供公共服务的UDDI Registry的个别UDDI注册中心，都称为兼容的UDDI注册中心。

　　UDDI – 技术发现层

　　统一描述、发现和集成协议(UDDI)规范一个由Web服务所构成的逻辑上的云状服务，同时也定义了一种编程接口，这种编程接口提供了描述Web服务的简单框架。规范包括几份相关的文档和一份XML Schema ，用来定义基于SOAP的注册和发现Web服务的协议。这些规范由来自多家业界主要公司的技术人员和管理人员花费了几个月的时间制定完成。这些公司也担负起实现第一批UDDI商业注册中心服务的任务，这些服务将可以被所有人所访问，同时其多个合作站点之间能够无缝地共享注册信息。

　　下图描述了UDDI规范、XML Schema和UDDI商业注册中心集群之间的关系，UDDI商业注册中心集群能为Web服务提供”一次注册，到处发布”的功能。

　　>Figure 1. UDDI规范、XML Schema和UDDI商业注册中心集群之间的关系
 
　　UDDI规范和调用模式用来在Internet上建立起发现服务。这些发现服务提供了一致的发布接口，以使得能通过编程进行发现。

　　通过使用UDDI的发现服务，企业可以单独注册那些希望被别的企业发现的自身提供的Web服务。企业可以通过UDDI商业注册中心的Web界面，或是使用实现了”UDDI Programmer’s API标准”所描述的编程接口的工具，来将信息加入到UDDI的商业注册中心。UDDI商业注册中心在逻辑上是集中的，在物理上是分布式的，由多个根节点组成，相互之间按一定规则进行数据同步。当一个企业在UDDI商业注册中心的一个实例中实施注册后，其注册信息会被自动复制到其它UDDI根节点，于是就能被任何希望发现这些Web服务的人所发现。

　　P2P(Peer to Peer)数据同步

　　在UDDI的核心系统实施中，采用的是P2P(Peer to Peer)的体系架构。从UDDI Registry的外部来看，UDDI Registry对于用户而言是一个整体的服务，而不同的UDDI操作入口站点(Operator Site)是整个UDDI Registry服务的不同的访问入口，用户信息是与访问入口相关联的，而用户注册的信息在查询上与访问入口无关，所有用户可以任意选择UDDI操作入口站点(Operator Site)进行信息查询，获得的数据的范围是覆盖所有UDDI Registry中逻辑存在的数据的。UDDI操作入口站点(Operator Site)的职责是具备注册数据的托管权，每个注册数据条目的所有权有两级，第一层次它是属于某个操作入口站点的，第二层次它是属于某个操作入口站点上注册的用户(发布者)的。值得注意的是，不同的操作入口站点可以有不同的用户认证机制和不同的用户管理方法。

　　由于在逻辑上，在一个UDDI操作入口站点(Operator Site)上进行查询等同于对整个UDDI注册中心(Registry)进行查询。而且由于UDDI Registry是由若干个公司，如IBM、Microsoft、HP一起提供服务的，按照商务的一般规律，很难设置一个独立的中央数据库作为所有操作入口站点的后台注册数据库。从商务上而言，采用分布式对等系统是最合适的，也能够调动所有提供服务的公司的最大积极性。

　　实现对等系统，完成”一次注册，到处发布”，有两种方案：

　　第一种方案是，查询分发和重定向，当一个UDDI操作入口站点(Operator Site)接受到一个查询请求后，除了在本地进行查询外，还将该查询分发和重定向到其他所有UDDI操作入口站点(Operator Site)，并获得查询结果后与本地的查询结果整合后一起返回给查询者。

　　这种方式在过去的手工作坊式的服务整合的阶段是很常用的，好处是系统实现简单，只需要为每个被集成服务增加一个查询接口，而自身的体系不用有太多改变。当然缺点也是显而易见的，首先这种方式只适用于集成查询低发生机率的场合，当集成查询是频繁的时候，必然造成同一信息的反复的传输，造成资源浪费。而对于UDDI注册中心服务而言，每一项查询都必须在信息全集合中进行，也就是说任意一个查询请求都必将被分发并重定向到每一个其他的操作入口，这将带来不必要的服务负担。

　　第二种方案是，数据复制与同步。这一方案也是UDDI注册中心内部实际使用的方案。当一个UDDI操作入口站点(Operator Site)接受到一个数据新增、更新和删除的操作，除在本地执行外，还需要将该操作分发和重定向到其他所有UDDI操作入口站点(Operator Site)以执行数据的新增、更新和删除的操作，这样，在所有的UDDI操作入口站点(Operator Site)内部都维护了一个UDDI注册中心的注册信息的全集。使用这种方法的好处是显而易见的，只有必要的数据变更消息在UDDI操作入口站点之间传输，这些传输在广义上是满足传输最小集的。同时所有查询都将在本地进行，对于服务质量也有很大提升。

　　然而在这种情况下，对于查询优先的UDDI注册服务而言，虽然服务质量改善了，减少了冗余的数据传输。但是有一些重要的服务特性需要被考虑：

　　·同步操作的授权, 由于UDDI服务的所有访问都是通过SOAP/API来实施的，而数据发布的相关操作也是如此。数据发布是需要经过认证授权的，而每个操作入口站点用户认证机制又是彼此独立的，因此需要设置一种专门的用于站点间数据同步的认证令牌。
　　·数据同步消息的正确性，由于数据同步操作是非常重要和敏感的，需要尽可能避免信息的错误更新。因此需要对数据同步消息进行严格的消息检查和验证。
　　·错误恢复的处理，当数据同步消息发生错误的时候，需要提供一种便捷安全的方法进行错误恢复，比如要求源操作入口站点重发数据同步消息等。
　　·对新操作入口站点加入的支持，当有新的操作入口站点加入时，就应当有区别与一般数据同步操作的数据复制操作的发生，每个操作入口站点都应当将其拥有托管权的数据复制到新的操作入口站点，之后再对该操作入口站点执行数据同步操作。

　　下图是对这样一种体系架构的概要描述，对外是查询/发布API，是面向用户的，对内是同步/复制API，是面向站点的。

　　Figure 2. UDDI API架构
 
　　关于查询和发布API是属于UDDI规范V1版本的，在后面我给出详细介绍，而对于同步和复制API是属于UDDI规范V2版本的，我将在以后的文章里面作阐述。

　　UDDI信息模型

　　UDDI注册使用的核心信息模型由XML Schema定义。使用XML是因为它提供了平台无关的数据描述并很自然的描述了数据的层次关系。而选择XML Schema是因为它支持丰富的数据类型，便捷的描述方式及其按信息模型对数据进行验证的能力。

　　UDDI XML Schema定义了四种主要信息类型，它们是技术人员在需要使用合作伙伴所提供的Web 服务时必须了解的技术信息。它们是：商业实体信息(businessEntity)、服务信息(businessService)、绑定信息(bindingTemplate)和服务调用规范(tModel)的说明信息。

　　Figure 3. UDDI信息模型
 
　　查询API与发布API

　　查询API包含两类调用，使程序能快速地定位候选商业实体、Web服务及其调用规范，然后在最初调用获得的初始信息的基础上，获得进一步的相关信息的细节。这类以find_xx命名的API提供了多种搜索标准，从而能对注册中心中的数据进行广泛地搜索。另一方面，如果事先已经知道所需数据的关键字，则可以通过直接调用get_xx API得到相应的结构数据(如：businessEntity、businessService、bindingTemplate、tModel)。

　　发布API包括四个save_xx函数和四个delete_xx函数，每个对应于一个UDDI主要结构(businessEntity，binsinessService，bindingTemplate，tModel)。一旦得到授权，一个独立的机构可以注册任意数量的businessEntity或tModel信息，也可以修改原先发布的信息。API设计模型很简单：可以更改特定的相关信息，也可以使用save功能来保存新信息。要删除整个结构则可以调用delete功能。详细信息请参见程序员API规范(Programmer’s API Specification)。

　　关于作者

　　柴晓路: 上海得易电子商务技术有限公司( DealEasy)首席系统架构师、XML技术顾问。2000年获复旦大学计算机科学硕士学位，曾在国际计算机科学学术会议(ICSC)、亚太区XML技术研讨会(XML Asia/Pacific’99)、中国XML技术研讨会(北京)、计算机科学期刊等各类国际、国内重要会议与期刊上发表论文多篇。专长于基于XML的系统集成和数据交换的技术研究，同时对数据库、面向对象技术及CSCW等技术比较擅长。2001年加入UDDI Advisor Group，参与了UDDI Specification V2的开发。目前在与UDDI.org合作筹备 UDDI-China.org，后者将在2001年6月进行技术中心站点发布。