tModel的用途及结构详解

文档选项 未显示需要 JavaScript 的文档选项

级别： 初级

柴晓路 (fennivel@uddi-china.org)Chief System Architect

2001 年 6 月 01 日

本文就UDDI注册数据模型中描述元数据的tModel进行了较深入的描述和介绍。主要详细介绍了tModel的机制，用途及XML表示的结构，详细分析了tModel是如何描述Web服务的技术指纹的，并为在以后的文章里介绍公用tModel体系奠定了基础。

tModel是UDDI数据模型中两个顶级数据实体(businessEntity和tModel)之一。tModel这个术语是多个概念的联合。按照UDDI规范中的描述，tModel被用于表示一个规范或一个概念的服务类型(Service Type)性概念。在目前的UDDI的实现中，有这样四种注册的服务类型："分类系统(Classification System)"、"标识系统(Identification system)" 、"抽象接口组件(abstract interface component)"和"规范(specification)"。tModel是这些服务类型在UDDI注册数据的承载体和表现形式，是Web服务描述的元数据。一个Web服务所包含的tModel的全体构成了这个Web服务的技术指纹，通过对这个技术指纹的分析，我们就可以很方便地了解该Web服务是符合那些技术规范的，采用怎样的调用界面的，以及其分类和标识的信息等。

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

什么是tModel?

为了达到让两个或更多的软件可以互相兼容，也就是说，为达到我们期望的互相交换数据的目标，他们必须共享一些设计目标和通用的规范。所有UDDI站点都支持的注册信息模型就是基于这样的共享规范的理念。

以前，为了架构一个具备兼容能力的软件，两个公司唯一可以执行的方式是，就使用同样的规范达成协议，然后基于该协议架构软件并测试。然而，如果使用UDDI，公司就需要以某种方式组织那些用于设计他们所提供的服务的软件接口规范及相应版本信息，并将其发布。为了识别不同的公共规范(或者在特定合作者间共享的私有规范)，规范本身的信息需要是可发现的。这种关于规范的信息，也就是传统上称作的元数据结构，我们在UDDI中称其为tModel。

tModel概念在发现那些被发布以供广泛使用的服务信息的场合下非常有用。为了让读者获得一个更清晰的理解，让我们考察以下示例。

例子:

假设您的企业购买了一个能通过您的网站自动接受电子定单的软件包。您可以通过使用某个公共UDDI站点，来为你自己的企业发布这个电子商务的服务。

您选购这个软件包的理由之一是它的应用广泛性。实际上，销售给您该软件包的那位销售员也着重提到了这个软件受到普遍好评的一个特性，那就是使用和支持了已被普遍应用的XML商务文档格式来实现自动的商务信息交换。

当您对该软件完成安装及配置后，它会自动查询某个公共UDDI站点来识别与该软件相兼容的商业伙伴。该软件通过查询您所指定的那些商业实体，并定位那些已经发布了与您的软件相兼容的电子商务服务的商业实体，来实现这个功能。

这个软件的配置过程是通过利用tModel的以下特性来实现的，由于已经为完整的软件界面规范注册了一个tModel，并且每个使用该软件界面规范的企业的订单服务都引用了这个完整规范的tModel的键值，因此这个匹配过程非常容易实现。

一般来说，把tModel的键和服务描述共同作为线索来跟踪一个指定的服务的兼容性源头是足够可靠的。由于许多服务都会被构建和实现成兼容于某个特定的规范，对该规范的具体信息(通过tModel条目来描述规范的具体信息或具体信息的URL，通过tModel引用来实现一般的规范引用)的引用(可以仅使用一个键值)就不需要在每个注册的电子商务服务中重复了。

对于企业商务软件的开发人员来说，tModel提供了一个通用方法，其作为一个通用引用点，使得兼容服务可以很简单地被识别。而对于使用该软件的企业来说，好处在于能够极大地缩短了识别特定服务是否与您的软件兼容的工作过程。最后，对于软件生产商和标准化组织来说，注册一个规范的相关信息，然后用该规范的的tModel来查找兼容的Web服务的实现，能帮助他们的客户真正获得使用被广泛应用的设计规范所带来的好处。

