在UDDI注册中心里使用WSDL

原文链接:[url]http://www.oasis-open.org/committees/uddi-spec/doc/tn/uddi-spec-tc-tn-wsdl-v202-20040631.htm[/url]

Document Identifier:

uddi-spec-tc-tn-wsdl-v2

This Version:

http://www.oasis-open.org/committees/uddi-spec/doc/tn/uddi-spec-tc-tn-wsdl-v202-20040631.htm

Latest Version:

http://www.oasis-open.org/committees/uddi-spec/doc/tn/uddi-spec-tc-tn-wsdl-v2.htm

Previous Version:

http://www.oasis-open.org/committees/uddi-spec/doc/tn/uddi-spec-tc-tn-wsdl-v200-20031104.htm

Authors (alphabetically):

John Colgrave, IBM, colgrave@uk.ibm.com

Karsten Januszewski, Microsoft, karstenj@microsoft.com

Editors:

Luc Clément, Systinet Corporation, luc.clement@systinet.com

Tony Rogers, Computer Associates, tony.rogers@ca.com

Abstract:

This document is an OASIS UDDI Technical Note that defines a new approach to using WSDL in a UDDI Registry.

Status:

This document is updated periodically on no particular schedule.

Committee members should send comments on this technical note to the uddi-spec@lists.oasis-open.org list. Others should submit comments via http://www.oasis-open.org/committees/comments/form.php?wg_abbrev=uddi-spec.

