第六章
统一描述、发现和集成协议（Universal Description, Discovery and Integration, UDDI）是一套基于Web的分布式的Web Services信息注册中此乃的实现标准规范。
1、工作原理
UDDI的工作方式和邮局公开发行的电话黄页类似，它可以把特定的企业信息和Web Services 在Internet上广而告之，并且提供具体的联系地址和方式。
** UDDI商业注册中心所提供的信息从概念上来说分为三个部分：
白页（white page）表示与企业有关的基本信息，包括企业名称、经营范围、联系地址、企业标识等；
黄页（yellow page）依据标准分类法区分不同的行业类别，使企业能够在更大的范围（如地域范围）内查找已经在注册中心注册的企业或Web Services;
绿页（green page）则包括企业所提供的Web Services的技术信息，其形式可能是一些指向文件或是URL的指针，而这些文件或URL是服务发现机制的必要组成部分。
** UDDI的具体工作步骤如下：
* 软件公司、标准化组织和程序员定义了企业如何在UDDI中注册的规则后，开始向UDDI注册中心发布这些规则的描述信息。这些规则被称为技术模型（即tModel）
* 企业向UDDI注册中心注册关于该企业及其提供的Web Services的描述；
* UDDI注册中心会给每个实体（tModel以及企业）指定一个在相关程序中唯一的标识符UUID(通用唯一标识符，Universally Unique ID)。UUID可以用来引用与之相关联的实体。
* 电子交易场所和搜索引擎等其他类型的客户和商务应用程序使用UDDI注册中心来发现它们感兴趣的Web Services。
* 其他的企业就可以调用这些服务，方便、迅速地进行商务应用程序的动态集成。
** UDDI注册中心里的四类数据：
* 商业实体（businessEntity），发布服务信息的商业实体的详细信息，包括企业名称、关键性的标识、可选的分类信息和联络方法等。
* 服务信息（businessService），一组特定的技术服务的描述信息。该信息是“绿页”数据的重要组成部分，是对Web Services的技术和商业描述。businessService结构是一个描述性容器，它组合了一系列的有关商业流程或分类目录的Web Services的描述信息。
* 绑定模板（bindingTemplate），关于Web Services的入口点和相关技术规范的描述信息。
* 技术模型（tModel），Web Services或分类法的规范性描述信息，也就是关于调用规范的元数据，包括Web Servicces名称、注册Web Services的企业信息和指向这而规范本身的URL指针等。
2、UDDI数据信息模型
* businessEntity元素
<element name="businesssEntity">
<type content="elementOnly">
<group order="seq">
<element ref="discoveryURLs" minOccurs="0" maxOccurs="1" />
<element ref="name" />
<element ref="description" minOccurs="0" maxOccurs="*" />
<element ref="contacts" minOccurs="0" maxOccurs="1" />
<element ref="businessServices" minOccurs="0" maxOccurs="1" />
<element ref="identifierBag" minOccurs="0" maxOccurs="1" />
<element ref="categoryBag" minOccurs="0" maxOccurs="1" />
</group>
<attribute name="businessKey" minOccurs="1" type="string" />
<attribute name="operator" type="string" />
<attribute name="authorizedName" type="string" />
</type>
</element>
其中businessKey、operator和authorizedName分别表示businessEntity的主键、实施注册的UDDI操作入口站点以及该businessEntity拥有所有权的用户ID。
discoveryURLs，包含多个discoveryURL，访问其中的每个discoveryURL都可以获得这个businessEntity的完整XML文本。 name表示该商业实体的名字、description表示该实体的描述、contacts表示联系方法。businessServices是一个businessService的容器，它表示这个businessEntity所能提供的所有Web Services。
UDDI支持多种查询方式，可以通过传统的商业实体的标识进行查询，也可以使用行业分类法进行查询。identifierBag和categoryBag为这样的查询提供了统一的支持。
* businessService元素
<element name="businessService">
<type content="elementOnly">
<group order="seq">
<element ref="name" />
<element ref="description" minOccurs="0" maxOccurs="*" />
<element ref="bindingTemplates" />
<element ref="categoryBag" minOccurs="0" maxOccurs="1" />
</group>
<attribute name="serviceKey" minOccurs="1" type="string" />
<attribute name="businessKey" type="string" />
</type>
</element>
serviceKey表示businessService的主键，businessKey表示businessService的父类容器businessEntity的主键标识。
name表示该服务的名字，description表示服务的描述信息，categoryBag提供查询支持。bindingTemplates是一个bindingTemplate的容器，它表示这个businessService所包含的所有技术绑定信息。
* bindingTemplate元素
<element name="bindingTemplate">
<type content="elementOnly">
<group order="seq">
<element ref="description" minOccurs="0" maxOccurs="*" />
<group order="choice">
<element ref="accessPoint" minOccurs="0" maxOccurs="1" />
<element ref="hostingRedirector" minOccurs="0" maxOccurs="1" />
</group>
<element ref="tModelInstanceDetails" />
</group>
<attribute name="bindingKey" minOccurs="1" type="string" />
<attribute name="serviceKey" type="string" />
</type>
</element>
bindingKey表示bindingTemplate的主键，serviceKey表示bindingTemplate的父类容器businessService的主键标识。tModelInstanceDetails包含了这个bindingTemplate所定位的调用入口的调用规范描述，这些描述都以tModel的形式出现。tModel在bindingTemplate中以引用关系存在。
accessPoint定义了由这个bindingTemplate描述的服务调用入口的访问地址，用户可以通过这个地址访问具体的服务。hostingRedirector则是accessPoint无法满足需求时的一种替代机制，同时hostingRedirector也是在当前电子交易市场、ISP等中间机构存在的情况下的一种强有力的描述托管机制。
* tModel元素
每一个bindingTemplate元素都包含一个特殊的元素tModel，该元素包含一个列表，列表的每个子元素分别是一个调用规范的引用。
<element name="tModel">
<type content="elementOnly">
<group order="seq">
<element ref="name" />
<element ref="description" minOccurs="0" maxOccurs="*" />
<element ref="overviewDoc" minOccurs="0" maxOccurs="1" />
<element ref="identifierBag" minOccurs="0" maxOccurs="1" />
<element ref="categoryBag" minOccurs="0" maxOccurs="1" />
</group>
<attribute name="tModelKey" minOccurs="1" type="string" />
<attribute name="operator" type="string" />
<attribute name="authorizedName" type="string" />
</type>
</element>
tModelKey表示tModel的主键，operator是实施注册的UDDI操作入口站点，authorizedName是对该tModel拥有所有权的用户ID。overviewDoc包含的是规范的关键信息，包含了一系列的URL，通过这些URL可以访问到这个tModel的具体技术规范文本。
3、UDDI的注册、查找与发布
（1）、UDDI的分类法与标识系统
businessEntity、businessService以及tModel等实体信息附加了类别信息以及标识信息等信息。
类别信息（属于某个分类法下的某个类别），是使用categoryBag元素来指定的，其中包含具备命名空间修饰的对分类法键值和描述的引用。
标识信息（在某个标识系统中拥有一个标识），是使用identifierBag元素来指定的，其中包含了具备命名空间修饰的对标识符和描述的引用。
UDDI规范1.0版中内置了三个分类法：
** NAICS行业分类法。
** UN/SPSC产品分类法。
** ISO 3166地理分类法。
UDDI规范1.0版内置了两个标识系统：
** Dun & Bradstreet D-U-N-S? Number标识符
此标识符表示一旦注册中心开始运行，这个tModel就会被传送到Dun & Bradstreet信息发布者那里进行管理。
** Thomas Registry Suppliers标识符
此标识符表示一旦注册中心开始运行，这个tModel的监管权将被移交给Thomas注册中心的信息发布者。
UDDI1.0中内置的分类法和标识系统是美国的商业惯例。全球各地的分类法和标识体系不可能全部加到UDDI中，因此为了解决如何提供种类繁多的分类法和标识系统，来满足全球用户的需要，又无需太多地增加UDDI注册中心的运作代价。UDDI规范2.0引入了已校验（checked）的外部命名空间的概念。
外部命名空间描述的外部分类法或标识系统的工作流程如下：
* 分类法（或标识系统）提供商首先将其自身提供的分类法的技术信息注册到UDDI注册中心，然后在UDDI注册中心注册与该分类法对应的分类校验服务（Taxonomy Validation Service）。
* 商业实体将自身信息注册到UDDI注册中心，同时采用外部的分类法提供商提供的分类法对其信息加以分类。
* UDDI注册中心发现这个外部分类，因此调用外部的与该分类法对应的分类校验服务来实施校验，如果校验成功则实体包含的相关分类信息被标注为已校验，否则就被标注为未通过校验。
（2）、UDDI的API介绍
UDDI的API是用于商业实体、Web Services和绑定信息的发布与发现的一套请求/响应机制。
UDDI的API中定义了两类API，即发布API和查询API。发布API主要用于在UDDI注册中心之间修改和存储注册信息，需要通过授权才能访问。而查询API主要用于从注册中心读取Web Services的相关信息，不需要通过授权。
4、从WSDL到UDDI的映射
一个完整的WSDL服务描述是由一个服务接口和一个服务实现文档组成的，由于服务接口标识服务的可重用定义，因此它在UDDI注册中心被作为tModel发布。服务实现描述服务的实例，每个实例都是使用一个WSDL Service元素定义的。服务实现文档中的每个Service元素都用于发布UDDI businessService。