回页首

tModel结构概要

UDDI的一个重要目标是能够描述一个Web服务并且使得此描述在搜索的时候提供足够的语义支持。另一个目标则是提供一种机制使得这些描述足够有用：当你在不太了解一种服务的时候，可以通过这些描述来学习如何与此服务进行交互。为了做到这一点，必需有一种方法来给描述赋予足够的信息，这些信息包括服务的行为表现，服务遵循何种协议，或者是服务符合什么规范或标准。tModel 结构的任务之一就是提供对符合某种规范、概念甚至是某种共享设计的描述能力。

tModel 结构以由键标识的元数据的(关于数据的数据)形态存在。概括地理解，在UDDI注册中心里的tModel 结构的用途是提供一个基于抽象的引用系统。因而，tModel 结构所表示的数据类别是相当繁多的。换句话说，一条tModel 注册信息可以定义任何东西，但在目前的版本中，我们应用了两个约定，这两个约定分别将tModel 结构用作确定兼容性的来源以及由键标识的命名空间引用。

tModel 结构组成信息非常简单。它们包括一个键，一个名，一个可选的描述，以及一个指向某处的URL，可能好奇的人可以去那里找到tModel 结构中的元数据本身所代表的实际概念，也就是说这个URL可能指向的是一个规范文本或概念的文本。

回页首

主要用途

在businessEntity注册中，你会在两个地方发现tModel的引用。从这方面考虑，tModel是很特殊的。尽管businessEntity中的其他数据(例如businessService和bindingTemplate数据)都是作为唯一父businessEntity元素的一个唯一的由键标识的实例存在的，然而tModel却是以引用的形式被使用的。这意味着你可以在多个businessEntity数据集中，找到对某个tModel实例的多个引用。

回页首

定义技术指纹

tModel的主要角色是作为描述一种技术规范的机制存在。例如是一个概述有线协议的一种规范、交换格式的一种规范或是交换序列规则的一种规范。这样的一个规范可以在RosettaNet RNIF 1.0规范中被发现。其他例子可以在一些标准工作比如ebXML ，ECO 和各种电子文档交换(EDI)的工作中被找到。

通过通讯介质与其他软件通信的软件总是遵循某种预先议定的规范。在这样的情况下，规范的设计者可以通过使用tModel注册规范的信息，以达到在一个UDDI注册中心中建立一个唯一的技术标识的目的。

一旦通过这种方法注册之后，其他人就可以方便地用在他们的技术服务描述bindingTemplate数据中增加一个相应的tModel标识符(称为tModelKey)的引用来表示提供了符合某种规范的Web服务。

这种方法使得搜索已经注册的符合某特定规范的Web服务相当容易。一旦知道了正确的tModelKey值，你就可以知道某个商业实体是否注册了一个引用那个tModelKey的Web服务。这样，tModelKey就成为给定的规范的一种唯一的技术指纹。

以上描述了如何定义技术指纹，那么当要搜索那些符合特殊技术指纹的数据的时候，我们就需要在查询API中包含tModelBag结构。这些技术指纹是一些tModel的UUID键值的集合，通过与bindingTemplate所包含的tModel键值进行匹配而完成指纹的匹配。当用于搜索Web服务时(例如，通过使用bindingTemplate结构描述的数据来搜索)，这个由tModel键值组成的指纹概念允许用户使用指定的键值组合完成高灵活性的搜索。例如，存在一个Web服务，该Web服务实现了UDDI规范的所有部分，那么就可以通过指定一个tModel键值的集合来搜索到这个Web服务，这个tModel键值的集合中包含了所有描述UDDI规范的tModel(例如，UDDI规范可能被定义为5个不同的独立的可部署的tModel)。同时，我们也可以在上述的查询中减少指定的tModelKey的数量，以实现更广泛的搜索，搜索目标是寻找那些实现了部分UDDI规范的Web服务。所有的tModelKey值总是使用统一资源名(URN)格式表示，这种格式以"uuid:"开头，随后跟着一个标准格式的UUID，该UUID是由8个16位组组成，按照通常的12-4-4-8模式排列。

回页首

