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> |
下面用粗体表示的字段是必要字段，必须出现。
| 字段名 | 描述 | 数据类型 | 长度 |
| tModelKey | 必要属性。这是给定tModel机构的唯一键值。当保存一个新的tModel机构时，应当传入一个空的tModelKey值。这表示将由注册中心操作入口站点生成一个UUID值。当更新一个已有的tModel结构时，应当传入与一个存在的tModel实例相对应的tModelKey值。 | string | 255 |
| authorizedName | 属性。发布tModel数据的个体在UDDI操作入口中的名字。该数据由管理该tModel数据的UDDI操作入口站点所指派计算，同时该数据不能在 save_tModel 操作中指定。 | string | 64 |
| operator | 属性。管理和控制tModel数据的UDDI注册中心操作入口站点的名称(certified name)。控制该数据的操作入口站点在数据被保存时记录它。该数据是由操作入口指派的，同时该数据不能在 save_tModel 操作中指定。 | string | 48 |
| name | 必要元素。用于记录tModel的名字。名字搜索通过 find_tModel调用提供。名字不能为空，并且必须对于查看tModel的用户是有明确意义的。 | string | 128 |
| description | 可选的可重复元素。一条或多条简短的tModel描述。每一条描述允许支持一种国家语言代码，但国际语言代码不可重复出现。 | string | 255 |
| overviewDoc | 可选元素。用于容纳与tModel元素相关联的远端描述或使用说明。可参阅本文档的bindingTemplate部分的关于overviewDoc的说明部分。 | structure | |
| identifierBag | 可选元素。用来记录tModel附属标识符的名/值(name-value)对的可选列表。这一结构可以在调用find_tModel进行搜索时使用。可参阅本文档中businessEntity部分对于该元素的详细描述以及附录中的"使用标识符"部分以获得更完整的描述信息。 | structure | |
| categoryBag | 可选元素。用于标记tModel的特定分类信息(如：工业，产品或者地理代码)的名/值(name-value)对的可选列表。这一结构可以在调用 find_tModel进行搜索时使用。可参阅本文档中businessEntity部分对于该元素的详细描述以及附录中的"使用分类法"部分以获得更完整的描述信息。 | structure |
这个可选的结构为在bindingTemplate中提供一个描述特定tModel的概要信息的容器。
| 字段名 | 描述 | 数据类型 | 长度 |
| description | 可选的可重复元素。对于被使用的特定tModel的简短描述性概览信息的具备语言代码修饰的零个或多文本描述。 | string | 255 |
| overviewURL | 可选元素。这个字符串数据元素用于存储一个URL引用，该URL引用了一个长期稳定的概要描述文档。这个概要描述文档详细描述了在整体Web服务描述中使用到的以组件形式存在的某个特定的tModel。这个元素的内容的推荐格式是一个URL，这个URL可用于通过Web浏览器或HTTP-GET操作来获取一个基于HTML的描述文档。 | string | 255 |
identifierBag元素允许商业实体、一般实体或者tModel数据包含常用的标识符形式的信息，如 Dun & Bradstreet D-U-N-S?标识符、税号等等。该数据用来标识businessEntity的身份，或者用来标识发布团体的身份。这个结构所包含的数据是可选的，但如果包含了这些数据，将会大大增强UDDI Programmers API规范中定义的 find_xx 消息所提供的搜索能力。
categoryBag元素允许对businessEntity、businessService以及tModel数据依照几种可用的基于分类学的分类方案来进行归类。UDDI注册中心操作入口站点自动提供对三种分类法的有效支持，这三种分类法是工业代码(NAICS)，产品与服务分类(UNSPSC)和地理分类。这个结构所包含的数据是可选的，但如果包含了这些数据，将会大大增强UDDI Programmers API规范中定义的 find_xx 消息所提供的搜索能力。
包含在categoryBag中的信息可以被用于定位和引用你所发布的 UDDI 信息。我们希望第三方的分类服务能够分析和检索在 UDDI注册中心操作入口站点中发现的信息，并在创建商业级搜索服务时将这些分类信息作为最先应用的条件。因此，该元素并不需要包含基于某特定目的的分类信息的所有可能的方面。在这些通过复制实现数据同步的UDDI注册中心站点中的数据总量很大，因此利用分类信息作为商业级搜索的第一信息来源的做法并不实际。
为便捷地实现服务描述(tModel)注册的一致性，并且为在UDDI注册中心给服务描述的基本组织提供一个框架，UDDI规范建立了一套内在的约定规则。我将在下一篇文章中介绍公用tModel和约定规则。
tModel包括name、description、oviewURL、identifierBag，catagoryBag等元素，实际上我之所以把这几个要素放到第一层，一是为了好看，二是因为每一层次都具有这几种元素。
Name——必要元素，名称。
description——文字描述。
overviewDOC——可选项，结构文档地址，UDDI建议这个文档应为HTML，以便用户使用浏览器，通过HTTP GET操作读取该文档。
identifierBag——可选项，标识号组。通过这个元素，我们可以使用预定义的名字空间标志来确定某个结构。该名字空间可由企业集团定义，或有UDDI（DUNS）提供。这个元素包含一组keyReference（关键字引用）元素，每个keyReference元素都是一个关键字/取值对。
扫一扫
794
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
