元技术信息：tModel元素

　　调用一个服务所需要的信息是在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的具体技术规范文本。

　　缓存bindingTemplate

　　当我们要编制实现一个应用程序，该应用程序需要使用一个已被其它商业实体注册在UDDI注册中心的远端Web服务，就需要从注册中心中发现为调用指定服务所需要的调用规范信息，并在程序编制时使用。这种类型的跨商业实体的服务调用在传统上将被视为是开发阶段的任务。尽管，这样的开发模式并不会因UDDI注册信息的出现而完全改变，但起码，如果使用了UDDI注册所支持的特别的调用模式，将可以解决一个非常显著而重要的问题。

　　从UDDI注册中心中获得的bindingTemplate信息集中的数据表示了一个指定的远端Web服务的调用规范实例。程序应当缓存该信息并且使用这个调用规范通过该Web服务注册的地址来访问这个Web服务。使用以前流行的远程过程调用技术的工具已经能够将这样一种工作自动化地实现，无论是通过缓存其调用位置或是通过写入固定代码的方式，都可以做到。然而，当远程服务在没有通知调用者的情形下发生了迁移，那么就会引起问题，该程序无法自动地更新访问代码或访问地址。这样的迁移可以是由各种原因造成的，包括服务器升级，灾难恢复以及服务入口或企业名称的改变等。

　　当使用从UDDI注册表中获得并缓存下来的信息进行调用发生失败时，正确的做法是去查询当初获得该数据的UDDI注册中心并获取与其对应的更新了的bindingTemplate信息。正确的调用是使用get_bindingDetails，并传入原始的bindingKey键值。如果返回的数据与缓存的信息不同，那么应该使用新的调用信息来重新尝试服务调用。如果这一重试操作获得成功的话，新的信息应当取代原先缓存的信息进入当前的缓存。

　　在使用Web服务中，使用这样的调用模式，那么使用UDDI操作入口站点(Operator Site)的商业实体就得以在不加重通信与协调开销的情况下自动完成与大量合作伙伴的服务恢复。例如，如果一个企业激活了一个灾难恢复站点以取代某个崩溃的原服务提供站点，来自合作伙伴的大部分调用想访问那个已经崩溃的服务提供站点时，会遭遇失败。通过把新的提供服务的地址更新到UDDI信息中，那些使用调用模式的合作者将可以自动地获取新的服务调用信息并在无需管理员介入的情况下恢复系统连接。

　　tModel体系

　　tModel是一个技术规范的超类，tModel能够描述商业标识符数据库、分类方法、技术规范、网络协议等各类的技术规范，我将在以后的专门介绍tModel的文章中详细阐述。

　　参考资料

　　UDDI技术规范及白皮书

　　UDDI Technical White Paper, Ariba Inc., IBM Corporation and Microsoft Corporation, 6 Sep 2000
　　UDDI Executive White Paper, Ariba Inc., IBM Corporation and Microsoft Corporation, 6 Sep 2000
　　UDDI Programmer’s API Specification, Ariba Inc., IBM Corporation and Microsoft Corporation, 27 Mar. 2001
　　UDDI Data Structure Reference, Ariba Inc., IBM Corporation and Microsoft Corporation, 30 Sep 2000

　　解决B2B电子商务应用交互和集成的InterOP Stack系列技术标准规范

　　Web Service Description Language (WSDL) 1.0, IBM, 25 Sep 2000
SOAP: Simple Object Access Protocol Specification 1.1, IBM, Microsoft, DevelopMentor, 2000
　　Extensible Markup Language (XML) 1.0 (Second Edition), W3C, 6 Oct 2000
XML Schema Part 0: Primer, W3C, 16 Mar 2001