原文地址：http://hi.baidu.com/pennyfeifei/blog/item/bbccee1f31039860f624e4fd.html
本文就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的彼此关联的细节内容。
  |
|
在商业领域内，合作伙伴和潜在的合作伙伴都期望能准确地定位到商业实体所能提供的服务或产品的相关信息，并把这些信息作为了解你们企业的开始。而在技术领域，技术人员、程序员或应用程序都期望能知道他们需要集成的商业实体的名称和一些关键性的标识，以及该商业实体是属于那个具体工业分类之类的分类信息，以及联络方法(包括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规范中的某个分类标识。
|
|
businessService 结构将一系列有关商业流程或分类目录的Web 服务的描述组合到一起。businessService和下面要提到的bindingTemplate一起构成了"绿页"信息。其中，一个可能的商业流程的例子是一组相关的Web 服务信息，包括采购服务、运输服务和其它的高层商业流程。这些服务都将是提供这些商业流程服务的商业实体所需要注册的Web服务。
这些businessService的信息集合可以再次加以分类，使Web应用服务的描述可以按不同的行业、产品、服务类型或是地域划分来进行。分类的方法的机制与businessEntity是类似的。
下面是businessService结构的XML Schema定义:
<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和businessKey两个直接属性分别表示businessService的主键和businessService的父类容器businessEntity的主键标识。一般的，serviceKey是在注册后由UDDI注册中心自动赋予，并在businessService整个生命周期中有效。而businessKey的值仅当businessService的父类容器发生变化时才会被修改。
name、description分别表示该服务的名、描述等信息。categoryBag的作用与businessEntity中是类似的。
bindingTemplates是一个bindingTemplate的容器，它表示了这个businessService所包含的所有技术绑定信息。在bindingTemplates中的每个bindingTemplate条目都是本Web服务的一条技术描述信息。这个结构表达了businessService和bindingTemplate的父子包含关系。
|
|
对于每一个businessService，存在一个或多个Web 服务的技术描述bindingTemplate。这些技术描述包括应用程序连接远程Web 服务并与之通讯所必须的信息。这些信息包括Web应用服务的地址、应用服务宿主和调用服务前必须调用的附加应用服务等。另外，通过附加的特性还可以实现一些复杂的路由选择，诸如负载平衡等。
下面是bindingTemplate结构的XML Schema定义:
<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和serviceKey两个直接属性分别表示bindingTemplate的主键和bindingTemplate的父类容器businessService的主键标识。一般的，bindingKey是在注册后由UDDI注册中心自动赋予，并在bindingTemplate整个生命周期中有效。而serviceKey的值仅当bindingTemplate的父类容器发生变化时才会被修改。
tModelInstanceDetails包含了这个bindingTemplate所定位的调用入口的调用规范的描述，这些描述都以tModel的形式出现。事实上，tModel并不是bindingTemplate的子元素，这里应该理解成引用关系。
accessPoint定义了由这个bindingTemplate描述的服务调用入口的访问地址，用户可以通过这个地址访问具体的服务。而hostingRedirector则是因为accessPoint无法满足需求而提供的替代机制，同时hostingRedirector机制也是一种及为有效的满足当前电子交易市场、ISP等中间机构存在的情况下的强有力的描述托管机制。
两种不能被bindingTemplate中accessPoint信息直接支持的特殊需求是：
- Web服务在技术上由第三方提供主机: 一个商业实体可以选择这样一种方式来发布一种服务，该服务逻辑上属于本企业，但实际上该服务是在远程的或者第三方的主机上运行的。应用服务提供商和网络交易市场运营商是这种情况的典型代表。在这种情况下，实际上是第三方实际控制绑定信息的运行时态的取值。
- 用户指定的对绑定位置的访问控制: 在其他情况中，比如情景相关的重定向是基于调用者的标识的，或者甚至是每天的路由，此时，提供更动态的对远程服务的实际联络信息的方式是非常必需的，相比起缓存accessPoint数据以支持调用的方式更为必要。关于对bindingTemplate信息的缓存机制请参阅本文后面的相关小节。
|
|
由于这些原因，bindingTemplate结构包括一个备用的数据元素，被称为hostingRedirector。hostingRedirector元素的存在和accessPoint信息是互斥的。这样使我们得以知道到底应该如何获取包含所需要使用的accessPoint数据的实际bindingTemplate信息，使用hostingRedirector或accessPoint。
|
|
调用一个服务所需要的信息是在bindingTemplate的结构中定义的，这在前面一节中已经阐述了。不过一般来说，仅知道Web服务所在的地址是不够的。例如，如果我知道我的合作伙伴提供一个Web服务来让我下订单，同时也知道这个服务的URL，不过如果不知道一些具体的信息，如订单的具体格式，应该使用的协议，需要采用的安全机制，调用返回的响应格式等，那样的话，通过Web服务将两个系统集成起来仍然是非常困难的。
当一个程序或是程序员需要调用某个特定的Web服务时，必须根据应用要求得到了足够充分的调用规范等相关信息，以使调用被正确地执行。因此，每一个bindingTemplate元素都包含一个特殊的元素，该元素包含了一个列表，列表的每个子元素分别是一个调用规范的引用。这些引用作为一个标识符的杂凑集合，组成了类似指纹的技术标识，用来查找、识别实现了给定行为或编程接口的Web 服务。
在我们的订单例子中，接受订单的Web 服务提供了一套定义良好的处理方法，当然前提是格式正确的信息以正确的方式被送到了正确的地点。这项服务的UDDI 注册将包括这些内容：用于描述商业合作伙伴的信息条目，描述订单服务的逻辑服务的信息条目，描述订单服务技术调用规范的bindingTemplate信息条目，其中bindingTemplate信息条目包含了服务的URL 和一个tModel引用。
实际上，这些引用是访问服务所需要的关键的调用规范信息。被称为"tModel"的数据项是关于调用规范的元数据，它包括服务名称，发布服务的组织以及指向这些规范本身的URL指针等。在我们的例子中，在bindingTemplate中可以得到指向描述订单服务的关于调用规范的信息的tModel引用。这个引用本身可以被看作是提供这项Web 服务的公司的承诺，承诺他们已经实现了一个与所引用的tModel 相兼容的服务。通过这种方式，很多公司可以提供与该调用规范相兼容的Web 服务。
下面是tModel结构的XML Schema定义:
<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，operator，和authorizedName这三个tModel的直接属性分别表示：tModel的主键、实施注册的UDDI操作入口站点以及对该tModel拥有所有权的用户ID。一般的，tModelKey是在注册后由UDDI注册中心自动赋予，并在tModel整个生命周期中有效。以后仅能通过authorizedName指定的用户ID在由operator指定的操作入口站点上进行该tModel的信息更新和对象删除，任意其他ID不能操纵本对象，同时也不能在其他操作入口站点上对该实体对象的数据进行维护。在V2的规范中，将会出现操作入口站点迁移和所有权迁移的API，但目前在V1的规范中没有这项支持。
overviewDoc包含的是规范的关键信心，包含了一系列的URL，通过这些URL可以访问到这个tModel的具体技术规范文本。
|
|
当我们要编制实现一个应用程序，该应用程序需要使用一个已被其它商业实体注册在UDDI注册中心的远端Web服务，就需要从注册中心中发现为调用指定服务所需要的调用规范信息，并在程序编制时使用。这种类型的跨商业实体的服务调用在传统上将被视为是开发阶段的任务。尽管，这样的开发模式并不会因UDDI注册信息的出现而完全改变，但起码，如果使用了UDDI注册所支持的特别的调用模式，将可以解决一个非常显著而重要的问题。
从UDDI注册中心中获得的bindingTemplate信息集中的数据表示了一个指定的远端Web服务的调用规范实例。程序应当缓存该信息并且使用这个调用规范通过该Web服务注册的地址来访问这个Web服务。使用以前流行的远程过程调用技术的工具已经能够将这样一种工作自动化地实现，无论是通过缓存其调用位置或是通过写入固定代码的方式，都可以做到。然而，当远程服务在没有通知调用者的情形下发生了迁移，那么就会引起问题，该程序无法自动地更新访问代码或访问地址。这样的迁移可以是由各种原因造成的，包括服务器升级，灾难恢复以及服务入口或企业名称的改变等。
当使用从UDDI注册表中获得并缓存下来的信息进行调用发生失败时，正确的做法是去查询当初获得该数据的UDDI注册中心并获取与其对应的更新了的bindingTemplate信息。正确的调用是使用get_bindingDetails，并传入原始的bindingKey键值。如果返回的数据与缓存的信息不同，那么应该使用新的调用信息来重新尝试服务调用。如果这一重试操作获得成功的话，新的信息应当取代原先缓存的信息进入当前的缓存。
在使用Web服务中，使用这样的调用模式，那么使用UDDI操作入口站点(Operator Site)的商业实体就得以在不加重通信与协调开销的情况下自动完成与大量合作伙伴的服务恢复。例如，如果一个企业激活了一个灾难恢复站点以取代某个崩溃的原服务提供站点，来自合作伙伴的大部分调用想访问那个已经崩溃的服务提供站点时，会遭遇失败。通过把新的提供服务的地址更新到UDDI信息中，那些使用调用模式的合作者将可以自动地获取新的服务调用信息并在无需管理员介入的情况下恢复系统连接。
扫一扫
276
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
