- 浏览: 2677887 次
- 性别:
- 来自: 北京
文章分类
最新评论
-
80后的童年2:
深入浅出MongoDB应用实战开发网盘地址:https://p ...
MongoDB入门教程 -
shliujing:
楼主在不是精通java和php的前提下,请不要妄下结论。
PHP、CakePHP哪凉快哪呆着去 -
安静听歌:
希望可以一给一点点注释
MySQL存储过程之代码块、条件控制、迭代 -
qq287767957:
PHP是全宇宙最强的语言!
PHP、CakePHP哪凉快哪呆着去 -
rryymmoK:
深入浅出MongoDB应用实战开发百度网盘下载:链接:http ...
MongoDB入门教程
原文链接:http://www.oasis-open.org/committees/uddi-spec/doc/tn/uddi-spec-tc-tn-wsdl-v202-20040631.htm
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 注意
1 介绍
Universal Description,Discovery & Integration(UDDI)规范提供了一种描述和发现Web服务和Web服务提供者的跨平台的方式。UDDI数据结构为基本服务信息
的描述提供了一个框架,以及一个可扩展机制来使用任何标准描述语言指定详细的服务访问信息。在特定的工业领域和不同基本的协议栈存在许多这样的语言。
Web Service Description Language(WSDL)是一个描述接口,协议绑定和网络服务部署细节的一般目的XML语言。WSDL通过提供一个描述抽象接口和任意网络服务
协议绑定的统一方式来补充UDDI标准。该文档的目的是阐明两者的关系以及描述一个映射WSDL描述到UDDI数据结构的推荐方式。
一致的和彻底的WSDL映射对UDDI工具集很重要。
1.1 目标和需求
该映射的首要目标是:
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数据模型有稍许不同,该映射确保在两种版本下都可以捕获信息。
1.2 和版本1最佳实践的关系
该文档基于在UDDI注册中心使用WSDL,版本1.08来构建,并提供一个围绕着WSDL灵活性的扩充的建模实践。该映射与已经存在的最佳实践里描述的那个映射之间
的首要区别是该映射提供一个方法论来表示单独的Web服务artifacts。
作为技术笔记,该文档没有替换版本1最佳实践。如果不需要额外的灵活性,已经存在的最佳实践仍然可以使用,特别是当UDDI artifacts为手动发布时
可以预想,本技术笔记描述的该方法的实现将被开发,而且一旦那些实现的经验被获得则该技术笔记将变成一个最佳实践。
一个最终的目标是与已经存在的最佳实践兼容,其中一个表示一个使用本文档描述的方式发布一个WSDL binding的tModel应该对使用版本1最佳实践方式的客户端
可用。
1.3 术语
本文档的关键字must, must not, required, shall, shall not, should, should not, recommended, may和optional将和在[RFC2119]中描述的一样被解释。
2 映射两种数据模型:WSDL&UDDI
2.1 WSDL数据模型
对目标和需求的上下文中的WSDL的复习将帮助在UDDI中指引一个新的映射实践。
2.1.1 portType
WSDL里的核心构件就是portType。一个portType为一个抽象的操作集,可能有一个或多个Web服务支持它。一个WSDL portType根据消息定义来定义这些操作,消息
定义通常依赖于XML Schema语言来描述每个消息的呈现。一个单独的WSDL文档可能包含多种portType实体。每个portType通过它的本地名和包含该portType的定义
元素的目标名字空间来唯一识别。
WSDL portTypes可能被多于一个Web服务实现。Web服务旨在支持一个给定的portType必须不只粘着在作为WSDL定义的一部分的消息格式;它们必须也粘着在隐含为
portTye的一部分语义协议。该一致性允许程序来认为如果并且只有两个Web服务实现了一个共用的portType时它们可替换。
2.1.2 binding
WSDL portTypes为抽象的Web服务描述并且没有指定关于使用来传输消息的编码和传输协议的信息。为了在WSDL里指定编码和传输协议细节,必须定义另一个结构,
即binding。一个WSDL binding指定一个可能用来与一个特殊WSDL portType通信的编码和传输协议特殊集。一个WSDL binding通过一个QName引用指定它的portType
引用的portType可能或者可能不在binding本身的同一目标名字空间里。而一个单独的WSDL文档可能包含包含该binding的定义元素的目标名字空间。
和portTypes一样,WSDL bindings为抽象的定义而且不表示Web服务实现,多个Web服务可能实现同一WSDL binding。
2.1.3 service和port
最后,WSDL定义一个Web服务实现为具有一些命名的ports的服务。每个port使用一个命名的binding中定义的协议来实现一个特别的portType。一个服务可能暴露
多个ports来让一个单独的portType对多种协议可得。一个服务也可能暴露多个ports来从一个单独的逻辑实体暴露多于一个portType。一个WSDL port通过一个
QName引用来指定它实现的binding。该引用的binding可能或者可能不在port本身的同一目标名字空间里。一个单独的WSDL文档可能包含多个服务。一个服务通过
它的本地名和包含该服务的定义元素的目标名字空间的结合来唯一标识。同样的,一个port通过它的本地名和包含该port的定义元素的目标名字空间的结合来
唯一标识。
2.1.4 import
WSDL中的import指令允许把这些不同的实体分离到多个文件。像这样,一个WSDL文档可能由一个单独的portType,多个portTypes,一个imports它的portType定义
的单独的binding,多个bindings,一个单独的service,多个services等等组成。WSDL数据模型提供WSDL实体的组合和重用的巨大的灵活性
给定这个灵活性,在组合和区分方面一个WSDL文档最重要的组件为定义元素的目标名字空间和在该目标名字空间中识别每个portType,binding,service和port
的本地名。
2.2 UDDI数据模型
作为理解下面的部分的援助,我们在这里提供在UDDI注册中心上下文中与WSDL的使用非常相关的两种UDDI数据结构的一个简短的概览:tModel和businessService。
2.2.1 tModels
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
时的选择标准。
2.2.2 businessService & bindingTemplate
在UDDI里服务通过businessService数据结构表示,服务怎样以及在哪里访问的细节通过一个或多个bindingTemplate结构提供。businessService可以被认为是
一个逻辑的服务容器。bindingTemplate结构包含服务的accessPoint,以及它要实现的tModels的引用。
2.3 映射WSDL和UDDI
WSDL设计来支持模块化和可重用的定义,每个定义artifact同其他定义artifacts有某种关系。在1.1节描述到,该技术笔记的目标和它定义的映射是为了允许在
UDDI里自动注册WSDL定义,允许基于特殊的WSDL artifacts和metadata的精确和灵活的UDDI查询,维护和版本1最佳实践方法论的兼容性,以及提供对UDDI V2和
UDDI V3的一致映射。映射本身达到了第一个目标。第二个目标提供了在该映射里使用的基本原理。为了支持基于特殊的WSDL artifacts和metadata的查询,该
映射必须能够表示单独的WSDL artifacts以及artifacts间的关系。这个目标也提供在UDDI中必须捕获的信息的基本原理。在某些情况下额外的信息也必须引入
进来以支持第三个目标。为了达到第四个目标,在那两个映射里捕获的信息应该尽可能一致。
2.3.1 映射概览
映射描述了一个映射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实体间的关系。
2.3.2 与版本1映射的比较
关于该映射的一个需要注意的重要事情(特别是当和版本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信息。
2.3.3 新规范的tModels
该映射介绍了一些用来表示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必须在UDDI注册中心注册来支持该映射。V1/V2和V3 keys为这些tModels给定。
2.3.4 一般的习惯约定
在该映射中,每个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"类型。
2.3.5 对多种UDDI API版本的支持
描述的映射设计来与UDDI API用来访问它的同一版本。API版本的差别控制了它们的差别,这些差别在合适的章节里指出了。
2.3.6 WSDL组件参考
一个UDDI实体一般引用使用overviewURL元素的技术规范。上面提到,在该映射中一个单独的WSDL文档可能映射到多个tModels,并且每个tModel引用文件里的一个
特殊的WSDL实体。特殊的WSDL实体通过它的本地名和包含该WSDL实体的定义元素的目标名字空间唯一标识。这个识别信息应该由UDDI实体决定,对特殊的
UDDI实体类型适用的名字空间和本地名使用特殊的映射。或者,overviewURL值可能包含一个fragment标识符来识别特殊的WSDL实体。如果可选的fragment
识别符被使用,则overviewURL的值应该符合附录C中描述的语法。
2.3.7 WSDL扩展性元素
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映射中。
2.3.8 对WSDL实现文档的支持
在本技术笔记的上下文中,一个WSDL实现文档为一个包含至少一个wsdl:service元素和它相关的wsdl:port元素的WSDL文档。关于该实现信息在UDDI里怎样描述有
两种选项:
1,在UDDI模型里的信息为权威信息并且没有对一个WSDL实现文档的引用
2,一个对一个外部WSDL实现文档的引用可以被存储在UDDI中并且UDDI中其余的信息用来在外部WSDL资源中描述合适的元素。
该文档的body中描述的映射与上面的第一个选项一致,并且它被假设为默认的映射。第二个选项在附录A中描述了。
2.4 在UDDI V2里映射WSDL1.1
本节描述了详细的映射WSDL1.1 artifacts到UDDI V2数据模型。
2.4.1 wsdl:portType -> uddi:tModel
一个wsdl:portType必须建模为一个uddi:tModel。
关于一个portType必须捕获的最少的信息为实体类型,它的本地名,它的名字空间,和定义该portType的WSDL文档的位置。捕获实体类型允许用户来搜索表示
portType artifacts的tModels。捕获本地名,名字空间和WSDL位置允许用户找到制定的portType artifact的定义的位置。
wsdl:portType信息如下所示捕获:
tModel的uddi:name元素必须为wsdl:portType的name属性的值。
tModel必须包含一个categoryBag,并且categoryBag必须包含一个具有该WSDL Entity Type分类系统的tModelKey和一个"portType"的keyValue的
KeykeyedReference。
如果wsdl:portType有一个targetNamespace则categoryBag必须也包含一个额外的具有该XML Namespace分类系统的tModelKey和一个包含wsdl:portType的
wsdl:definitions元素的目标名字空间的keyValue的keyedReference。如果portType没有targetNamespace,一个categoryBag必须不包含一个该XML
Namespace分类系统的KeyedReference。
tModel必须包含一个具有一个包含描述wsdl:portType的WSDL文档的位置的overviewURL的overviewDoc。
2.4.1.1 wsdl:portType映射总结
WSDL UDDI
portType tModel(归类为portType)
portType的名字空间 categoryBag中的keyedReference
portType的本地名 tModel名
WSDL文档的位置 overviewURL
2.4.2 wsdl:bingding -> uddi:tModel
一个wsdl:binding必须建模为一个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元素必须为wsdl:binding的name属性的值。
tModel必须包含一个categoryBag,而且categoryBag必须包含至少下列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必须也包含一个额外的具有该XML Namespace分类系统的tModelKey的keyedReference和包含
wsdl:binding的wsdl:definitions元素的目标名字空间的keyValue。如果binding没有targetNamespace,一个categoryBag必须不包含一个该XML Namespace
分类系统的keyedReference。
tModel必须包含一个具有一个包含描述wsdl:binding的WSDL文档位置的overviewURL的overviewDoc。
2.4.2.1 wsdl:binding扩展
在下面的章节描述到,如果可用,在一个对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使用同样的方式来
被定义和使用。
2.4.2.1.1 soap:binding
如果wsdl:binding包含一个来自http://schemas.xmlsoap.org/wsdl/soap/名字空间的soap:binding扩展性元素则categoryBag必须包含一个具有一个
Protocol Categorization分类系统的tModelKey的keyedReference和一个SOAP Protocol tModel的tModelKey的keyValue。
如果soap:binding的transport属性值为http://schemas.xmlsoap.org/soap/http则categoryBag必须包含一个具有一个Transport Categorization分类
系统的tModelKey的keyedReference和一个HTTP Protocol tModel的tModelKey的keyValue。
如果transport属性的值是其他任何东西,则bindingTemplate必须包含一个额外的具有一个Transport Categorization分类系统的tModelKey的
keyedReference和一个合适的transport tModel的tModelKey的keyValue。
2.4.2.1.2 http:binding
如果wsdl:binding包含一个来自http://schemas.xmlsoap.org/wsdl/http/名字空间的http:binding扩展性元素则categoryBag必须包含一个具有一个
Protocol Categorization分类系统的tModelKey的keyedReference和一个HTTP Protocol tModel的tModelKey的keyValue。
注意这是一个与HTTP Transport tModel不同的tModel,并且在这种情况下没有分开的transport tModel,这样在来自Transport Categorization分类系统的
categoryBag中就没有keyedReference。
2.4.2.1.3 其他wsdl:binding扩展
其他wsdl:binding扩展性元素以一个类似的方式处理。假设提供其他bindings的vendors将提供合适的protocol和transport tModels。
2.4.2.2 wsdl:binding映射总结
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
2.4.3 wsdl:service -> uddi:businessService
一个wsdl:service必须建模为一个uddi:businessService。一个已经存在的businessSerice可能被使用或者一个新的businessService可能
被创建。只有一个wsdl:service可以被一个单独的uddi:businessService建模。
必须被捕获的关于一个服务的最少的信息为它的实体类型,它的本地名,它的名字空间,和它支持的ports列表。捕获实体类型允许用户搜索通过WSDL定义描述的
服务。ports列表提供对消费服务必需的技术信息的访问。
wsdl:service信息如下所示捕获:
如果一个新的businessService被创建,该businessService的则uddi:name元素应该为人类可读的名字,尽管如果没有指定人类可读的名字,则一个uddi:
name必须被添加,包含wsdl:service的name属性的值。
businessService必须包含一个categoryBag,而且categoryBag必须包含至少以下keyedReference元素:
1,一个具有一个WSDL Entity Type分类系统的tModelKey和一个"service"的keyValue的keyedReference
2,一个具有一个XML Local Name分类系统的tModelKey和一个wsdl:service的name属性的值keyValue的keyedReference
如果wsdl:service有一个targetNamespace则categoryBag必须也包含一个额外的具有一个XML Namespace分类系统的tModelKey和一个包含wsdl:service的
wsdl:definitions元素的目标名字空间的keyValue的keyedReference。如果服务没有targetNamespace,一个categoryBag必须不包含一个XML Namespace
分类系统的keyedReference。
businessService的bindingTemplates元素必须包含建模服务的ports的bindingTemplate元素,这在下面的章节描述了。
2.4.3.1 映射总结
WSDL UDDI
Service businessService(归类为服务)
Service的Namespace categoryBag中的keyedReference
Service的本地名 categoryBag中的keyedReference;也可选为服务的名字
2.4.4 wsdl:port -> uddi:bindingTemplate
一个wsdl:port必须建模为一个uddi:bindingTemplate。
关于一个port的必须被捕获的最少的信息是它实现的binding,它实现的portType,和它的本地名。
通过捕获binding,用户可以搜索实现一个特定的binding的服务。通过捕获portType,用户可以搜索实现了一个特殊的portType的服务而不必知道服务实现的
特定的binding。
wsdl:port信息如下所示捕获:
bindingTemplate tModelInstanceDetails元素必须包含至少以下tModelInstanceInfo元素:
1,一个具有一个对该port实现的wsdl:binding建模的tModel的tModelKey的tModelInstanceInfo。该tModelInstanceInfo的instanceParms必须包含wsdl:port
本地名。
2,一个具有一个对该wsdl:portType建模的tModel的tModelKey的tModelInstanceInfo。
2.4.4.1 映射总结
WSDL UDDI
port bindingTemplate
名字空间 包含的businessService的keyedReference中捕获
port的本地名 该binding的tModel相关的tModelInstanceInfo的instanceParms
port实现的binding 具有符合该binding的tModel的tModelKey的tModelInstanceInfo
port实现的portType 具有符合该portType的tModel的tModelKey的tModelInstanceInfo
2.4.5 wsdl:port Address Extensions -> uddi:bindingTemplate
uddi:bindingTemplate必须包含Web服务的地址信息。该信息来自wsdl:port地址扩展性元素。
2.4.5.1 soap:address -> uddi:accessPoint
一个soap:address必须在建模包含soap:address的wsdl:port的uddi:bindingTemplate中建模为uddi:accessPoint。
soap:address信息如下所示被捕获:
1,accessPoint值必须为soap:address元素的location属性的值
2,accessPoint的URLType属性必须与soap:binding指定的transport一致,或者如果没有一致存在则为"other"。例如在HTTP transport情况下,URLType
属性必须为"http"。
如果"other"被使用则一个引用合适的vendor定义的transport tModel的tModelInstanceInfo元素必须添加到bindingTemplate。
2.4.5.2 http:address -> uddi:accessPoint
一个http:address在建模包含http:address的wsdl:port的uddi:bindingTemplate中必须建模为一个uddi:accessPoint。
http:address信息如下所示捕获:
1,accessPoint值必须为http:address元素的location属性的值
2,accessPoint的URLType属性必须为"http"或者"https"
2.4.5.3 其他wsdl:port Address扩展
任何其他address扩展性元素在建模包含address扩展性元素的wsdl:port的uddi:bindingTemplate中必须建模为uddi:accessPoint。
address信息如下所示捕获:
1,accessPoint值必须为address扩展性元素的location属性的值。如果location属性的值不能映射到accessPoint值则WSDL实现文档方式必须被使用。
参考附录A来得到更多信息。
2,accesPoint的URLType属性必须与该URL相关的transport协议一致,或者如果没有合适的定义的属性值则为"other"。
2.5 在UDDI V3中映射WSDL 1.1的区别
本节描述在UDDI V3视图中的模型的差别,模型是UDDI V3规范中重要的条目。
2.5.1 主要差别
主要差别为:
1,实体将拥有V3 keys而不是V2 keys。
2,一个accessPoint有一个useType属性而不是一个URLType属性。
2.5.2 在UDDI V3规范中与wsdlDeployment的比较
UDDI V3规范包含对wsdlDeployment的支持,wsdlDeployment表现为一个accessPoint的useType属性的值和一个bindingTemplate的分类。wsdlDeployment的使用
与本技术笔记不兼容,因为它假设没有WSDL建模会执行,对WSDL不知道任何事情,更不用说它的URL。
3 一个完整的例子
考虑下面的基于在WSDL1.1规范中表示的WSDL文档的WSDL例子。这个例子显示了这个WSDL文档怎样分解到两个tModels(一个为portType另一个为binding)以及一个
具有一个bindingTemplate的businessService。然后它显示可以用来作发现目的的UDDI API查询。
3.1 WSDL例子
注意该WSDL文档有一个portType,一个binding,一个service和一个port。像这样,这个例子展示了最简单的WSDL文档。同时也注意一下该WSDL的位置位于
http://location/sample.wsdl。
3.2 UDDI V2模型
3.2.1 UDDI portType tModel
WSDL portType 实体映射到一个tModel。tModel名字和WSDL portType本地名一样。tModel包含一个指定WSDL名字空间的categoryBag,并且它指示了tModel为
"portType"类型。overviewDoc提供了一个对WSDL文档的指针。
3.2.2 UDDI binding tModel
WSDL binding实体映射到一个tModel。tModel名字与WSDL binding的本地名一样。tModel包含一个指定WSDL名字空间的categoryBag,它指示了tModel为"binding"
类型,它提供一个对portType tModel的指针,并且它指示了该binding支持什么协议。wsdlSpec keyedReference确保了用户可以找到使用在版本1最佳实践里定
义的惯例的tModel。overviewDoc提供了一个对WSDL文档的指针。
3.2.3 UDDI businessService和bindingTemplate
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。
3.3 例子V2查询
本节显示对给定的例子的模型怎样执行多种UDDI V2查询。
3.3.1 基于portType名寻找tModel
在名字空间http://example.com/stockquote/寻找StockQuotePortType的portType tModel。
这应该返回tModelKey uddi:e8cf1163-8234-4b35-865f-94a7322e40c3。
3.3.2 基于portType寻找bindings
寻找StockQuotePortType的所有bindings。
这应该返回tModelKey uddi:49662926-f4a5-4ba5-b8d0-32ab388dadda。
3.3.3 寻找portType的实现
寻找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的列表。
这应该返回serviceKey 102b114a-52e0-4af4-a292-02700da543d4。
现在第二个调用用来寻找该特殊service的合适的bindings。
这应该返回bindingKey f793c521-0daf-434c-8700-0e32da232e74。
3.3.4 寻找binding的实现
寻找StockQuoteSoapBind的所有实现。
这与前面的例子非常类似,除了tModelBag包含binding tModel的key而不是portType tModel。
3.3.5 寻找portType的SOAP实现
寻找StockQuotePortType的支持SOAP的所有实现。
至少需要三个查询。第一个查询返回所有的引用portType tModel并且归类为SOAP的binding tModels。
下一步发生什么取决于在整个查询中是否需要其他criteria。
3.3.5.1 没有其他Criteria
这种情况下至少需要两个查询,在上面的寻找一个单独的binding的实现的例子中描述了。第一个查询为一个find_service调用,它必须包含"orAllKeys"
findQualifier并且必须提供一个包含第一个查询返回的所有的binding tModel keys的tModelBag。这将返回有一个引用至少binding tModels中的一个的
bindingTemplate的services列表。
最后,对每个这样的service,必须或者调用get_serviceDetail或者find_binding。
3.3.5.2 其他Criteria
这种情况也至少需要两个查询,这取决于找到的binding tModels和services的数量。对每个binding tModel需要一个find_service查询并且默认的"andAllKeys"
必须被使用,因为其他的criteria也将应用到该查询。这将返回有一个引用特殊的binding tModel并也满足其他criteria的bindingTemplate的services列表。
3.3.6 寻找portType的SOAP/HTTP实现
这与前面的情况类似,除了第一个查询除了包含SOAP协议之外必须也包含一个HTTP transport的category。
3.3.7 寻找binding的portType
一个binding的portType包含在binding tModel的categoryBag中。一旦获得binding的tModel则不需要查询。
具有tModelKey="uuid:082b0851-25d8-303c-b332-f24a6d53e38e"的keyedReference的keyValue包含portType tModelKey。
3.3.8 基于WSDL服务寻找businessService
在名字空间http://example.com/stockquote/寻找StockQuoteService的businessService。
这应该返回serviceKey 102b114a-52e0-4af4-a292-02700da543d4。
3.4 例子V3查询
本节包含一些来自前面的章节的查询例子的重写来使用UDDI V3 API的新特性。其他查询没有很大不同。显示的实体keys假设V2模型通过一个root registry迁移
到V3。
3.4.1 需找portType的实现
在UDDI V3 API中一个serviceKey对find_binding是可选的,可以用一个单独的查询实现它。
这将返回bindingKey uddi:f793c521-0daf-434c-8700-0e32da232e74。
3.4.2 寻找portType的SOAP实现
3.4.2.1 没有其他Criteria
由于在UDDI V3 API里serviceKey对find_binding是可选的并且可以嵌入一个find_tModel调用,可以用一个单独的查询实现它:
这将返回bindingKey uddi:f793c521-0daf-434c-8700-0e32da232e74。
4 参考
4.1 规范
[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/
A 外部WSDL实现文档
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.
A.1 捕获URL
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.
A.2 从WSDL获得Port Address
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.
A.3 查询使用WSDL实现文档的服务
It is possible to query the services that have a WSDL Implementation Document by querying specifying the tModelKey of the WSDL Address tModel.
B 规范tModels
This Technical Note introduces a number of canonical tModels that are used to represent WSDL metadata and relationships. These tModels are defined here.
B.1 WSDL实体型tModel
B.1.1 设计目标
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.1.2 定义
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
B.1.3 合法值
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.1.4 使用例子
A V2 tModel representing a portType would have a categoryBag representing its type:
B.2 XML名字空间tModel
B.2.1 设计目标
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.2.2 定义
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
B.2.3 合法值
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.2.4 使用例子
A namespace keyedReference would be as follows:
B.3 XML本地名字tModel
B.3.1 设计目标
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.3.2 定义
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
B.3.3 合法值
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.3.4 使用例子
A local name keyedReference would be as follows:
B.4 WSDL portType引用tModel
B.4.1 设计目标
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.4.2 定义
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
B.4.3 合法值
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.4.4 使用例子
One would add the following keyedReference to signify that a wsdl:binding implements a specific portType:
Note that the keyValue is a tModelKey, which, if queried for using get_tModelDetail, would return the tModel that represents the portType.
B.5 SOAP协议tModel
B.5.1 设计目标
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.5.2 定义
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
B.5.3 使用例子
The SOAP Protocol tModel is used to categorise a binding tModel that corresponds to a wsdl:binding that supports the SOAP 1.1 protocol.
B.6 HTTP协议tModel
B.6.1 设计目标
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.6.2 定义
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
B.6.3 使用例子
The H
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 注意
1 介绍
Universal Description,Discovery & Integration(UDDI)规范提供了一种描述和发现Web服务和Web服务提供者的跨平台的方式。UDDI数据结构为基本服务信息
的描述提供了一个框架,以及一个可扩展机制来使用任何标准描述语言指定详细的服务访问信息。在特定的工业领域和不同基本的协议栈存在许多这样的语言。
Web Service Description Language(WSDL)是一个描述接口,协议绑定和网络服务部署细节的一般目的XML语言。WSDL通过提供一个描述抽象接口和任意网络服务
协议绑定的统一方式来补充UDDI标准。该文档的目的是阐明两者的关系以及描述一个映射WSDL描述到UDDI数据结构的推荐方式。
一致的和彻底的WSDL映射对UDDI工具集很重要。
1.1 目标和需求
该映射的首要目标是:
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数据模型有稍许不同,该映射确保在两种版本下都可以捕获信息。
1.2 和版本1最佳实践的关系
该文档基于在UDDI注册中心使用WSDL,版本1.08来构建,并提供一个围绕着WSDL灵活性的扩充的建模实践。该映射与已经存在的最佳实践里描述的那个映射之间
的首要区别是该映射提供一个方法论来表示单独的Web服务artifacts。
作为技术笔记,该文档没有替换版本1最佳实践。如果不需要额外的灵活性,已经存在的最佳实践仍然可以使用,特别是当UDDI artifacts为手动发布时
可以预想,本技术笔记描述的该方法的实现将被开发,而且一旦那些实现的经验被获得则该技术笔记将变成一个最佳实践。
一个最终的目标是与已经存在的最佳实践兼容,其中一个表示一个使用本文档描述的方式发布一个WSDL binding的tModel应该对使用版本1最佳实践方式的客户端
可用。
1.3 术语
本文档的关键字must, must not, required, shall, shall not, should, should not, recommended, may和optional将和在[RFC2119]中描述的一样被解释。
2 映射两种数据模型:WSDL&UDDI
2.1 WSDL数据模型
对目标和需求的上下文中的WSDL的复习将帮助在UDDI中指引一个新的映射实践。
2.1.1 portType
WSDL里的核心构件就是portType。一个portType为一个抽象的操作集,可能有一个或多个Web服务支持它。一个WSDL portType根据消息定义来定义这些操作,消息
定义通常依赖于XML Schema语言来描述每个消息的呈现。一个单独的WSDL文档可能包含多种portType实体。每个portType通过它的本地名和包含该portType的定义
元素的目标名字空间来唯一识别。
WSDL portTypes可能被多于一个Web服务实现。Web服务旨在支持一个给定的portType必须不只粘着在作为WSDL定义的一部分的消息格式;它们必须也粘着在隐含为
portTye的一部分语义协议。该一致性允许程序来认为如果并且只有两个Web服务实现了一个共用的portType时它们可替换。
2.1.2 binding
WSDL portTypes为抽象的Web服务描述并且没有指定关于使用来传输消息的编码和传输协议的信息。为了在WSDL里指定编码和传输协议细节,必须定义另一个结构,
即binding。一个WSDL binding指定一个可能用来与一个特殊WSDL portType通信的编码和传输协议特殊集。一个WSDL binding通过一个QName引用指定它的portType
引用的portType可能或者可能不在binding本身的同一目标名字空间里。而一个单独的WSDL文档可能包含包含该binding的定义元素的目标名字空间。
和portTypes一样,WSDL bindings为抽象的定义而且不表示Web服务实现,多个Web服务可能实现同一WSDL binding。
2.1.3 service和port
最后,WSDL定义一个Web服务实现为具有一些命名的ports的服务。每个port使用一个命名的binding中定义的协议来实现一个特别的portType。一个服务可能暴露
多个ports来让一个单独的portType对多种协议可得。一个服务也可能暴露多个ports来从一个单独的逻辑实体暴露多于一个portType。一个WSDL port通过一个
QName引用来指定它实现的binding。该引用的binding可能或者可能不在port本身的同一目标名字空间里。一个单独的WSDL文档可能包含多个服务。一个服务通过
它的本地名和包含该服务的定义元素的目标名字空间的结合来唯一标识。同样的,一个port通过它的本地名和包含该port的定义元素的目标名字空间的结合来
唯一标识。
2.1.4 import
WSDL中的import指令允许把这些不同的实体分离到多个文件。像这样,一个WSDL文档可能由一个单独的portType,多个portTypes,一个imports它的portType定义
的单独的binding,多个bindings,一个单独的service,多个services等等组成。WSDL数据模型提供WSDL实体的组合和重用的巨大的灵活性
给定这个灵活性,在组合和区分方面一个WSDL文档最重要的组件为定义元素的目标名字空间和在该目标名字空间中识别每个portType,binding,service和port
的本地名。
2.2 UDDI数据模型
作为理解下面的部分的援助,我们在这里提供在UDDI注册中心上下文中与WSDL的使用非常相关的两种UDDI数据结构的一个简短的概览:tModel和businessService。
2.2.1 tModels
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
时的选择标准。
2.2.2 businessService & bindingTemplate
在UDDI里服务通过businessService数据结构表示,服务怎样以及在哪里访问的细节通过一个或多个bindingTemplate结构提供。businessService可以被认为是
一个逻辑的服务容器。bindingTemplate结构包含服务的accessPoint,以及它要实现的tModels的引用。
2.3 映射WSDL和UDDI
WSDL设计来支持模块化和可重用的定义,每个定义artifact同其他定义artifacts有某种关系。在1.1节描述到,该技术笔记的目标和它定义的映射是为了允许在
UDDI里自动注册WSDL定义,允许基于特殊的WSDL artifacts和metadata的精确和灵活的UDDI查询,维护和版本1最佳实践方法论的兼容性,以及提供对UDDI V2和
UDDI V3的一致映射。映射本身达到了第一个目标。第二个目标提供了在该映射里使用的基本原理。为了支持基于特殊的WSDL artifacts和metadata的查询,该
映射必须能够表示单独的WSDL artifacts以及artifacts间的关系。这个目标也提供在UDDI中必须捕获的信息的基本原理。在某些情况下额外的信息也必须引入
进来以支持第三个目标。为了达到第四个目标,在那两个映射里捕获的信息应该尽可能一致。
2.3.1 映射概览
映射描述了一个映射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实体间的关系。
2.3.2 与版本1映射的比较
关于该映射的一个需要注意的重要事情(特别是当和版本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信息。
2.3.3 新规范的tModels
该映射介绍了一些用来表示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必须在UDDI注册中心注册来支持该映射。V1/V2和V3 keys为这些tModels给定。
2.3.4 一般的习惯约定
在该映射中,每个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"类型。
2.3.5 对多种UDDI API版本的支持
描述的映射设计来与UDDI API用来访问它的同一版本。API版本的差别控制了它们的差别,这些差别在合适的章节里指出了。
2.3.6 WSDL组件参考
一个UDDI实体一般引用使用overviewURL元素的技术规范。上面提到,在该映射中一个单独的WSDL文档可能映射到多个tModels,并且每个tModel引用文件里的一个
特殊的WSDL实体。特殊的WSDL实体通过它的本地名和包含该WSDL实体的定义元素的目标名字空间唯一标识。这个识别信息应该由UDDI实体决定,对特殊的
UDDI实体类型适用的名字空间和本地名使用特殊的映射。或者,overviewURL值可能包含一个fragment标识符来识别特殊的WSDL实体。如果可选的fragment
识别符被使用,则overviewURL的值应该符合附录C中描述的语法。
2.3.7 WSDL扩展性元素
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映射中。
2.3.8 对WSDL实现文档的支持
在本技术笔记的上下文中,一个WSDL实现文档为一个包含至少一个wsdl:service元素和它相关的wsdl:port元素的WSDL文档。关于该实现信息在UDDI里怎样描述有
两种选项:
1,在UDDI模型里的信息为权威信息并且没有对一个WSDL实现文档的引用
2,一个对一个外部WSDL实现文档的引用可以被存储在UDDI中并且UDDI中其余的信息用来在外部WSDL资源中描述合适的元素。
该文档的body中描述的映射与上面的第一个选项一致,并且它被假设为默认的映射。第二个选项在附录A中描述了。
2.4 在UDDI V2里映射WSDL1.1
本节描述了详细的映射WSDL1.1 artifacts到UDDI V2数据模型。
2.4.1 wsdl:portType -> uddi:tModel
一个wsdl:portType必须建模为一个uddi:tModel。
关于一个portType必须捕获的最少的信息为实体类型,它的本地名,它的名字空间,和定义该portType的WSDL文档的位置。捕获实体类型允许用户来搜索表示
portType artifacts的tModels。捕获本地名,名字空间和WSDL位置允许用户找到制定的portType artifact的定义的位置。
wsdl:portType信息如下所示捕获:
tModel的uddi:name元素必须为wsdl:portType的name属性的值。
tModel必须包含一个categoryBag,并且categoryBag必须包含一个具有该WSDL Entity Type分类系统的tModelKey和一个"portType"的keyValue的
KeykeyedReference。
如果wsdl:portType有一个targetNamespace则categoryBag必须也包含一个额外的具有该XML Namespace分类系统的tModelKey和一个包含wsdl:portType的
wsdl:definitions元素的目标名字空间的keyValue的keyedReference。如果portType没有targetNamespace,一个categoryBag必须不包含一个该XML
Namespace分类系统的KeyedReference。
tModel必须包含一个具有一个包含描述wsdl:portType的WSDL文档的位置的overviewURL的overviewDoc。
2.4.1.1 wsdl:portType映射总结
WSDL UDDI
portType tModel(归类为portType)
portType的名字空间 categoryBag中的keyedReference
portType的本地名 tModel名
WSDL文档的位置 overviewURL
2.4.2 wsdl:bingding -> uddi:tModel
一个wsdl:binding必须建模为一个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元素必须为wsdl:binding的name属性的值。
tModel必须包含一个categoryBag,而且categoryBag必须包含至少下列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必须也包含一个额外的具有该XML Namespace分类系统的tModelKey的keyedReference和包含
wsdl:binding的wsdl:definitions元素的目标名字空间的keyValue。如果binding没有targetNamespace,一个categoryBag必须不包含一个该XML Namespace
分类系统的keyedReference。
tModel必须包含一个具有一个包含描述wsdl:binding的WSDL文档位置的overviewURL的overviewDoc。
2.4.2.1 wsdl:binding扩展
在下面的章节描述到,如果可用,在一个对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使用同样的方式来
被定义和使用。
2.4.2.1.1 soap:binding
如果wsdl:binding包含一个来自http://schemas.xmlsoap.org/wsdl/soap/名字空间的soap:binding扩展性元素则categoryBag必须包含一个具有一个
Protocol Categorization分类系统的tModelKey的keyedReference和一个SOAP Protocol tModel的tModelKey的keyValue。
如果soap:binding的transport属性值为http://schemas.xmlsoap.org/soap/http则categoryBag必须包含一个具有一个Transport Categorization分类
系统的tModelKey的keyedReference和一个HTTP Protocol tModel的tModelKey的keyValue。
如果transport属性的值是其他任何东西,则bindingTemplate必须包含一个额外的具有一个Transport Categorization分类系统的tModelKey的
keyedReference和一个合适的transport tModel的tModelKey的keyValue。
2.4.2.1.2 http:binding
如果wsdl:binding包含一个来自http://schemas.xmlsoap.org/wsdl/http/名字空间的http:binding扩展性元素则categoryBag必须包含一个具有一个
Protocol Categorization分类系统的tModelKey的keyedReference和一个HTTP Protocol tModel的tModelKey的keyValue。
注意这是一个与HTTP Transport tModel不同的tModel,并且在这种情况下没有分开的transport tModel,这样在来自Transport Categorization分类系统的
categoryBag中就没有keyedReference。
2.4.2.1.3 其他wsdl:binding扩展
其他wsdl:binding扩展性元素以一个类似的方式处理。假设提供其他bindings的vendors将提供合适的protocol和transport tModels。
2.4.2.2 wsdl:binding映射总结
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
2.4.3 wsdl:service -> uddi:businessService
一个wsdl:service必须建模为一个uddi:businessService。一个已经存在的businessSerice可能被使用或者一个新的businessService可能
被创建。只有一个wsdl:service可以被一个单独的uddi:businessService建模。
必须被捕获的关于一个服务的最少的信息为它的实体类型,它的本地名,它的名字空间,和它支持的ports列表。捕获实体类型允许用户搜索通过WSDL定义描述的
服务。ports列表提供对消费服务必需的技术信息的访问。
wsdl:service信息如下所示捕获:
如果一个新的businessService被创建,该businessService的则uddi:name元素应该为人类可读的名字,尽管如果没有指定人类可读的名字,则一个uddi:
name必须被添加,包含wsdl:service的name属性的值。
businessService必须包含一个categoryBag,而且categoryBag必须包含至少以下keyedReference元素:
1,一个具有一个WSDL Entity Type分类系统的tModelKey和一个"service"的keyValue的keyedReference
2,一个具有一个XML Local Name分类系统的tModelKey和一个wsdl:service的name属性的值keyValue的keyedReference
如果wsdl:service有一个targetNamespace则categoryBag必须也包含一个额外的具有一个XML Namespace分类系统的tModelKey和一个包含wsdl:service的
wsdl:definitions元素的目标名字空间的keyValue的keyedReference。如果服务没有targetNamespace,一个categoryBag必须不包含一个XML Namespace
分类系统的keyedReference。
businessService的bindingTemplates元素必须包含建模服务的ports的bindingTemplate元素,这在下面的章节描述了。
2.4.3.1 映射总结
WSDL UDDI
Service businessService(归类为服务)
Service的Namespace categoryBag中的keyedReference
Service的本地名 categoryBag中的keyedReference;也可选为服务的名字
2.4.4 wsdl:port -> uddi:bindingTemplate
一个wsdl:port必须建模为一个uddi:bindingTemplate。
关于一个port的必须被捕获的最少的信息是它实现的binding,它实现的portType,和它的本地名。
通过捕获binding,用户可以搜索实现一个特定的binding的服务。通过捕获portType,用户可以搜索实现了一个特殊的portType的服务而不必知道服务实现的
特定的binding。
wsdl:port信息如下所示捕获:
bindingTemplate tModelInstanceDetails元素必须包含至少以下tModelInstanceInfo元素:
1,一个具有一个对该port实现的wsdl:binding建模的tModel的tModelKey的tModelInstanceInfo。该tModelInstanceInfo的instanceParms必须包含wsdl:port
本地名。
2,一个具有一个对该wsdl:portType建模的tModel的tModelKey的tModelInstanceInfo。
2.4.4.1 映射总结
WSDL UDDI
port bindingTemplate
名字空间 包含的businessService的keyedReference中捕获
port的本地名 该binding的tModel相关的tModelInstanceInfo的instanceParms
port实现的binding 具有符合该binding的tModel的tModelKey的tModelInstanceInfo
port实现的portType 具有符合该portType的tModel的tModelKey的tModelInstanceInfo
2.4.5 wsdl:port Address Extensions -> uddi:bindingTemplate
uddi:bindingTemplate必须包含Web服务的地址信息。该信息来自wsdl:port地址扩展性元素。
2.4.5.1 soap:address -> uddi:accessPoint
一个soap:address必须在建模包含soap:address的wsdl:port的uddi:bindingTemplate中建模为uddi:accessPoint。
soap:address信息如下所示被捕获:
1,accessPoint值必须为soap:address元素的location属性的值
2,accessPoint的URLType属性必须与soap:binding指定的transport一致,或者如果没有一致存在则为"other"。例如在HTTP transport情况下,URLType
属性必须为"http"。
如果"other"被使用则一个引用合适的vendor定义的transport tModel的tModelInstanceInfo元素必须添加到bindingTemplate。
2.4.5.2 http:address -> uddi:accessPoint
一个http:address在建模包含http:address的wsdl:port的uddi:bindingTemplate中必须建模为一个uddi:accessPoint。
http:address信息如下所示捕获:
1,accessPoint值必须为http:address元素的location属性的值
2,accessPoint的URLType属性必须为"http"或者"https"
2.4.5.3 其他wsdl:port Address扩展
任何其他address扩展性元素在建模包含address扩展性元素的wsdl:port的uddi:bindingTemplate中必须建模为uddi:accessPoint。
address信息如下所示捕获:
1,accessPoint值必须为address扩展性元素的location属性的值。如果location属性的值不能映射到accessPoint值则WSDL实现文档方式必须被使用。
参考附录A来得到更多信息。
2,accesPoint的URLType属性必须与该URL相关的transport协议一致,或者如果没有合适的定义的属性值则为"other"。
2.5 在UDDI V3中映射WSDL 1.1的区别
本节描述在UDDI V3视图中的模型的差别,模型是UDDI V3规范中重要的条目。
2.5.1 主要差别
主要差别为:
1,实体将拥有V3 keys而不是V2 keys。
2,一个accessPoint有一个useType属性而不是一个URLType属性。
2.5.2 在UDDI V3规范中与wsdlDeployment的比较
UDDI V3规范包含对wsdlDeployment的支持,wsdlDeployment表现为一个accessPoint的useType属性的值和一个bindingTemplate的分类。wsdlDeployment的使用
与本技术笔记不兼容,因为它假设没有WSDL建模会执行,对WSDL不知道任何事情,更不用说它的URL。
3 一个完整的例子
考虑下面的基于在WSDL1.1规范中表示的WSDL文档的WSDL例子。这个例子显示了这个WSDL文档怎样分解到两个tModels(一个为portType另一个为binding)以及一个
具有一个bindingTemplate的businessService。然后它显示可以用来作发现目的的UDDI API查询。
3.1 WSDL例子
<?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>
注意该WSDL文档有一个portType,一个binding,一个service和一个port。像这样,这个例子展示了最简单的WSDL文档。同时也注意一下该WSDL的位置位于
http://location/sample.wsdl。
3.2 UDDI V2模型
3.2.1 UDDI portType tModel
WSDL portType 实体映射到一个tModel。tModel名字和WSDL portType本地名一样。tModel包含一个指定WSDL名字空间的categoryBag,并且它指示了tModel为
"portType"类型。overviewDoc提供了一个对WSDL文档的指针。
<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>
3.2.2 UDDI binding tModel
WSDL binding实体映射到一个tModel。tModel名字与WSDL binding的本地名一样。tModel包含一个指定WSDL名字空间的categoryBag,它指示了tModel为"binding"
类型,它提供一个对portType tModel的指针,并且它指示了该binding支持什么协议。wsdlSpec keyedReference确保了用户可以找到使用在版本1最佳实践里定
义的惯例的tModel。overviewDoc提供了一个对WSDL文档的指针。
<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>
3.2.3 UDDI businessService和bindingTemplate
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。
3.3 例子V2查询
本节显示对给定的例子的模型怎样执行多种UDDI V2查询。
3.3.1 基于portType名寻找tModel
在名字空间http://example.com/stockquote/寻找StockQuotePortType的portType tModel。
<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>
这应该返回tModelKey uddi:e8cf1163-8234-4b35-865f-94a7322e40c3。
3.3.2 基于portType寻找bindings
寻找StockQuotePortType的所有bindings。
<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>
这应该返回tModelKey uddi:49662926-f4a5-4ba5-b8d0-32ab388dadda。
3.3.3 寻找portType的实现
寻找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的列表。
<find_service generic="2.0" xmlns="urn:uddi-org:api_v2"> <tModelBag> <tModelKey>uuid:e8cf1163-8234-4b35-865f-94a7322e40c3</tModelKey> </tModelBag> </find_binding>
这应该返回serviceKey 102b114a-52e0-4af4-a292-02700da543d4。
现在第二个调用用来寻找该特殊service的合适的bindings。
<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>
这应该返回bindingKey f793c521-0daf-434c-8700-0e32da232e74。
3.3.4 寻找binding的实现
寻找StockQuoteSoapBind的所有实现。
这与前面的例子非常类似,除了tModelBag包含binding tModel的key而不是portType tModel。
3.3.5 寻找portType的SOAP实现
寻找StockQuotePortType的支持SOAP的所有实现。
至少需要三个查询。第一个查询返回所有的引用portType tModel并且归类为SOAP的binding tModels。
<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>
下一步发生什么取决于在整个查询中是否需要其他criteria。
3.3.5.1 没有其他Criteria
这种情况下至少需要两个查询,在上面的寻找一个单独的binding的实现的例子中描述了。第一个查询为一个find_service调用,它必须包含"orAllKeys"
findQualifier并且必须提供一个包含第一个查询返回的所有的binding tModel keys的tModelBag。这将返回有一个引用至少binding tModels中的一个的
bindingTemplate的services列表。
最后,对每个这样的service,必须或者调用get_serviceDetail或者find_binding。
3.3.5.2 其他Criteria
这种情况也至少需要两个查询,这取决于找到的binding tModels和services的数量。对每个binding tModel需要一个find_service查询并且默认的"andAllKeys"
必须被使用,因为其他的criteria也将应用到该查询。这将返回有一个引用特殊的binding tModel并也满足其他criteria的bindingTemplate的services列表。
3.3.6 寻找portType的SOAP/HTTP实现
这与前面的情况类似,除了第一个查询除了包含SOAP协议之外必须也包含一个HTTP transport的category。
3.3.7 寻找binding的portType
一个binding的portType包含在binding tModel的categoryBag中。一旦获得binding的tModel则不需要查询。
具有tModelKey="uuid:082b0851-25d8-303c-b332-f24a6d53e38e"的keyedReference的keyValue包含portType tModelKey。
3.3.8 基于WSDL服务寻找businessService
在名字空间http://example.com/stockquote/寻找StockQuoteService的businessService。
<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>
这应该返回serviceKey 102b114a-52e0-4af4-a292-02700da543d4。
3.4 例子V3查询
本节包含一些来自前面的章节的查询例子的重写来使用UDDI V3 API的新特性。其他查询没有很大不同。显示的实体keys假设V2模型通过一个root registry迁移
到V3。
3.4.1 需找portType的实现
在UDDI V3 API中一个serviceKey对find_binding是可选的,可以用一个单独的查询实现它。
<find_binding xmlns="urn:uddi-org:api_v3"> <tModelBag> <tModelKey>uddi:e8cf1163-8234-4b35-865f-94a7322e40c3</tModelKey> </tModelBag> </find_binding>
这将返回bindingKey uddi:f793c521-0daf-434c-8700-0e32da232e74。
3.4.2 寻找portType的SOAP实现
3.4.2.1 没有其他Criteria
由于在UDDI V3 API里serviceKey对find_binding是可选的并且可以嵌入一个find_tModel调用,可以用一个单独的查询实现它:
<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>
这将返回bindingKey uddi:f793c521-0daf-434c-8700-0e32da232e74。
4 参考
4.1 规范
[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/
A 外部WSDL实现文档
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.
A.1 捕获URL
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.
A.2 从WSDL获得Port Address
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.
A.3 查询使用WSDL实现文档的服务
It is possible to query the services that have a WSDL Implementation Document by querying specifying the tModelKey of the WSDL Address tModel.
B 规范tModels
This Technical Note introduces a number of canonical tModels that are used to represent WSDL metadata and relationships. These tModels are defined here.
B.1 WSDL实体型tModel
B.1.1 设计目标
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.1.2 定义
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
<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>
B.1.3 合法值
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.1.4 使用例子
A V2 tModel representing a portType would have a categoryBag representing its type:
<categoryBag> <keyedReference tModelKey="uuid:6e090afa-33e5-36eb-81b7-1ca18373f457" keyName="WSDL Entity type" keyValue="portType"/> … </categoryBag>
B.2 XML名字空间tModel
B.2.1 设计目标
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.2.2 定义
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
<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>
B.2.3 合法值
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.2.4 使用例子
A namespace keyedReference would be as follows:
<categoryBag> <keyedReference tModelKey="uuid:d01987d1-ab2e-3013-9be2-2a66eb99d824" keyName="namespace" keyValue="urn:foo"/> … </categoryBag>
B.3 XML本地名字tModel
B.3.1 设计目标
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.3.2 定义
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
<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>
B.3.3 合法值
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.3.4 使用例子
A local name keyedReference would be as follows:
<categoryBag> <keyedReference tModelKey="uuid:2ec65201-9109-3919-9bec-c9dbefcaccf6" keyName="Local service name" keyValue="StockQuoteService"/> … </categoryBag>
B.4 WSDL portType引用tModel
B.4.1 设计目标
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.4.2 定义
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
<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>
B.4.3 合法值
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.4.4 使用例子
One would add the following keyedReference to signify that a wsdl:binding implements a specific portType:
<categoryBag> <keyedReference tModelKey="uuid:082b0851-25d8-303c-b332-f24a6d53e38e" keyName="wsdl:portType Reference" keyValue="uuid:e8cf1163-8234-4b35-865f-94a7322e40c3"/> … </categoryBag>
Note that the keyValue is a tModelKey, which, if queried for using get_tModelDetail, would return the tModel that represents the portType.
B.5 SOAP协议tModel
B.5.1 设计目标
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.5.2 定义
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
<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>
B.5.3 使用例子
The SOAP Protocol tModel is used to categorise a binding tModel that corresponds to a wsdl:binding that supports the SOAP 1.1 protocol.
<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>
B.6 HTTP协议tModel
B.6.1 设计目标
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.6.2 定义
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
<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>
B.6.3 使用例子
The H
发表评论
-
Ubuntu 11.10 安装Java、JIRA/Confluence/FishEye、Nginx
2012-03-01 22:26 46221. 替换Ubuntu源 编辑/etc/apt/source. ... -
Android开发WeatherForecast程序
2009-03-28 13:38 62841,使用Googel API http://www.googl ... -
Android程序开发入门
2009-03-26 14:26 30251, 安装软件 1) JDK 2) Eclipse 3) AD ... -
Spring与ThreadLocal的讨论
2007-07-31 12:27 3910Singleton是不能使用非Singleton的实例的 比如 ... -
Spring基础培训ppt
2007-07-30 19:34 6237做ppt还真是累 更新了一下ppt. -
使用Jetty和DWR创建伸缩性Comet程序
2007-07-28 21:11 7510Ajax for Java developers: Write ... -
Java代码规范
2007-07-19 01:12 3444http://java.sun.com/docs/codeco ... -
Spring JavaConfig参考文档
2007-07-14 18:37 12829Spring JavaConfig参考文档 Spring Ja ... -
Tiger in the house
2007-07-14 02:49 8278很高兴花周五晚上2个小时的时间来阅读这样一本实用的书 -- 《 ... -
深入了解Java ClassLoader、Bytecode 、ASM、cglib
2007-07-05 16:50 19439一、Java ClassLoader 1,什么是ClassL ... -
Java里判断Image文件信息格式(GIF/PNG/JPG)/Size/Height/Width?
2007-06-05 18:01 92751,判断Image格式 用UE打开GIF/PNG/JPG格式的 ... -
推荐轻量级面向服务Web开发库Objot
2007-05-27 22:17 3204Objot是我们公司Aragon Consulting Gro ... -
实战Mule:利用Mule调用XFire发布的文件上传服务
2007-03-27 15:17 5939配置Mule和XFire环境 参考前面的文章实战Mule:利用 ... -
实战Mule:利用Mule调用XFire发布的Web服务
2007-03-26 17:26 9396下载和安装XFire和Mule 参考http://hideto ... -
开源ESB引擎Mule初印象
2007-03-22 18:13 10663Mule is the leading open source ... -
XFire快速上手
2007-03-14 11:53 6707下载XFrie 首先,去http://xfire.codeha ... -
学习Eclipse RCP之Hello World
2007-03-12 17:57 4250创建插件项目 打开Eclipse并选择File->New ... -
Google Web Toolkit上手指南
2007-03-12 16:07 4781目录 安装Google Web Toolkit 构建一个简单的 ... -
5分钟学习Maven2
2007-03-12 01:12 5947安装 Maven是一个Java工具,所以你必须安装Java环境 ... -
Axis2快速上手指南
2007-03-01 23:22 74350原文链接:http://ws.apache.org/axis2 ...
相关推荐
在UDDI注册中心中理解和使用WSDL是构建互操作性Web服务的关键。通过将WSDL文档划分为服务接口和服务实现两部分,不仅可以清晰地区分服务的抽象定义和具体实现,还能提高服务的可管理性和可发现性。此外,UDDI与WSDL...
- **服务发布**:服务提供商可以在UDDI注册中心注册他们的服务,包括服务接口的定义、地址、联系信息等,以便其他服务消费者能够找到并使用这些服务。 - **服务发现**:服务消费者可以通过查询UDDI注册中心来查找...
这通常涉及到将WSDL文档发布到UDDI注册中心,从而使得这些服务可以被客户端发现并使用。UDDI注册中心的使用允许开发者不仅能够查找到具有特定功能的Web服务,还可以获取服务的具体技术实现信息,从而实现服务的动态...
本文档是在“在UDDI注册中心使用WSDL(第二版)”的基础上进一步拓展,确保了BPEL4WS与WSDL之间的兼容性和一致性。 ##### 1.3 术语 - **BPEL4WS**: 一种用于描述Web服务交互的业务流程执行语言。 - **UDDI**: 一种...
- **理解UDDI注册中心的WSDL**:介绍如何理解和使用UDDI注册中心中的WSDL文件。 - **developerWorks Toolbox订阅**:IBM developerWorks网站提供的工具和服务订阅。 - **Web服务专区**:提供更多关于Web服务的教学...
**在“理解UDDI注册中心的WSDL”文档中**,可能详细介绍了如何使用UDDI来注册和查找具有WSDL定义的服务。文档可能涵盖了以下内容: 1. **UDDI注册过程**:如何创建UDDI注册项,包括企业、服务和绑定的定义。 2. **...
一个利用uddi4j和juddirc0.9做一个注册web服务(wsdl文件)到uddi服务器上。 注册服务:wsld接口和wsdl实现,分别使用PublishServiceImplementation和PublishServiceInterface两个程序来实现
### SOA UDDI 注册中心相关知识点 #### 1. Web 服务与 UDDI 概念 - **Web 服务**:一种基于互联网的应用程序接口(API),它使用标准的互联网协议(如HTTP)来交换数据和服务。Web 服务通常使用XML作为数据格式,并...
看了下教程,实现UDDI注册中心有2种方法,一个是IBM的公共UDDI注册中心,一个是搭建Apache的私有UDDI注册中心,我选择搭建Apache的JUDDI,在其中遇到不少问题,主要是必须要用jdk1.5版本和tomcat5.5,花了不少时间来配...
另外,贴出自己写的解析wsdl文件 注册到uddi 中心 以及查找 源代码。生成数据库的脚本放在文件目录下,这里的数据库测试环境为sqlserver2005,由于数据库中,原来的描述字段为255varchar型,由于实际的wsdl文件的描述...
在本系列文章中,我们将研究创建、部署和发布 Web 服务的所有主要技术方面,从 Web 服务描述语言(WSDL),到简单对象访问协议(SOAP),以及通用描述、发现和集成(UDDI)注册中心。 在 Web 服务中,WSDL扮演着...
3. **CreateNewBusiness.java**:在这个文件中,开发者可以学习如何在uddi注册中心注册一个新业务。uddi中的业务代表了一个组织,它可能提供了多个服务。 4. **CreateNewInterface.java**:接口在uddi中代表了服务...
当一个Web服务开发完成并准备供其他系统使用时,它需要在UDDI注册中心进行注册。在这个过程中,服务提供者会提供关于服务的元数据,如服务的名称、接口定义(通常是一个WSDL文件,即Web Services Description ...
UDDI,全称为通用描述、发现和集成,是一种基于Web的服务发现和注册标准,它为服务提供商和服务消费者提供了一个中心化的目录,使得企业能够发布、查找和管理网络服务。UDDI V3是该标准的第三版,于2004年发布,引入...
【UDDI(统一描述、发现和集成)】:UDDI是一个标准,提供了服务注册和查找机制,使得服务消费者能发现和理解可用的服务。 【WSDL(Web Services Description Language)】:WSDL是一种XML格式,用于定义Web服务的...
WSDL文件可以被注册到UDDI注册中心,以便其他应用程序发现并使用服务。 8. **服务编排**:WSDL也可以用于描述服务编排,即将多个服务组合成一个复杂的业务流程。这种情况下,WSDL文件会包含对其他服务的引用。 9. ...
UDDI注册中心允许企业注册它们所提供的服务,其他企业或个人可以通过UDDI来查找所需的Web服务。这种机制大大降低了寻找合作伙伴和服务的成本,同时也提高了业务流程的灵活性。 ## 实践案例 文章的部分内容提到了...
UDDI4J是Java平台上的一个开源库,它允许开发者使用Java API来操作UDDI注册中心,进行服务的发布、查找和绑定操作。本篇文章将深入探讨UDDI4J的使用,结合WSDL4J和JUDDI,以代码示例解析整个流程。 **1. WSDL4J:...
2. **业务实体**:这是在UDDI注册中心中登记的基本单位,代表实际提供服务的企业或组织。业务实体包含了服务的详细信息,如名称、地址、联系信息等。 3. **绑定模板**:绑定模板定义了如何访问服务,包括协议、端口...