理解UDDI(2)：UDDI注册信息的数据模型
(本文最初由 IBM developerWorks 中国网站发表，其网址是http://www.ibm.com/developerWorks/cn/)
(本文是我在developerWorks专栏发表的UDDI 注册信息的数据模型，需要浏览未缩减版原文，请访问http://www.ibm.com/developerWorks/cn/)
统一描述、发现和集成协议(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 XML Schema 定义了四种主要的信息类型，它们是技术人员在需要使用合作伙伴所提供的Web 服务时必须了解的技术信息。它们是：商业实体信息(businessEntity结构)、服务信息(businessService结构)、绑定信息(bindingTemplate结构)和技术规范信息(tModel结构)。在UDDI的数据模型中，tModel是一个很特殊的数据项。tModel描述了一切技术信息， tModel的全体组成了UDDI中的所有技术注册信息。在后面的tModel节我将给出tModel的彼此关联的细节内容。
商业实体信息: businessEntity元素
在商业领域内，合作伙伴和潜在的合作伙伴都期望能准确地定位到商业实体所能提供的服务或产品的相关信息，并把这些信息作为了解你们企业的开始。而在技术领域，技术人员、程序员或应用程序都期望能知道他们需要集成的商业实体的名称和一些关键性的标识 ，以及该商业实体是属于那个具体工业分类之类的分类信息，以及联络方法(包括Email、电话、URL)等。支持对UDDI 商业注册的商业信息发布和发现的核心XML 元素都包含在“businessEntity”结构中。这个结构是商业实体专属信息集的最高层的数据容器，位于整个信息结构的最上层。
商业服务信息：businessService元素
businessService 结构将一系列有关商业流程或分类目录的Web 服务的描述组合到一起。businessService和下面要提到的bindingTemplate一起构成了“绿页”信息。其中，一个可能的商业流程的例子是一组相关的Web 服务信息，包括采购服务、运输服务和其它的高层商业流程。这些服务都将是提供这些商业流程服务的商业实体所需要注册的Web服务。
这些businessService的信息集合可以再次加以分类，使Web应用服务的描述可以按不同的行业、产品、服务类型或是地域划分来进行。分类的方法的机制与businessEntity是类似的。
技术绑定信息：bindingTemplate元素
对于每一个businessService，存在一个或多个Web 服务的技术描述bindingTemplate。这些技术描述包括应用程序连接远程Web 服务并与之通讯所必须的信息。这些信息包括Web应用服务的地址、应用服务宿主和调用服务前必须调用的附加应用服务等。另外，通过附加的特性还可以实现一些复杂的路由选择，诸如负载平衡等。
元技术信息：tModel元素
调用一个服务所需要的信息是在bindingTemplate的结构中定义的，这在前面一节中已经阐述了。不过一般来说，仅知道Web服务所在的地址是不够的。例如，如果我知道我的合作伙伴提供一个Web服务来让我下订单，同时也知道这个服务的URL，不过如果不知道一些具体的信息，如订单的具体格式，应该使用的协议，需要采用的安全机制，调用返回的响应格式等，那样的话，通过Web服务将两个系统集成起来仍然是非常困难的。
当一个程序或是程序员需要调用某个特定的Web服务时，必须根据应用要求得到了足够充分的调用规范等相关信息，以使调用被正确地执行。因此，每一个bindingTemplate元素都包含一个特殊的元素，该元素包含了一个列表，列表的每个子元素分别是一个调用规范的引用。这些引用作为一个标识符的杂凑集合 ，组成了类似指纹的技术标识，用来查找、识别实现了给定行为或编程接口的Web 服务。
