本文就UDDI注册信息的数据模型进行了较深入的介绍，主要详细介绍了商业实体信息：businessEntity元素, 商业服务信息：businessService元素, 技术绑定信息：bindingTemplate元素和元技术信息:tModel元素，同时就bindingTemplete的缓存和重定向机制作了详细的介绍，在以后的文章里面我将就tModel进行更深入地讨论。

　　统一描述、发现和集成协议(UDDI)标准包括了SOAP消息的XML Schema(UDDI Data Structure Reference)和UDDI规范API(UDDI Programmer’s API)的描述。它们两者一起建立了基础的信息模型和交互框架，具有发布各种Web 服务描述信息的能力。其中交互框架是为UDDI Client(可能是各种企业软件)与UDDI Registry进行交互的消息约定，我们将在以后进行讨论。

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

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

　　数据模型概览

　　UDDI XML Schema 定义了四种主要的信息类型，它们是技术人员在需要使用合作伙伴所提供的Web 服务时必须了解的技术信息。它们是：商业实体信息(businessEntity结构)、服务信息(businessService结构)、绑定信息(bindingTemplate结构)和技术规范信息(tModel结构)。UDDI注册信息的整体数据模型可以参阅下图。

　　Figure 1. UDDI数据模型关系图
 
　　在UDDI的数据模型中，tModel是一个很特殊的数据项。tModel描述了一切技术信息， tModel的全体组成了UDDI中的所有技术注册信息。在后面的tModel节我将给出tModel的彼此关联的细节内容。

　　商业实体信息:businessEntity元素

　　在商业领域内，合作伙伴和潜在的合作伙伴都期望能准确地定位到商业实体所能提供的服务或产品的相关信息，并把这些信息作为了解你们企业的开始。而在技术领域，技术人员、程序员或应用程序都期望能知道他们需要集成的商业实体的名称和一些关键性的标识，以及该商业实体是属于那个具体工业分类之类的分类信息，以及联络方法(包括Email、电话、URL)等。支持对UDDI 商业注册的商业信息发布和发现的核心XML 元素都包含在"businessEntity"结构中。这个结构是商业实体专属信息集的最高层的数据容器，位于整个信息结构的最上层。

　　所有"businessEntity"中的信息支持"黄页"分类法。因此可以执行这样的搜索，如可以定位属于某个行业分类或提供某种产品的企业，也可以是定位处于某个地域范围内的企业。目前在UDDI中内置的分类法包括NAICS工业分类法、UN/SPSC产品分类法等。

　　下面是businessEntity结构的XML Schema定义:

<element name = "businessEntity">
<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的直接属性分别表示：businessEntity的主键、实施注册的UDDI操作入口站点以及对该businessEntity拥有所有权的用户ID。一般的，businessKey是在注册后由UDDI注册中心自动赋予，并在businessEntity整个生命周期中有效。以后仅能通过authorizedName指定的用户ID在由operator指定的操作入口站点上进行该businessEntity的信息更新和对象删除，任意其他ID不能操纵本对象，同时也不能在其他操作入口站点上对该实体对象的数据进行维护。在V2的规范中，将会出现操作入口站点迁移和所有权迁移的API，但目前在V1的规范中没有这项支持。

　　discoveryURLs是一个充分体现UDDI的发现(discover)能力，这个结构包含了多个discoveryURL，访问其中的每个discoveryURL都应当可以获得这个businessEntity的完整XML文本(这个XML文本的顶级元素一定是businessEntity)。name、description和contacts分别表示该商业实体的名、描述和联系方法等。

　　businessServices是一个businessService的容器，它表示了这个businessEntity所能提供的所有Web服务。在businessServices中的每个businessService条目都描述了一个Web服务。这个结构表达了businessEntity和businessService的父子包含关系。

　　我们知道，UDDI支持多种查询方式，可以通过传统的商业实体的标识进行查询，也可以使用工业分类法进行查询。identifierBag和categoryBag就是为这样的查询提供的统一的支持，不但在businessEntity中，在businessService和tModel中也有这样的支持。关于identifierBag和categoryBag我将在以后的专门介绍tModel的文章加以详细描述。在identifierBag中信息表达的例子是描述了商业实体的D&B D-U-N-S Number?，而categoryBag中信息表达的例子可能是UN/SPEC规范中的某个分类标识。