For information on whether any intellectual property claims have been disclosed that may be essential to implementing this technical note, and any offers of patent licensing terms, please refer to the Intellectual Property Rights section of the UDDI Spec TC web page (http://www.oasis-open.org/committees/uddi-spec/ipr.php).

目录表
1 介绍
1.1 目标和需求
1.2 和版本1最佳实践的关系
1.3 术语
2 映射两种数据模型:WSDL&UDDI
2.1 WSDL数据模型
2.1.1 portType
2.1.2 binding
2.1.3 service和port
2.1.4 import
2.2 UDDI数据模型
2.2.1 tModels
2.2.2 businessService&bindingTemplate
2.3 映射WSDL和UDDI
2.3.1 映射概览
2.3.2 与版本1映射的比较
2.3.3 新规范的tModels
2.3.4 一般的习惯约定
2.3.5 对多种UDDI API版本的支持
2.3.6 WSDL组件参考
2.3.7 WSDL扩展性元素
2.3.8 对WSDL实现文档的支持
2.4 在UDDI V2里映射WSDL1.1
2.4.1 wsdl:portType -> uddi:tModel
2.4.2 wsdl:binding -> uddi:tModel
2.4.3 wsdl:service -> uddi:businessService
2.4.4 wsdl:port -> uddi:bindingTemplate
2.4.5 wsdl:port Address Extensions -> uddi:bindingTemplate
2.5 在UDDI V3里映射WSDLL1.1的差别
2.5.1 主要的差别
2.5.2 与UDDI V3规范里的wsdlDeployment比较
3 一个完整的例子
3.1 WSDL例子
3.2 UDDI V2模型
3.2.1 UDDI portType tModel
3.2.2 UDDI binding tModel
3.2.3 UDDI businessService和bindingTemplate
3.3 例子V2查询
3.3.1 基于portType名寻找tModel
3.3.2 基于portType寻找bindings
3.3.3 寻找portType的实现
3.3.4 寻找binding的实现
3.3.5 寻找portType的SOAP实现
3.3.6 寻找portType的SOAP/HTTP实现
3.3.7 寻找binding的portType
3.3.8 基于WSDL服务寻找businessService
3.4 例子V3查询
3.4.1 需找portType的实现
3.4.2 寻找portType的SOAP实现
4 参考
4.1 规范
A 外部WSDL实现文档
A.1 捕获URL
A.2 从WSDL获得Port Address
A.3 查询使用WSDL实现文档的服务
B 规范tModels
B.1 WSDL实体型tModel
B.1.1 设计目标
B.1.2 定义
B.1.3 合法值
B.1.4 使用例子
B.2 XML名字空间tModel
B.2.1 设计目标
B.2.2 定义
B.2.3 合法值
B.2.4 使用例子
B.3 XML本地名字tModel
B.3.1 设计目标
B.3.2 定义
B.3.3 合法值
B.3.4 使用例子
B.4 WSDL portType引用tModel
B.4.1 设计目标
B.4.2 定义
B.4.3 合法值
B.4.4 使用例子
B.5 SOAP协议tModel
B.5.1 设计目标
B.5.2 定义
B.5.3 使用例子
B.6 HTTP协议tModel
B.6.1 设计目标
B.6.2 定义
B.6.3 使用例子
B.7 协议分类
B.7.1 设计目标
B.7.2 定义
B.7.3 合法值
B.7.4 使用例子
B.8 传输分类
B.8.1 设计目标
B.8.2 定义
B.8.3 合法值
B.8.4 使用例子
B.9 WSDL地址tModel
B.9.1 设计目标
B.9.2 定义
B.9.3 合法值
B.9.4 使用例子
C 在overviewURL里使用XPointer
C.1 XPointer语法
C.1.1 使用例子
D 感谢
E 校正历史
F 注意

[b]1 介绍[/b]
Universal Description,Discovery & Integration(UDDI)规范提供了一种描述和发现Web服务和Web服务提供者的跨平台的方式。UDDI数据结构为基本服务信息
的描述提供了一个框架,以及一个可扩展机制来使用任何标准描述语言指定详细的服务访问信息。在特定的工业领域和不同基本的协议栈存在许多这样的语言。
Web Service Description Language(WSDL)是一个描述接口,协议绑定和网络服务部署细节的一般目的XML语言。WSDL通过提供一个描述抽象接口和任意网络服务
协议绑定的统一方式来补充UDDI标准。该文档的目的是阐明两者的关系以及描述一个映射WSDL描述到UDDI数据结构的推荐方式。
一致的和彻底的WSDL映射对UDDI工具集很重要。

[b]1.1 目标和需求[/b]
该映射的首要目标是:
1. 允许在UDDI里自动注册WSDL定义
2. 基于特殊的WSDL artifacts和metadata允许精确和灵活的UDDI查询
3. 维护和在[urlhttp://www.oasis-open.org/committees/uddi-spec/doc/tn/uddi-spec-tc-tn-wsdl-v202-20040631.htm#ref1]Using WSDL in a UDDI Registry, Version 1.08[/url]最佳实践文档里描述的映射的兼容性
4. 提供对UDDI Version 2和UDDI Version 3的映射的一致性
5. 支持WSDL描述的任何逻辑和物理结构
该映射指定了映射WSDL1.1 artifacts到UDDI结构的一个一致的方法学。它描述了一种呈现可重用的,抽象的Web服务artifacts,(WSDL portTypes和WSDL绑定)和
Web服务实现(WSDL services和ports)的方式。工具可以使用该映射来从WSDL描述自动生成UDDI注册
该映射从WSDL文档捕获足够的信息来允许Web服务信息的精确的查询而在以后不用求助于源WSDL文档,以及允许一旦找到一个合适的匹配时得到合适的WSDL文档。
在次基础上,源WSDL文档可以在使用UDDI注册中心的发布者之间发布,一个UDDI注册中心提供一个方便的central point,在这里下面的查询可以被执行。
该映射对设计时和运行时发现允许下面类型的查询:
1,给定名字空间和/或一个wsdl:portType的本地名字,寻找表示该portType的tModel
2,给定名字空间和/或一个wsdl:binding的本地名字,寻找表示该binding的tModel
3,给定一个表示一个portType的tModel,寻找表示该portType的bindings的所有tModel
4,给定一个表示一个portType的tModel,寻找表示该portType的实现的所有bindingTemplates
5,给定一个表示一个binding的tModel,寻找表示该binding的实现的所有bindingTemplates
6,给定名字空间和/或一个wsdl:service的本地名字,寻找表示该service的businessService
该映射的一些方面允许不用更多查询来直接得到信息。例如,给定表示一个binding的tModel,可以得到表示该binding引用的portType的tModel的key。映射的
其他方面可能需要对UDDI注册中心进行多种查询。
尽管UDDI V3数据模型和该UDDI数据模型有稍许不同,该映射确保在两种版本下都可以捕获信息。

[b]1.2 和版本1最佳实践的关系[/b]
该文档基于在UDDI注册中心使用WSDL,版本1.08来构建,并提供一个围绕着WSDL灵活性的扩充的建模实践。该映射与已经存在的最佳实践里描述的那个映射之间
的首要区别是该映射提供一个方法论来表示单独的Web服务artifacts。
作为技术笔记,该文档没有替换版本1最佳实践。如果不需要额外的灵活性,已经存在的最佳实践仍然可以使用,特别是当UDDI artifacts为手动发布时
可以预想,本技术笔记描述的该方法的实现将被开发,而且一旦那些实现的经验被获得则该技术笔记将变成一个最佳实践。
一个最终的目标是与已经存在的最佳实践兼容,其中一个表示一个使用本文档描述的方式发布一个WSDL binding的tModel应该对使用版本1最佳实践方式的客户端
可用。

[b]1.3 术语[/b]
本文档的关键字must, must not, required, shall, shall not, should, should not, recommended, may和optional将和在[RFC2119]中描述的一样被解释。

[b]2 映射两种数据模型:WSDL&UDDI[/b]

[b]2.1 WSDL数据模型[/b]
对目标和需求的上下文中的WSDL的复习将帮助在UDDI中指引一个新的映射实践。
[img]http://www.oasis-open.org/committees/uddi-spec/doc/tn/uddi-spec-tc-tn-wsdl-v202-20040631_files/image002.gif[/img]

[b]2.1.1 portType[/b]
WSDL里的核心构件就是portType。一个portType为一个抽象的操作集,可能有一个或多个Web服务支持它。一个WSDL portType根据消息定义来定义这些操作,消息
定义通常依赖于XML Schema语言来描述每个消息的呈现。一个单独的WSDL文档可能包含多种portType实体。每个portType通过它的本地名和包含该portType的定义
元素的目标名字空间来唯一识别。
WSDL portTypes可能被多于一个Web服务实现。Web服务旨在支持一个给定的portType必须不只粘着在作为WSDL定义的一部分的消息格式;它们必须也粘着在隐含为
portTye的一部分语义协议。该一致性允许程序来认为如果并且只有两个Web服务实现了一个共用的portType时它们可替换。

[b]2.1.2 binding[/b]
WSDL portTypes为抽象的Web服务描述并且没有指定关于使用来传输消息的编码和传输协议的信息。为了在WSDL里指定编码和传输协议细节,必须定义另一个结构,
即binding。一个WSDL binding指定一个可能用来与一个特殊WSDL portType通信的编码和传输协议特殊集。一个WSDL binding通过一个QName引用指定它的portType
引用的portType可能或者可能不在binding本身的同一目标名字空间里。而一个单独的WSDL文档可能包含包含该binding的定义元素的目标名字空间。
和portTypes一样,WSDL bindings为抽象的定义而且不表示Web服务实现,多个Web服务可能实现同一WSDL binding。

[b]2.1.3 service和port[/b]
最后,WSDL定义一个Web服务实现为具有一些命名的ports的服务。每个port使用一个命名的binding中定义的协议来实现一个特别的portType。一个服务可能暴露
多个ports来让一个单独的portType对多种协议可得。一个服务也可能暴露多个ports来从一个单独的逻辑实体暴露多于一个portType。一个WSDL port通过一个
QName引用来指定它实现的binding。该引用的binding可能或者可能不在port本身的同一目标名字空间里。一个单独的WSDL文档可能包含多个服务。一个服务通过
它的本地名和包含该服务的定义元素的目标名字空间的结合来唯一标识。同样的,一个port通过它的本地名和包含该port的定义元素的目标名字空间的结合来
唯一标识。

[b]2.1.4 import[/b]
WSDL中的import指令允许把这些不同的实体分离到多个文件。像这样,一个WSDL文档可能由一个单独的portType,多个portTypes,一个imports它的portType定义
的单独的binding,多个bindings,一个单独的service,多个services等等组成。WSDL数据模型提供WSDL实体的组合和重用的巨大的灵活性
给定这个灵活性,在组合和区分方面一个WSDL文档最重要的组件为定义元素的目标名字空间和在该目标名字空间中识别每个portType,binding,service和port
的本地名。

[b]2.2 UDDI数据模型[/b]
作为理解下面的部分的援助,我们在这里提供在UDDI注册中心上下文中与WSDL的使用非常相关的两种UDDI数据结构的一个简短的概览:tModel和businessService。

[b]2.2.1 tModels[/b]
TModels通常指服务类型定义。TModels表示唯一的概念或结构。它们被用来描述一个规范,一个概念或者一个分享的设计的compliance。TModels在UDDI注册中心
里有多种用途。在映射WSDL描述的Web服务的情况下,tModels有两种用途。第一,tModels用来表示技术规范,例如服务类型,绑定和线路协议。第二,tModels
用来实现用来给技术规范和服务分类的分类系统。该技术笔记定义了一个规范集和用于映射WSDL实体到UDDI实体的分类系统tModels。这些tModels在附录B中定义。
当一个特殊的规范在UDDI注册中心中注册为一个tModel,则它被赋予一个唯一的key,称为一个tModelKey。这个key被其它UDDI实体使用来引用tModel,例如来
指示该规范的compliance。
每个规范tModel包含一个overviewURL,它提供规范本身的地址,例如,一个WSDL文档。
额外的metadata可以与一个使用任何数量的标识符和分类系统的规范tModel关联。标识符聚集在一个叫做identifierBag的结构里,而分类聚集在一个叫做
categoryBag的结构里。这些bags包含一个keyedReference元素集。每个keyedReference指定分类系统tModel和一个指定metadata的名字/值对的tModelKey。
例如,一个指示名字空间分类系统的keyedReference可以被用来指定一个WSDL名字空间。在keyedReference元素里指定的metadata值可以被用来作为当搜索UDDI
时的选择标准。

[b]2.2.2 businessService & bindingTemplate[/b]
[img]http://www.oasis-open.org/committees/uddi-spec/doc/tn/uddi-spec-tc-tn-wsdl-v202-20040631_files/image003.gif[/img]
在UDDI里服务通过businessService数据结构表示,服务怎样以及在哪里访问的细节通过一个或多个bindingTemplate结构提供。businessService可以被认为是
一个逻辑的服务容器。bindingTemplate结构包含服务的accessPoint,以及它要实现的tModels的引用。

[b]2.3 映射WSDL和UDDI[/b]
WSDL设计来支持模块化和可重用的定义,每个定义artifact同其他定义artifacts有某种关系。在1.1节描述到,该技术笔记的目标和它定义的映射是为了允许在
UDDI里自动注册WSDL定义,允许基于特殊的WSDL artifacts和metadata的精确和灵活的UDDI查询,维护和版本1最佳实践方法论的兼容性,以及提供对UDDI V2和
UDDI V3的一致映射。映射本身达到了第一个目标。第二个目标提供了在该映射里使用的基本原理。为了支持基于特殊的WSDL artifacts和metadata的查询,该
映射必须能够表示单独的WSDL artifacts以及artifacts间的关系。这个目标也提供在UDDI中必须捕获的信息的基本原理。在某些情况下额外的信息也必须引入
进来以支持第三个目标。为了达到第四个目标,在那两个映射里捕获的信息应该尽可能一致。

[b]2.3.1 映射概览[/b]
映射描述了一个映射WSDL1.1定义到UDDI V2和UDDI V3数据模型的方法论。该方法论映射每个WSDL artifact到一个单独的UDDI实体,并正确的表示WSDL描述的
"building block"设计。wsdl:portType和wsdl:binding元素映射到uddi:tModel实体,wsdl:service元素映射到uddi:businessService实体,以及wsdl:port元素
映射到uddi:bindingTemplate实体。KeyedReferences提供一种机制来表达额外的metadata和表示两个UDDI实体间的关系。
[img]http://www.oasis-open.org/committees/uddi-spec/doc/tn/uddi-spec-tc-tn-wsdl-v202-20040631_files/image004.jpg[/img]

[b]2.3.2 与版本1映射的比较[/b]
关于该映射的一个需要注意的重要事情(特别是当和版本1最佳实践里描述的映射比较时)是这种方法可能映射一个单独的WSDL文档到多个tModels。例如,在UDDI里
一个包含一个portType定义和两个binding定义的单独的WSDL文档将映射到三个不同的tModels。这种方式与版本1最佳实践不同,版本1默认映射整个WSDL文档到
一个单独的tModel。版本1最佳实践不允许一个portType映射到一个不同的tModel。这种新的映射决定的基本原理为更高效的表示UDDI中WSDL artifacts的模块性
和重用性。一个Web服务实现可能只实现一个WSDL文档里描述的bingdings中的一个。通过分解WSDL到多个tModels,我们可以在UDDI里正确的建模一个给定的Web
服务实现支持哪个portTypes和bindings,而不是被迫宣称一个Web服务一直支持整个WSDL文档。
当UDDI中一个建模的WSDL文档有一个增加数量的数据时,这种新方式与版本1最佳实践一致,版本1不会尝试使用UDDI作为一个WSDL文档中所有数据的repository,
和版本1最佳实践一样,我们仍然必须到UDDI注册中心之外获得对需要该Web服务来使得软件程序工作的必要的portType和bindding信息。

[b]2.3.3 新规范的tModels[/b]
该映射介绍了一些用来表示WSDL metadata和关系的规范的tModels。这些tModels,包括WSDL Entity Type tModel,XML Namespace tModel,XML Local Name
tModel,WSDL portType Reference tModel,SOAP Protocol tModel,HTTP Protocol tModel, Protocol Categorization tModel,Transport Categorization
tModel和WSDL Address tModel,在附录B中描述了。这些tModels[b]必须[/b]在UDDI注册中心注册来支持该映射。V1/V2和V3 keys为这些tModels给定。

[b]2.3.4 一般的习惯约定[/b]
在该映射中,每个WSDL artifact映射到它相应的UDDI实体。一个keyedReference元素集添加到每个UDDI实体来捕获额外的metadata。为了支持1.1节中描述的需
求,下面的metadata为每个实体捕获:
1,定义的WSDL实体类型(即,portType,binding,service,或者port)
2,定义WSDL实体的WSDL定义文件的目标名字空间
3,定义的WSDL实体的本地名
4,定义WSDL实体为portType,binding和可选的service实体捕获的WSDL文档的位置
实体间的任何关系和依赖也必须被捕获。例如,一个表示一个binding的tModel提供对表示通过该binding实现的portType的tModel的一个引用。
为了维持同版本1最佳实践映射的兼容性,某些UDDI实体也表现为"wsdlSpec"类型。

[b]2.3.5 对多种UDDI API版本的支持[/b]
描述的映射设计来与UDDI API用来访问它的同一版本。API版本的差别控制了它们的差别,这些差别在合适的章节里指出了。

[b]2.3.6 WSDL组件参考[/b]
一个UDDI实体一般引用使用overviewURL元素的技术规范。上面提到,在该映射中一个单独的WSDL文档可能映射到多个tModels,并且每个tModel引用文件里的一个
特殊的WSDL实体。特殊的WSDL实体通过它的本地名和包含该WSDL实体的定义元素的目标名字空间唯一标识。这个识别信息[b]应该[/b]由UDDI实体决定,对特殊的
UDDI实体类型适用的名字空间和本地名使用特殊的映射。或者,overviewURL值[b]可能[/b]包含一个fragment标识符来识别特殊的WSDL实体。如果可选的fragment
识别符被使用,则overviewURL的值[b]应该[/b]符合附录C中描述的语法。

[b]2.3.7 WSDL扩展性元素[/b]
WSDL使用扩展性元素来描述一个WSDL定义里技术专有的信息。扩展性元素可能包含在许多WSDL元素里。只与该映射相关的扩展性元素为binding和port扩展,特别
是可以被添加到wsdl:binding和wsdl:port元素的扩展性元素。它们中的第一个用来宣称特殊的协议和消息形式;第二个用来提供地址信息。
从这些扩展性元素得到的信息对wsdl:bingding映射到tModel,对wsdl:port映射到bindingTemplate。该文档里定义的映射包含关于SOAP1.1和WSDL1.1 W3C Note
里定义的HTTP GET/POST bindings细节。该映射也描述了其他bindings应该怎样合并到UDDI映射中。

[b]2.3.8 对WSDL实现文档的支持[/b]
在本技术笔记的上下文中,一个WSDL实现文档为一个包含至少一个wsdl:service元素和它相关的wsdl:port元素的WSDL文档。关于该实现信息在UDDI里怎样描述有
两种选项:
1,在UDDI模型里的信息为权威信息并且没有对一个WSDL实现文档的引用
2,一个对一个外部WSDL实现文档的引用可以被存储在UDDI中并且UDDI中其余的信息用来在外部WSDL资源中描述合适的元素。
该文档的body中描述的映射与上面的第一个选项一致,并且它被假设为默认的映射。第二个选项在附录A中描述了。

[b]2.4 在UDDI V2里映射WSDL1.1[/b]
本节描述了详细的映射WSDL1.1 artifacts到UDDI V2数据模型。

[b]2.4.1 wsdl:portType -> uddi:tModel[/b]
一个wsdl:portType[b]必须[/b]建模为一个uddi:tModel。
关于一个portType必须捕获的最少的信息为实体类型,它的本地名,它的名字空间,和定义该portType的WSDL文档的位置。捕获实体类型允许用户来搜索表示
portType artifacts的tModels。捕获本地名,名字空间和WSDL位置允许用户找到制定的portType artifact的定义的位置。
wsdl:portType信息如下所示捕获:
tModel的uddi:name元素[b]必须[/b]为wsdl:portType的name属性的值。
tModel[b]必须[/b]包含一个categoryBag,并且categoryBag[b]必须[/b]包含一个具有该WSDL Entity Type分类系统的tModelKey和一个"portType"的keyValue的
KeykeyedReference。
如果wsdl:portType有一个targetNamespace则categoryBag[b]必须[/b]也包含一个额外的具有该XML Namespace分类系统的tModelKey和一个包含wsdl:portType的
wsdl:definitions元素的目标名字空间的keyValue的keyedReference。如果portType没有targetNamespace,一个categoryBag[b]必须不[/b]包含一个该XML
Namespace分类系统的KeyedReference。
tModel[b]必须[/b]包含一个具有一个包含描述wsdl:portType的WSDL文档的位置的overviewURL的overviewDoc。

[b]2.4.1.1 wsdl:portType映射总结[/b]
WSDL UDDI
portType tModel(归类为portType)
portType的名字空间 categoryBag中的keyedReference
portType的本地名 tModel名
WSDL文档的位置 overviewURL

[b]2.4.2 wsdl:bingding -> uddi:tModel[/b]
一个wsdl:binding[b]必须[/b]建模为一个uddi:tModel。
关于一个binding必须至少捕获的信息为它的实体类型,它的本地名,它的名字空间,定义该binding的WSDL文档的位置,它实现的portType,它的协议,和可选的
传输信息。捕获实体类型允许用户搜索表示binding artifacts的tModels。捕获本地名,名字空间和WSDL文档的位置允许用户找到指定的binding artifact的定义
的位置。对portType的链接允许用户搜索实现特殊的portType的bindings。
在版本1最佳实践的映射定义到,一个wsdl:binding与一个WSDL服务接口定义一致。为了维持和前一个映射的兼容性,bingding必须也描述为"wsdlSpec"类型。
wsdl:binding信息如下所示捕获:
tModel的uddi:name元素[b]必须[/b]为wsdl:binding的name属性的值。
tModel[b]必须[/b]包含一个categoryBag,而且categoryBag[b]必须[/b]包含至少下列keyedReference元素:
1,一个具有该WSDL Entity Type分类系统的tModelKey的keyedReference和"binding"的keyValue
2,一个具有该WSDL portType Reference分类系统的tModelKey的keyedReference和建模wsdl:binding相关的wsdl:portType的tModelKey的keyValue
3,一个具有该UDDI Types分类系统的tModelKey的keyedReference和为了向前兼容的"wsdlSpec"的keyValue
4,一到两个需要用来捕获协议的keyedReferences和可选的传输信息--参考下一节
如果wsdl:binding有一个targetNamespace则categoryBag[b]必须[/b]也包含一个额外的具有该XML Namespace分类系统的tModelKey的keyedReference和包含
wsdl:binding的wsdl:definitions元素的目标名字空间的keyValue。如果binding没有targetNamespace,一个categoryBag[b]必须不[/b]包含一个该XML Namespace
分类系统的keyedReference。
tModel[b]必须[/b]包含一个具有一个包含描述wsdl:binding的WSDL文档位置的overviewURL的overviewDoc。

[b]2.4.2.1 wsdl:binding扩展[/b]
在下面的章节描述到,如果可用,在一个对wsdl:binding的扩展里指定的关于协议和传输的信息用来分类binding tModel。该信息使用在本技术笔记里定义的分类
系统中的两个来指定:
1,Protocol Categorization
2,Transport Categorization
Protocol Categorization分类系统的合法值为归类为protocol tModels的tModels的tModelKeys。同样的,Transport Categorization分类系统的合法值为归类为
transport tModels的tModels的tModelKeys。
有这两个将tModel keys作为值的分类构成的原因是允许其他标准或者私有protocols和transports和标准的SOAP和HTTP protocols和transport使用同样的方式来
被定义和使用。

[b]2.4.2.1.1 soap:binding[/b]
如果wsdl:binding包含一个来自http://schemas.xmlsoap.org/wsdl/soap/名字空间的soap:binding扩展性元素则categoryBag[b]必须[/b]包含一个具有一个
Protocol Categorization分类系统的tModelKey的keyedReference和一个SOAP Protocol tModel的tModelKey的keyValue。
如果soap:binding的transport属性值为http://schemas.xmlsoap.org/soap/http则categoryBag[b]必须[/b]包含一个具有一个Transport Categorization分类
系统的tModelKey的keyedReference和一个HTTP Protocol tModel的tModelKey的keyValue。
如果transport属性的值是其他任何东西,则bindingTemplate[b]必须[/b]包含一个额外的具有一个Transport Categorization分类系统的tModelKey的
keyedReference和一个合适的transport tModel的tModelKey的keyValue。

[b]2.4.2.1.2 http:binding[/b]
如果wsdl:binding包含一个来自http://schemas.xmlsoap.org/wsdl/http/名字空间的http:binding扩展性元素则categoryBag[b]必须[/b]包含一个具有一个
Protocol Categorization分类系统的tModelKey的keyedReference和一个HTTP Protocol tModel的tModelKey的keyValue。
注意这是一个与HTTP Transport tModel不同的tModel,并且在这种情况下没有分开的transport tModel,这样在来自Transport Categorization分类系统的
categoryBag中就没有keyedReference。

[b]2.4.2.1.3 其他wsdl:binding扩展[/b]
其他wsdl:binding扩展性元素以一个类似的方式处理。假设提供其他bindings的vendors将提供合适的protocol和transport tModels。

[b]2.4.2.2 wsdl:binding映射总结[/b]
WSDL UDDI
binding tModel(归类为binding和wsdlSpec)
binding的名字空间 categoryBag中的keyedReference
binding的本地名 tModel name
WSDL文档的位置 overviewURL
binding相关的portType categoryBag中的keyedReference
binding扩展的Protocol categoryBag中的keyedReference
binding扩展(如果有的话)的Transport categoryBag中的keyedReference

[b]2.4.3 wsdl:service -> uddi:businessService[/b]
一个wsdl:service[b]必须[/b]建模为一个uddi:businessService。一个已经存在的businessSerice[b]可能[/b]被使用或者一个新的businessService[b]可能[/b]
被创建。只有一个wsdl:service可以被一个单独的uddi:businessService建模。
必须被捕获的关于一个服务的最少的信息为它的实体类型,它的本地名,它的名字空间,和它支持的ports列表。捕获实体类型允许用户搜索通过WSDL定义描述的
服务。ports列表提供对消费服务必需的技术信息的访问。
wsdl:service信息如下所示捕获:
如果一个新的businessService被创建,该businessService的则uddi:name元素[b]应该[/b]为人类可读的名字,尽管如果没有指定人类可读的名字,则一个uddi:
name[b]必须[/b]被添加,包含wsdl:service的name属性的值。
businessService[b]必须[/b]包含一个categoryBag,而且categoryBag[b]必须[/b]包含至少以下keyedReference元素:
1,一个具有一个WSDL Entity Type分类系统的tModelKey和一个"service"的keyValue的keyedReference
2,一个具有一个XML Local Name分类系统的tModelKey和一个wsdl:service的name属性的值keyValue的keyedReference
如果wsdl:service有一个targetNamespace则categoryBag[b]必须[/b]也包含一个额外的具有一个XML Namespace分类系统的tModelKey和一个包含wsdl:service的
wsdl:definitions元素的目标名字空间的keyValue的keyedReference。如果服务没有targetNamespace,一个categoryBag[b]必须不[/b]包含一个XML Namespace
分类系统的keyedReference。
businessService的bindingTemplates元素[b]必须[/b]包含建模服务的ports的bindingTemplate元素,这在下面的章节描述了。

[b]2.4.3.1 映射总结[/b]
WSDL UDDI
Service businessService(归类为服务)
Service的Namespace categoryBag中的keyedReference
Service的本地名 categoryBag中的keyedReference;也可选为服务的名字

[b]2.4.4 wsdl:port -> uddi:bindingTemplate[/b]
一个wsdl:port[b]必须[/b]建模为一个uddi:bindingTemplate。
关于一个port的必须被捕获的最少的信息是它实现的binding,它实现的portType,和它的本地名。
通过捕获binding,用户可以搜索实现一个特定的binding的服务。通过捕获portType,用户可以搜索实现了一个特殊的portType的服务而不必知道服务实现的
特定的binding。
wsdl:port信息如下所示捕获:
bindingTemplate tModelInstanceDetails元素[b]必须[/b]包含至少以下tModelInstanceInfo元素:
1,一个具有一个对该port实现的wsdl:binding建模的tModel的tModelKey的tModelInstanceInfo。该tModelInstanceInfo的instanceParms[b]必须[/b]包含wsdl:port
本地名。
2,一个具有一个对该wsdl:portType建模的tModel的tModelKey的tModelInstanceInfo。

[b]2.4.4.1 映射总结[/b]
WSDL UDDI
port bindingTemplate
名字空间 包含的businessService的keyedReference中捕获
port的本地名 该binding的tModel相关的tModelInstanceInfo的instanceParms
port实现的binding 具有符合该binding的tModel的tModelKey的tModelInstanceInfo
port实现的portType 具有符合该portType的tModel的tModelKey的tModelInstanceInfo

[b]2.4.5 wsdl:port Address Extensions -> uddi:bindingTemplate[/b]
uddi:bindingTemplate必须包含Web服务的地址信息。该信息来自wsdl:port地址扩展性元素。

[b]2.4.5.1 soap:address -> uddi:accessPoint[/b]
一个soap:address[b]必须[/b]在建模包含soap:address的wsdl:port的uddi:bindingTemplate中建模为uddi:accessPoint。
soap:address信息如下所示被捕获:
1,accessPoint值[b]必须[/b]为soap:address元素的location属性的值
2,accessPoint的URLType属性[b]必须[/b]与soap:binding指定的transport一致,或者如果没有一致存在则为"other"。例如在HTTP transport情况下,URLType
属性[b]必须[/b]为"http"。
如果"other"被使用则一个引用合适的vendor定义的transport tModel的tModelInstanceInfo元素[b]必须[/b]添加到bindingTemplate。

[b]2.4.5.2 http:address -> uddi:accessPoint[/b]
一个http:address在建模包含http:address的wsdl:port的uddi:bindingTemplate中[b]必须[/b]建模为一个uddi:accessPoint。
http:address信息如下所示捕获:
1,accessPoint值[b]必须[/b]为http:address元素的location属性的值
2,accessPoint的URLType属性[b]必须[/b]为"http"或者"https"

[b]2.4.5.3 其他wsdl:port Address扩展[/b]
任何其他address扩展性元素在建模包含address扩展性元素的wsdl:port的uddi:bindingTemplate中[b]必须[/b]建模为uddi:accessPoint。
address信息如下所示捕获:
1,accessPoint值[b]必须[/b]为address扩展性元素的location属性的值。如果location属性的值不能映射到accessPoint值则WSDL实现文档方式必须被使用。
参考附录A来得到更多信息。
2,accesPoint的URLType属性[b]必须[/b]与该URL相关的transport协议一致,或者如果没有合适的定义的属性值则为"other"。

[b]2.5 在UDDI V3中映射WSDL 1.1的区别[/b]
本节描述在UDDI V3视图中的模型的差别,模型是UDDI V3规范中重要的条目。

[b]2.5.1 主要差别[/b]
主要差别为:
1,实体将拥有V3 keys而不是V2 keys。
2,一个accessPoint有一个useType属性而不是一个URLType属性。

[b]2.5.2 在UDDI V3规范中与wsdlDeployment的比较[/b]
UDDI V3规范包含对wsdlDeployment的支持,wsdlDeployment表现为一个accessPoint的useType属性的值和一个bindingTemplate的分类。wsdlDeployment的使用
与本技术笔记不兼容,因为它假设没有WSDL建模会执行,对WSDL不知道任何事情,更不用说它的URL。

[b]3 一个完整的例子[/b]
考虑下面的基于在WSDL1.1规范中表示的WSDL文档的WSDL例子。这个例子显示了这个WSDL文档怎样分解到两个tModels(一个为portType另一个为binding)以及一个
具有一个bindingTemplate的businessService。然后它显示可以用来作发现目的的UDDI API查询。

[b]3.1 WSDL例子[/b]
[code]
<?xml version="1.0" encoding="utf-8"?>
<definitions
name="StockQuote"
targetNamespace="http://example.com/stockquote/"
xmlns:tns="http://example.com/stockquote/"
xmlns:xsd1="http://example.com/stockquote/schema/"
xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
xmlns="http://schemas.xmlsoap.org/wsdl/">

<types>
<schema
targetNamespace="http://example.com/stockquote/schema/"
xmlns="http://www.w3.org/2001/XMLSchema">
<element name="TradePriceRequest">
<complexType>
<all>
<element name="tickerSymbol" type="string"/>
</all>
</complexType>
</element>
<element name="TradePrice">
<complexType>
<all>
<element name="price" type="float"/>
</all>
</complexType>
</element>
</schema>
</types>

<message name="GetLastTradePriceInput">
<part name="body" element="xsd1:TradePriceRequest"/>
</message>
<message name="GetLastTradePriceOutput">
<part name="body" element="xsd1:TradePrice"/>
</message>

<portType name="StockQuotePortType">
<operation name="GetLastTradePrice">
<input message="tns:GetLastTradePriceInput"/>
<output message="tns:GetLastTradePriceOutput"/>
</operation>
</portType>

<binding name="StockQuoteSoapBinding" type="tns:StockQuotePortType">
<soap:binding style="document"
transport="http://schemas.xmlsoap.org/soap/http"/>
<operation name="GetLastTradePrice">
<soap:operation soapAction="http://example.com/GetLastTradePrice"/>
<input>
<soap:body use="literal"/>
</input>
<output>
<soap:body use="literal"/>
</output>
</operation>
</binding>

<service name="StockQuoteService">
<port name="StockQuotePort" binding="tns:StockQuoteSoapBinding">
<soap:address location="http://location/sample"/>
</port>
</service>
</definitions>
[/code]
注意该WSDL文档有一个portType,一个binding,一个service和一个port。像这样,这个例子展示了最简单的WSDL文档。同时也注意一下该WSDL的位置位于
http://location/sample.wsdl。

[b]3.2 UDDI V2模型[/b]

[b]3.2.1 UDDI portType tModel[/b]
WSDL portType 实体映射到一个tModel。tModel名字和WSDL portType本地名一样。tModel包含一个指定WSDL名字空间的categoryBag,并且它指示了tModel为
"portType"类型。overviewDoc提供了一个对WSDL文档的指针。
[code]
<tModel tModelKey="uuid:e8cf1163-8234-4b35-865f-94a7322e40c3" >
<name>
StockQuotePortType
</name>
<overviewDoc>
<overviewURL>
http://location/sample.wsdl
<overviewURL>
<overviewDoc>
<categoryBag>
<keyedReference
tModelKey="uuid:d01987d1-ab2e-3013-9be2-2a66eb99d824"
keyName="portType namespace"
keyValue="http://example.com/stockquote/" />
<keyedReference
tModelKey="uuid:6e090afa-33e5-36eb-81b7-1ca18373f457"
keyName="WSDL type"
keyValue="portType" />
</categoryBag>
</tModel>
[/code]

[b]3.2.2 UDDI binding tModel[/b]
WSDL binding实体映射到一个tModel。tModel名字与WSDL binding的本地名一样。tModel包含一个指定WSDL名字空间的categoryBag,它指示了tModel为"binding"
类型,它提供一个对portType tModel的指针,并且它指示了该binding支持什么协议。wsdlSpec keyedReference确保了用户可以找到使用在版本1最佳实践里定
义的惯例的tModel。overviewDoc提供了一个对WSDL文档的指针。
[code]
<tModel tModelKey="uuid:49662926-f4a5-4ba5-b8d0-32ab388dadda">
<name>
StockQuoteSoapBinding
</name>
<overviewDoc>
<overviewURL>
http://location/sample.wsdl
</overviewURL>
</overviewDoc>
<categoryBag>
<keyedReference
tModelKey="uuid:d01987d1-ab2e-3013-9be2-2a66eb99d824"
keyName="binding namespace"
keyValue="http://example.com/stockquote/" />
<keyedReference
tModelKey="uuid:6e090afa-33e5-36eb-81b7-1ca18373f457"
keyName="WSDL type"
keyValue="binding" />
<keyedReference
tModelKey="uuid:082b0851-25d8-303c-b332-f24a6d53e38e"
keyName="portType reference"
keyValue="uuid:e8cf1163-8234-4b35-865f-94a7322e40c3" />
<keyedReference
tModelKey="uuid:4dc74177-7806-34d9-aecd-33c57dc3a865"
keyName="SOAP protocol"
keyValue= "uuid:aa254698-93de-3870-8df3-a5c075d64a0e" />
<keyedReference
tModelKey="uuid:e5c43936-86e4-37bf-8196-1d04b35c0099"
keyName="HTTP transport"
keyValue=" uuid:68DE9E80-AD09-469D-8A37-088422BFBC36" />
<keyedReference
tModelKey="uuid:c1acf26d-9672-4404-9d70-39b756e62ab4"
keyName="uddi-org:types"
keyValue="wsdlSpec" />
</categoryBag>
</tModel>
[/code]

[b]3.2.3 UDDI businessService和bindingTemplate[/b]
WSDL service实体映射到一个businessService,WSDL port实体映射到一个bindingTemplate。businessService名应该为一个人类可读的名字。businessService
包含一个指示该service表示一个WSDL service的categoryBag,并且它指定WSDL名字空间和WSDL服务本地名。bindingTemplate指定了service的endpoint,并且
它包含一个tModelInstanceDetails集。第一个tModelInstanceInfo指示了该service实现了StockQuoteSoapBind并提供了WSDL port本地名。第二个
tModelInstanceInfo指示了实现StockQuotePortType的service。

[b]3.3 例子V2查询[/b]
本节显示对给定的例子的模型怎样执行多种UDDI V2查询。

[b]3.3.1 基于portType名寻找tModel[/b]
在名字空间http://example.com/stockquote/寻找StockQuotePortType的portType tModel。
[code]
<find_tModel generic="2.0" xmlns="urn:uddi-org:api_v2">
<name>StockQuotePortType</name>
<categoryBag>
<keyedReference
tModelKey="uuid:6e090afa-33e5-36eb-81b7-1ca18373f457"
keyName="WSDL type"
keyValue="portType"/>
<keyedReference
tModelKey="uuid:d01987d1-ab2e-3013-9be2-2a66eb99d824"
keyName="portType namespace"
keyValue="http://example.com/stockquote/"/>
</categoryBag>
</find_tModel>
[/code]
这应该返回tModelKey uddi:e8cf1163-8234-4b35-865f-94a7322e40c3。

[b]3.3.2 基于portType寻找bindings[/b]
寻找StockQuotePortType的所有bindings。
[code]
<find_tModel generic="2.0" xmlns="urn:uddi-org:api_v2">
<categoryBag>
<keyedReference
tModelKey=" uuid:6e090afa-33e5-36eb-81b7-1ca18373f457"
keyName="WSDL type"
keyValue="binding"/>
<keyedReference
tModelKey="uuid:082b0851-25d8-303c-b332-f24a6d53e38e"
keyName="portType reference"
keyValue="uuid:e8cf1163-8234-4b35-865f-94a7322e40c3"/>
</categoryBag>
</find_tModel>
[/code]
这应该返回tModelKey uddi:49662926-f4a5-4ba5-b8d0-32ab388dadda。

[b]3.3.3 寻找portType的实现[/b]
寻找StockQuotePortType的所有实现。
因为serviceKey属性在UDDI V2 API的find_binding调用里是必需的,不可能找到具有一个单独调用的一个portType的所有的实现。必须做一个find_service调用
来得到所有包含一个引用该portType的bindingTemplate的services的keys,然后或者每个这样的service的细节必须通过一个get_serviceDetail调用被得到并且
在service的bindingTemplates中找到合适的bindingTemplate,或者对每个service做一个find_binding调用,相应的设置serviceKey属性。下面的例子显示了
find_binding调用的使用。
第一个调用得到有一个引用该portType的bindingTemplate的services的列表。
[code]
<find_service generic="2.0" xmlns="urn:uddi-org:api_v2">
<tModelBag>
<tModelKey>uuid:e8cf1163-8234-4b35-865f-94a7322e40c3</tModelKey>
</tModelBag>
</find_binding>
[/code]
这应该返回serviceKey 102b114a-52e0-4af4-a292-02700da543d4。
现在第二个调用用来寻找该特殊service的合适的bindings。
[code]
<find_binding serviceKey="102b114a-52e0-4af4-a292-02700da543d4" generic="2.0" xmlns="urn:uddi-org:api_v2">
<tModelBag>
<tModelKey>uuid:e8cf1163-8234-4b35-865f-94a7322e40c3</tModelKey>
</tModelBag>
</find_binding>
[/code]
这应该返回bindingKey f793c521-0daf-434c-8700-0e32da232e74。

[b]3.3.4 寻找binding的实现[/b]
寻找StockQuoteSoapBind的所有实现。
这与前面的例子非常类似,除了tModelBag包含binding tModel的key而不是portType tModel。

[b]3.3.5 寻找portType的SOAP实现[/b]
寻找StockQuotePortType的支持SOAP的所有实现。
至少需要三个查询。第一个查询返回所有的引用portType tModel并且归类为SOAP的binding tModels。
[code]
<find_tModel generic="2.0" xmlns="urn:uddi-org:api_v2">
<categoryBag>
<keyedReference
tModelKey="uuid:6e090afa-33e5-36eb-81b7-1ca18373f457"
keyName="WSDL type"
keyValue="binding"/>
<keyedReference
tModelKey="uuid:4dc74177-7806-34d9-aecd-33c57dc3a865"
keyName="SOAP protocol"
keyValue= "uuid:aa254698-93de-3870-8df3-a5c075d64a0e" />
<keyedReference
tModelKey="uuid:082b0851-25d8-303c-b332-f24a6d53e38e"
keyName="portType reference"
keyValue="uuid:e8cf1163-8234-4b35-865f-94a7322e40c3"/>
</categoryBag>
</find_tModel>
[/code]
下一步发生什么取决于在整个查询中是否需要其他criteria。

[b]3.3.5.1 没有其他Criteria[/b]
这种情况下至少需要两个查询,在上面的寻找一个单独的binding的实现的例子中描述了。第一个查询为一个find_service调用,它必须包含"orAllKeys"
findQualifier并且必须提供一个包含第一个查询返回的所有的binding tModel keys的tModelBag。这将返回有一个引用至少binding tModels中的一个的
bindingTemplate的services列表。
最后,对每个这样的service,必须或者调用get_serviceDetail或者find_binding。

[b]3.3.5.2 其他Criteria[/b]
这种情况也至少需要两个查询,这取决于找到的binding tModels和services的数量。对每个binding tModel需要一个find_service查询并且默认的"andAllKeys"
必须被使用,因为其他的criteria也将应用到该查询。这将返回有一个引用特殊的binding tModel并也满足其他criteria的bindingTemplate的services列表。

[b]3.3.6 寻找portType的SOAP/HTTP实现[/b]
这与前面的情况类似,除了第一个查询除了包含SOAP协议之外必须也包含一个HTTP transport的category。

[b]3.3.7 寻找binding的portType[/b]
一个binding的portType包含在binding tModel的categoryBag中。一旦获得binding的tModel则不需要查询。
具有tModelKey="uuid:082b0851-25d8-303c-b332-f24a6d53e38e"的keyedReference的keyValue包含portType tModelKey。

[b]3.3.8 基于WSDL服务寻找businessService[/b]
在名字空间http://example.com/stockquote/寻找StockQuoteService的businessService。
[code]
<find_service generic="2.0" xmlns="urn:uddi-org:api_v2">
<categoryBag>
<keyedReference
tModelKey="uuid:6e090afa-33e5-36eb-81b7-1ca18373f457"
keyName="WSDL type"
keyValue="service" />
<keyedReference
tModelKey="uuid:d01987d1-ab2e-3013-9be2-2a66eb99d824"
keyName="service namespace"
keyValue="http://example.com/stockquote/" />
<keyedReference
tModelKey="uuid:2ec65201-9109-3919-9bec-c9dbefcaccf6"
keyName="service local name"
keyValue="StockQuoteService" />
</categoryBag>
</find_service>
[/code]
这应该返回serviceKey 102b114a-52e0-4af4-a292-02700da543d4。

[b]3.4 例子V3查询[/b]
本节包含一些来自前面的章节的查询例子的重写来使用UDDI V3 API的新特性。其他查询没有很大不同。显示的实体keys假设V2模型通过一个root registry迁移
到V3。

[b]3.4.1 需找portType的实现[/b]
在UDDI V3 API中一个serviceKey对find_binding是可选的,可以用一个单独的查询实现它。
[code]
<find_binding xmlns="urn:uddi-org:api_v3">
<tModelBag>
<tModelKey>uddi:e8cf1163-8234-4b35-865f-94a7322e40c3</tModelKey>
</tModelBag>
</find_binding>
[/code]
这将返回bindingKey uddi:f793c521-0daf-434c-8700-0e32da232e74。

[b]3.4.2 寻找portType的SOAP实现[/b]

[b]3.4.2.1 没有其他Criteria[/b]
由于在UDDI V3 API里serviceKey对find_binding是可选的并且可以嵌入一个find_tModel调用,可以用一个单独的查询实现它:
[code]
<find_binding xmlns="urn:uddi-org:api_v3">
<findQualifiers>
<findQualifier>
uddi:uddi.org:findqualifier:orallkeys
</findQualifier>
</findQualifiers>
<find_tModel xmlns="urn:uddi-org:api_v3">
<categoryBag>
<keyedReference
tModelKey="uddi:uddi.org:wsdl:types"
keyName="WSDL type"
keyValue="binding"/>
<keyedReference
tModelKey="uddi:uddi.org:wsdl:categorization:protocol"
keyName="SOAP protocol"
keyValue="uddi:uddi.org:protocol:soap"/>
<keyedReference
tModelKey="uddi:uddi.org:wsdl:porttypereference"
keyName="portType reference"
keyValue="uuid:e8cf1163-8234-4b35-865f-94a7322e40c3"/>
</categoryBag>
</find_tModel>
</find_binding>
[/code]
这将返回bindingKey uddi:f793c521-0daf-434c-8700-0e32da232e74。

[b]4 参考[/b]

[b]4.1 规范[/b]
[RFC2119] S. Bradner, Key words for use in RFCs to Indicate Requirement Levels, IETF RFC 2119, March 1997. Available at http://www.ietf.org/rfc/rfc2119.txt.

[1] Using WSDL in a UDDI Registry 1.08. Available at http://www.oasis-open.org/committees/uddi-spec/doc/bp/uddi-spec-tc-bp-using-wsdl-v108-20021110.pdf

[2] Web Services Description Language (WSDL) 1.1, March 15, 2000. Available at http://www.w3.org/TR/wsdl

[3] UDDI Version 2.03 Data Structure Reference, July 7, 2002. Available at http://uddi.org/pubs/DataStructure-V2.03-Published-20020719.pdf.

[4] UDDI Version 3.0 Published Specification, 19 July 2002. Available at http://www.uddi.org/pubs/uddi-v3.00-published-20020719.pdf.

[5] XPointer xpointer() Scheme, W3C Working Draft, 10 July 2002. Available at http://www.w3.org/TR/2002/WD-xptr-xpointer-20020710/

[b]A 外部WSDL实现文档[/b]
There are multiple reasons why it may be desirable to support an external WSDL Implementation Document, among which are the following:

There are extensibility elements defined for the wsdl:service.
There is a wsdl:documentation element for a wsdl:port.
The address of a port may not be representable as a uddi:accessPoint value.
The authoritative source of the address is desired to be the WSDL document rather than UDDI.
The approach described here assumes that if any one of these reasons leads to the use of an external WSDL Deployment Document then the entire mapping described in this section is used.

There are two additional necessary pieces of information that must be captured to use external WSDL Implementation Documents:

The URL of the WSDL Implementation Document.
An indication that the port address must be obtained from the WSDL Implementation Document.

[b]A.1 捕获URL[/b]
If an external WSDL Implementation Document is being used then the URL of this document must be used as the accessPoint value of each and every port of each and every service.

[b]A.2 从WSDL获得Port Address[/b]
If a WSDL Implementation Document is being used then the bindingTemplate MUST contain sufficient information to identify the port address in the WSDL Implementation Document. The mapping described here MUST be used instead of the mapping defined in section 2.4.5.

In all cases where a WSDL Implementation Document is used, the URLType attribute of the accessPoint corresponding to each port MUST be "other", and the value of the accessPoint MUST be the URL of the WSDL Implementation Document.

The bindingTemplate MUST contain a tModelInstanceInfo element with a tModelKey of the WSDL Address tModel. This tModelInstanceInfo element, in combination with the protocol and transport information from the binding tModel, provides the necessary information to locate and interpret the endpoint address.

[b]A.3 查询使用WSDL实现文档的服务[/b]
It is possible to query the services that have a WSDL Implementation Document by querying specifying the tModelKey of the WSDL Address tModel.

[b]B 规范tModels[/b]
This Technical Note introduces a number of canonical tModels that are used to represent WSDL metadata and relationships. These tModels are defined here.

[b]B.1 WSDL实体型tModel[/b]

[b]B.1.1 设计目标[/b]
This mapping uses a number of UDDI entities to represent the various entities within a WSDL document. A mechanism is required to indicate what type of WSDL entity is being described by each UDDI entity. The WSDL Entity Type tModel provides a typing system for this purpose. This category system is used to indicate that a UDDI entity represents a particular type of WSDL entity.

[b]B.1.2 定义[/b]
Name: uddi-org:wsdl:types

Description: WSDL Type Category System

V3 format key: uddi:uddi.org:wsdl:types

V1,V2 format key: uuid:6e090afa-33e5-36eb-81b7-1ca18373f457

Categorization: categorization

Checked: no

B.1.2.1 V2 tModel Structure
[code]
<tModel tModelKey="uuid:6e090afa-33e5-36eb-81b7-1ca18373f457">
<name>uddi-org:wsdl:types</name>
<description xml:lang="en">WSDL Type Category System</description>
<overviewDoc>
<overviewURL>
http://www.oasis-open.org/committees/uddi-spec/doc/tn/uddi-spec-tc-tn-wsdl-v2.htm#wsdlTypes
</overviewURL>
</overviewDoc>
<categoryBag>
<keyedReference
tModelKey="uuid:c1acf26d-9672-4404-9d70-39b756e62ab4"
keyName="uddi-org:types" keyValue="unchecked"/>
<keyedReference
tModelKey="uuid:c1acf26d-9672-4404-9d70-39b756e62ab4"
keyName="uddi-org:types" keyValue="categorization"/>
</categoryBag>
</tModel>
[/code]

[b]B.1.3 合法值[/b]
While this is an unchecked category system, there are only four values that should be used with this category system:

keyValue
Description
UDDI Entity

portType
Represents a UDDI entity categorized as a wsdl:portType
tModel

binding
Represents a UDDI entity categorized as a wsdl:binding
tModel

service
Represents a UDDI entity categorized as a wsdl:service
businessService

port
Represents a UDDI entity categorized as a wsdl:port
bindingTemplate (v3 only)

[b]B.1.4 使用例子[/b]
A V2 tModel representing a portType would have a categoryBag representing its type:
[code]
<categoryBag>
<keyedReference
tModelKey="uuid:6e090afa-33e5-36eb-81b7-1ca18373f457"
keyName="WSDL Entity type"
keyValue="portType"/>

</categoryBag>
[/code]

[b]B.2 XML名字空间tModel[/b]

[b]B.2.1 设计目标[/b]
A namespace provides necessary qualifying information about a technical concept or model. The XML Namespace tModel provides a mechanism to associate a namespace with a UDDI entity. This category system describes a UDDI entity by specifying the target namespace of the description file (i.e., a WSDL document or XML Schema file) that describes the entity. More than one tModel might be categorized with the same namespace – in fact, this mapping would be quite common, as many WSDL documents use a common target namespace for wsdl:portType, wsdl:binding, and wsdl:service elements.

[b]B.2.2 定义[/b]
Name: uddi-org:xml:namespace

Description: A category system used to indicate namespaces

V3 format key: uddi:uddi.org:xml:namespace

V1, V2 format key: uuid:d01987d1-ab2e-3013-9be2-2a66eb99d824

Categorization: categorization

Checked: no

B.2.2.1 V2 tModel Structure
[code]
<tModel tModelKey="uuid:d01987d1-ab2e-3013-9be2-2a66eb99d824">
<name>uddi-org:xml:namespace</name>
<description xml:lang="en">A category system used to indicate namespaces</description>
<overviewDoc>
<overviewURL>
http://www.oasis-open.org/committees/uddi-spec/doc/tn/uddi-spec-tc-tn-wsdl-v2.htm#xmlNamespace
</overviewURL>
</overviewDoc>
<categoryBag>
<keyedReference
tModelKey="uuid:c1acf26d-9672-4404-9d70-39b756e62ab4"
keyName="uddi-org:types" keyValue="unchecked"/>
<keyedReference
tModelKey="uuid:c1acf26d-9672-4404-9d70-39b756e62ab4"
keyName="uddi-org:types" keyValue="categorization"/>
</categoryBag>
</tModel>
[/code]

[b]B.2.3 合法值[/b]
The values used in this category system are namespaces of type "anyURI". The content of keyValue in a keyedReference that refers to this tModel is the target namespace of the WSDL document that describes the WSDL entity described by the UDDI entity.

[b]B.2.4 使用例子[/b]
A namespace keyedReference would be as follows:
[code]
<categoryBag>
<keyedReference
tModelKey="uuid:d01987d1-ab2e-3013-9be2-2a66eb99d824"
keyName="namespace"
keyValue="urn:foo"/>

</categoryBag>
[/code]

[b]B.3 XML本地名字tModel[/b]

[b]B.3.1 设计目标[/b]
Each WSDL entity is identified by its name attribute, and this identification information needs to be captured in the mapped UDDI entities. In the case of wsdl:portType and wsdl:binding, the name attribute is mapped to the uddi:tModel name element. However, it isn’t always appropriate to map the wsdl:service name attribute to the name element of the businessService, and, in the case of wsdl:port, the bindingTemplate entity does not have a name element. The XML Local Name tModel provides a mechanism to indicate the name attribute for the uddi:businessService.

[b]B.3.2 定义[/b]
Name: uddi-org:xml:localName

Description: A category system used to indicate XML local names

V3 format key: uddi:uddi.org:xml:localname

V1,V2 format key: uuid:2ec65201-9109-3919-9bec-c9dbefcaccf6

Categorization: categorization

Checked: no

B.3.2.1 V2 tModel Structure
[code]
<tModel tModelKey="uuid:2ec65201-9109-3919-9bec-c9dbefcaccf6">
<name>uddi-org:xml:localName</name>
<description xml:lang="en">A category system used to indicate XML local names</description>
<overviewDoc>
<overviewURL>
http://www.oasis-open.org/committees/uddi-spec/doc/tn/uddi-spec-tc-tn-wsdl-v2.htm#xmlLocalName
</overviewURL>
</overviewDoc>
<categoryBag>
<keyedReference
tModelKey="uuid:c1acf26d-9672-4404-9d70-39b756e62ab4"
keyName="uddi-org:types" keyValue="unchecked"/>
<keyedReference
tModelKey="uuid:c1acf26d-9672-4404-9d70-39b756e62ab4"
keyName="uddi-org:types" keyValue="categorization"/>
</categoryBag>
</tModel>
[/code]

[b]B.3.3 合法值[/b]
The values used in this category system are XML local names. The content of keyValue in a keyedReference that refers to this tModel is equal to the name attribute of the WSDL entity described by the UDDI entity.

[b]B.3.4 使用例子[/b]
A local name keyedReference would be as follows:
[code]
<categoryBag>
<keyedReference
tModelKey="uuid:2ec65201-9109-3919-9bec-c9dbefcaccf6"
keyName="Local service name"
keyValue="StockQuoteService"/>

</categoryBag>
[/code]

[b]B.4 WSDL portType引用tModel[/b]

[b]B.4.1 设计目标[/b]
WSDL entities exhibit many relationships. Specifically, a wsdl:port describes an implementation of a wsdl:binding, and a wsdl:binding describes a binding of a particular wsdl:portType. These same relationships must be expressed in the UDDI mapping. UDDI provides a built-in mechanism, via the tModelInstanceInfo structure, to associate a bindingTemplate with a tModel. But UDDI does not provide a built-in mechanism to describe a relationship between two tModels. The WSDL portType Reference category system provides a mechanism to indicate that a UDDI entity has a relationship with a certain wsdl:portType tModel. This can be applied, for example, to indicate that a wsdl:binding tModel is a binding of a specific wsdl:portType tModel.

[b]B.4.2 定义[/b]
Name: uddi-org:wsdl:portTypeReference

Description: A category system used to reference a wsdl:portType tModel

V3 format key: uddi:uddi.org:wsdl:porttypereference

V1,V2 format key: uuid:082b0851-25d8-303c-b332-f24a6d53e38e

Categorization: categorization

Checked: yes

B.4.2.1 V2 tModel Structure
[code]
<tModel tModelKey="uuid:082b0851-25d8-303c-b332-f24a6d53e38e">
<name>uddi-org:wsdl:portTypeReference</name>
<description xml:lang="en">A category system used to reference a wsdl:portType tModel</description>
<overviewDoc>
<overviewURL>
http://www.oasis-open.org/committees/uddi-spec/doc/tn/uddi-spec-tc-tn-wsdl-v2.htm#portTypeReference
</overviewURL>
</overviewDoc>
<categoryBag>
<keyedReference
tModelKey="uuid:c1acf26d-9672-4404-9d70-39b756e62ab4"
keyName="uddi-org:types" keyValue="categorization"/>
<keyedReference
tModelKey="uuid:c1acf26d-9672-4404-9d70-39b756e62ab4"
keyName="uddi-org:types" keyValue="checked"/>
</categoryBag>
</tModel>
[/code]

[b]B.4.3 合法值[/b]
Valid values for this category system are tModelKeys. The content of the keyValue attribute in a keyedReference that refers to this tModel is the tModelKey of the wsdl:portType tModel being referenced.

As the valid values are entity keys the V3 version of the tModel representing this category system must be categorized with the uddi:uddi.org:categorization:entitykeyvalues category system, with a keyValue of tModelKey.

[b]B.4.4 使用例子[/b]
One would add the following keyedReference to signify that a wsdl:binding implements a specific portType:
[code]
<categoryBag>
<keyedReference
tModelKey="uuid:082b0851-25d8-303c-b332-f24a6d53e38e"
keyName="wsdl:portType Reference"
keyValue="uuid:e8cf1163-8234-4b35-865f-94a7322e40c3"/>

</categoryBag>
[/code]
Note that the keyValue is a tModelKey, which, if queried for using get_tModelDetail, would return the tModel that represents the portType.

[b]B.5 SOAP协议tModel[/b]

[b]B.5.1 设计目标[/b]
Web services can support a wide variety of protocols. Users looking for Web services may want to search for Web services that support a specific protocol. The SOAP Protocol tModel can be used to indicate that a Web service supports the SOAP 1.1 protocol. This tModel correlates to the http://schemas.xmlsoap.org/wsdl/soap/ namespace identified in the WSDL Specification.

[b]B.5.2 定义[/b]
Name: uddi-org:protocol:soap

Description: A tModel that represents the SOAP 1.1 protocol

V3 format key: uddi:uddi.org:protocol:soap

V1,V2 format key: uuid:aa254698-93de-3870-8df3-a5c075d64a0e

Categorization: protocol

B.5.2.1 tModel Structure
[code]
<tModel tModelKey="uuid:aa254698-93de-3870-8df3-a5c075d64a0e">
<name>uddi-org:protocol:soap</name>
<description xml:lang="en">A tModel that represents the SOAP 1.1 protocol</description>
<overviewDoc>
<overviewURL>
http://www.oasis-open.org/committees/uddi-spec/doc/tn/uddi-spec-tc-tn-wsdl-v2.htm#soap
</overviewURL>
</overviewDoc>
<categoryBag>
<keyedReference
tModelKey="uuid:c1acf26d-9672-4404-9d70-39b756e62ab4"
keyName="uddi-org:types" keyValue="protocol"/>
</categoryBag>
</tModel>
[/code]

[b]B.5.3 使用例子[/b]
The SOAP Protocol tModel is used to categorise a binding tModel that corresponds to a wsdl:binding that supports the SOAP 1.1 protocol.
[code]
<tModel tModelKey="uuid:49662926-f4a5-4ba5-b8d0-32ab388dadda">
<name>…</name>
<categoryBag>
<keyedReference
tModelKey="uuid:d01987d1-ab2e-3013-9be2-2a66eb99d824"
keyName="binding namespace"
keyValue="http://example.com/stockquote/"/>
<keyedReference
tModelKey="uuid:6e090afa-33e5-36eb-81b7-1ca18373f457"
keyName="WSDL type"
keyValue="binding"/>
<keyedReference
tModelKey="uuid:082b0851-25d8-303c-b332-f24a6d53e38e"
keyName="portType reference"
keyValue="uuid:e8cf1163-8234-4b35-865f-94a7322e40c3"/>
<keyedReference
tModelKey="uuid:4dc74177-7806-34d9-aecd-33c57dc3a865"
keyName="SOAP protocol"
keyValue="uuid:aa254698-93de-3870-8df3-a5c075d64a0e"/>
<keyedReference
tModelKey="uuid:c1acf26d-9672-4404-9d70-39b756e62ab4"
keyName="uddi-org:types"
keyValue="wsdlSpec"/>
</categoryBag>
<overviewDoc>
<overviewURL>http://location/sample.wsdl</overviewURL>
</overviewDoc>
</tModel>
[/code]

[b]B.6 HTTP协议tModel[/b]

[b]B.6.1 设计目标[/b]
Web services can support a wide variety of protocols. Users looking for Web services may want to search for Web services that support a specific protocol. The HTTP Protocol tModel can be used to indicate that a Web service supports the HTTP protocol. Note that this tModel is different from the HTTP Transport tModel. This tModel represents a protocol; for example, it represents the http://schemas.xmlsoap.org/wsdl/http/ namespace in the WSDL specification. The HTTP Transport tModel represents a transport.

[b]B.6.2 定义[/b]
Name: uddi-org:protocol:http

Description: A tModel that represents the HTTP protocol

V3 format key: uddi:uddi.org:protocol:http

V1,V2 format key: uuid:6e10b91b-babc-3442-b8fc-5a3c8fde0794

Categorization: protocol

B.6.2.1 V2 tModel Structure
[code]
<tModel tModelKey="uuid:6e10b91b-babc-3442-b8fc-5a3c8fde0794">
<name>uddi-org:protocol:http</name>
<description xml:lang="en">A tModel that represents the HTTP protocol</description>
<overviewDoc>
<overviewURL>
http://www.oasis-open.org/committees/uddi-spec/doc/tn/uddi-spec-tc-tn-wsdl-v2.htm#http
</overviewURL>
</overviewDoc>
<categoryBag>
<keyedReference
tModelKey="uuid:c1acf26d-9672-4404-9d70-39b756e62ab4"
keyName="uddi-org:types" keyValue="protocol"/>
</categoryBag>
</tModel>
[/code]

[b]B.6.3 使用例子[/b]
The H
  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值