定义抽象的命名空间引用

其他用到tModel引用的地方是在定义组织身份标识和各种分类信息的identifierBag和categoryBag结构中。在这一上下文中，tModel引用表示了由键标识的名/值对与组织身份标识概念名之间的关联，或是表示了由键标识的名/值对与赋予这个名/值对具体语义的命名空间之间的关系。

举个例子，某商业实体可以通过这种方法表达这样一个事实：自己的美国税号标识符(他们的合伙人和客户一定知道这个)是一个特定的值。为了这样做，我们需要假设可以找到一个命名为"US Tax Codes"的tModel，它带有的描述是"由美国国内税务部定义的美国商业税号"。从这点来看，tModel仍然代表一种特定的概念，不过不是一种技术规范，而代表了一个特定的范围，此范围内税号ID有一个特定的含义。

建立起这个描述之后，商业实体就可以用税号tModel的tModelKey作为一个唯一引用，来修饰在identifierBag数据组成这样一个说明条目的其余数据。注册中心操作入口站点(Operator Site)已经注册了很多有用的tModel，包括美国税号，NAICS(一种工业代码分类法)，UNSPSC(一种产品和服务代码分类法)以及一种需要确定的地理分类法。

回页首

结构规范

<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>

下层子结构说明

下面用粗体表示的字段是必要字段，必须出现。

overviewDoc

这个可选的结构为在bindingTemplate中提供一个描述特定tModel的概要信息的容器。

identifierBag

identifierBag元素允许商业实体、一般实体或者tModel数据包含常用的标识符形式的信息，如 Dun & Bradstreet D-U-N-S?标识符、税号等等。该数据用来标识businessEntity的身份，或者用来标识发布团体的身份。这个结构所包含的数据是可选的，但如果包含了这些数据，将会大大增强UDDI Programmers API规范中定义的 find_xx 消息所提供的搜索能力。

categoryBag

categoryBag元素允许对businessEntity、businessService以及tModel数据依照几种可用的基于分类学的分类方案来进行归类。UDDI注册中心操作入口站点自动提供对三种分类法的有效支持，这三种分类法是工业代码(NAICS)，产品与服务分类(UNSPSC)和地理分类。这个结构所包含的数据是可选的，但如果包含了这些数据，将会大大增强UDDI Programmers API规范中定义的 find_xx 消息所提供的搜索能力。

包含在categoryBag中的信息可以被用于定位和引用你所发布的 UDDI 信息。我们希望第三方的分类服务能够分析和检索在 UDDI注册中心操作入口站点中发现的信息，并在创建商业级搜索服务时将这些分类信息作为最先应用的条件。因此，该元素并不需要包含基于某特定目的的分类信息的所有可能的方面。在这些通过复制实现数据同步的UDDI注册中心站点中的数据总量很大，因此利用分类信息作为商业级搜索的第一信息来源的做法并不实际。

回页首

公用tModel体系

为便捷地实现服务描述(tModel)注册的一致性，并且为在UDDI注册中心给服务描述的基本组织提供一个框架，UDDI规范建立了一套内在的约定规则。我将在下一篇文章中介绍公用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
  
  

关于作者

		柴晓路: 上海得易电子商务技术有限公司( DealEasy)首席系统架构师、XML技术顾问。2000年获复旦大学计算机科学硕士学位，曾在国际计算机科学学术会议(ICSC)、亚太区XML技术研讨会(XML Asia/Pacific'99)、中国XML技术研讨会(北京)、计算机科学期刊等各类国际、国内重要会议与期刊上发表论文多篇。专长于基于XML的系统集成和数据交换的技术研究，同时对数据库、面向对象技术及CSCW等技术比较擅长。2001年加入 UDDI Advisor Group，参与了UDDI Specification V2的开发。目前作为 UDDI-China.org的主要核心成员参与UDDI-China.org的核心技术工作。UDDI-China.org是在UDDI.org和DealEasy Technology的支持下在2001年6月发布的UDDI技术站点。

对本文的评价

太差！ (1) 需提高 (2) 一般；尚可 (3) 好文章 (4) 真棒！(5) 建议？

回页首