“Web Services:WSDL”的版本间差异
(→语法) |
(→UDDI) |
||
第185行: | 第185行: | ||
== UDDI == | == UDDI == | ||
UDDI:“Universal Description, Discovery and Integration”,通用描述、发现与集成服务: 是一种'''目录服务''',企业可以使用它'''对 Web services 进行注册和搜索'''。 | |||
它是一个'''基于 XML 的跨平台的描述规范''',可以使世界范围内的企业在互联网上发布自己所提供的服务。 | |||
=== 什么是 UDDI? === | |||
UDDI 是一个独立于平台的框架,用于通过使用 Internet 来描述服务,发现企业,并对企业服务进行集成。 | |||
* UDDI 指的是通用描述、发现与集成服务 | |||
* UDDI 是一种用于存储有关 web services 的信息的目录。 | |||
* UDDI 是一种由 WSDL 描述的 web services 界面的目录。 | |||
* UDDI 经由 SOAP 进行通信 | |||
* UDDI 被构建入了微软的 .NET 平台 | |||
=== UDDI 基于什么? === | |||
UDDI 使用 W3C 和 IETF(Internet Engineering Task Force) 的因特网标准,比如 XML、HTTP 和 DNS 协议。 | |||
# 使用 '''WSDL''' 来描述到达 web services 的界面; | |||
# 通过 '''SOAP''' 实现跨平台的编程特性。 | |||
=== UDDI 的好处 === | |||
UDDI 规范帮助我们解决的问题: | |||
* 使得在成百万当前在线的企业中发现正确的企业成为可能 | |||
* 定义一旦首选的企业被发现后如何启动商业 | |||
* 扩展新客户并增加对目前客户的访问 | |||
* 扩展销售并延伸市场范围 | |||
* 满足用户驱动的需要,为在全球 Internet 经济中快速合作的促进来清除障碍 | |||
=== UDDI 如何被使用 === | |||
<pre> | |||
假如行业发布了一个用于航班比率检测和预订的 UDDI 标准,航空公司就可以把它们的服务注册到一个 UDDI 目录中。 | |||
然后旅行社就能够搜索这个 UDDI 目录以找到航空公司预订界面。 | |||
当此界面被找到后,旅行社就能够立即与此服务进行通信,这样由于它使用了一套定义良好的预订界面。 | |||
</pre> | |||
== 语法 == | == 语法 == |
2021年6月1日 (二) 03:45的最新版本
关于
WSDL(网络服务描述语言,Web Services Description Language)是一门基于 XML 的语言,用于描述 Web Services 以及如何对它们进行访问。
文档
WSDL 文档仅仅是一个简单的 XML 文档,它包含一系列描述某个 web service 的定义。
文档结构
WSDL 文档是利用这些主要的元素来描述某个 web service 的:
元素 | 定义 |
---|---|
<portType> | web service 执行的操作 |
<message> | web service 使用的消息 |
<types> | web service 使用的数据类型 |
<binding> | web service 使用的通信协议 |
- WSDL 文档可包含其它的元素,比如 extension 元素,以及一个 service 元素,此元素可把若干个 web services 的定义组合在一个单一的 WSDL 文档中。
一个 WSDL 文档的主要结构是类似这样的:
<definitions>
<types>
data type definitions........
</types>
<message>
definition of the data being communicated....
</message>
<portType>
set of operations......
</portType>
<binding>
protocol and data format specification....
</binding>
</definitions>
其中:
- <portType>:元素描述一个 web service、可被执行的操作,以及相关的消息。
- 可以把 <portType> 元素比作传统编程语言中的一个函数库(或一个模块、或一个类);
- 最重要的 WSDL 元素;
- <message>:元素定义一个操作的数据元素。
- 每个消息均由一个或多个部件组成。
- 可以把这些部件比作传统编程语言中一个函数调用的参数。
- <types>:元素定义 web service 使用的数据类型。
- 为了最大程度的平台中立性,WSDL 使用 XML Schema 语法来定义数据类型。
- <binding>:元素为每个端口定义消息格式和协议细节。
示例
这是某个 WSDL 文档的简化的片段:
<message name="getTermRequest">
<part name="term" type="xs:string"/>
</message>
<message name="getTermResponse">
<part name="value" type="xs:string"/>
</message>
<portType name="glossaryTerms">
<operation name="getTerm">
<input message="getTermRequest"/>
<output message="getTermResponse"/>
</operation>
</portType>
如上:
- <portType> 元素把 "glossaryTerms" 定义为某个端口的名称,把 "getTerm" 定义为某个操作的名称。
- 操作 "getTerm" 拥有一个名为 "getTermRequest" 的输入消息,以及一个名为 "getTermResponse" 的输出消息。
- <message> 元素可定义每个消息的部件,以及相关联的数据类型。
- 对比传统的编程,glossaryTerms 是一个函数库,而 "getTerm" 是带有输入参数 "getTermRequest" 和返回参数 getTermResponse 的一个函数。
端口:<portType>
<portType> 元素是最重要的 WSDL 元素:它可描述一个 web service、可被执行的操作,以及相关的消息。
- 可以把 <portType> 元素比作传统编程语言中的一个函数库(或一个模块、或一个类)。
操作类型
请求-响应(Request-response)是最普通的操作类型,不过 WSDL 定义了四种类型:
类型 | 定义 |
---|---|
One-way | 此操作可接受消息,但不会返回响应。 |
Request-response | 此操作可接受一个请求并会返回一个响应 |
Solicit-response | 此操作可发送一个请求,并会等待一个响应。 |
Notification | 此操作可发送一条消息,但不会等待响应。 |
One-Way 操作
一个 one-way 操作的例子:
<message name="newTermValues">
<part name="term" type="xs:string"/>
<part name="value" type="xs:string"/>
</message>
<portType name="glossaryTerms">
<operation name="setTerm">
<input name="newTerm" message="newTermValues"/>
</operation>
</portType >
如上:端口 "glossaryTerms" 定义了一个名为 "setTerm" 的 one-way 操作:
- 这个 "setTerm" 操作可接受新术语表项目消息的输入,这些消息使用一条名为 "newTermValues" 的消息,此消息带有输入参数 "term" 和 "value"。不过,没有为这个操作定义任何输出。
Request-Response 操作
一个 request-response 操作的例子:
<message name="getTermRequest">
<part name="term" type="xs:string"/>
</message>
<message name="getTermResponse">
<part name="value" type="xs:string"/>
</message>
<portType name="glossaryTerms">
<operation name="getTerm">
<input message="getTermRequest"/>
<output message="getTermResponse"/>
</operation>
</portType>
如上:端口 "glossaryTerms" 定义了一个名为 "getTerm" 的 request-response 操作:
- "getTerm" 操作会请求一个名为 "getTermRequest" 的输入消息,此消息带有一个名为 "term" 的参数,
- 并将返回一个名为 "getTermResponse" 的输出消息,此消息带有一个名为 "value" 的参数。
绑定:<binding>
WSDL 绑定可为 web service 定义消息格式和协议细节。
binding 元素有两个属性:
- name 属性:定义 binding 的名称;
- type 属性:指向用于 binding 的端口;
soap:binding 元素有两个属性:
- style 属性:可取值 "rpc" 或 "document";
- transport 属性:定义了要使用的 SOAP 协议。
soap:operation 元素定义了每个端口提供的操作符。
- 对于每个操作,相应的 SOAP 行为都需要被定义。
示例:
<message name="getTermRequest">
<part name="term" type="xs:string"/>
</message>
<message name="getTermResponse">
<part name="value" type="xs:string"/>
</message>
<portType name="glossaryTerms">
<operation name="getTerm">
<input message="getTermRequest"/>
<output message="getTermResponse"/>
</operation>
</portType>
<binding type="glossaryTerms" name="b1">
<soap:binding style="document"
transport="http://schemas.xmlsoap.org/soap/http" />
<operation>
<soap:operation soapAction="http://example.com/getTerm"/>
<input><soap:body use="literal"/></input>
<output><soap:body use="literal"/></output>
</operation>
</binding>
UDDI
UDDI:“Universal Description, Discovery and Integration”,通用描述、发现与集成服务: 是一种目录服务,企业可以使用它对 Web services 进行注册和搜索。
它是一个基于 XML 的跨平台的描述规范,可以使世界范围内的企业在互联网上发布自己所提供的服务。
什么是 UDDI?
UDDI 是一个独立于平台的框架,用于通过使用 Internet 来描述服务,发现企业,并对企业服务进行集成。
- UDDI 指的是通用描述、发现与集成服务
- UDDI 是一种用于存储有关 web services 的信息的目录。
- UDDI 是一种由 WSDL 描述的 web services 界面的目录。
- UDDI 经由 SOAP 进行通信
- UDDI 被构建入了微软的 .NET 平台
UDDI 基于什么?
UDDI 使用 W3C 和 IETF(Internet Engineering Task Force) 的因特网标准,比如 XML、HTTP 和 DNS 协议。
- 使用 WSDL 来描述到达 web services 的界面;
- 通过 SOAP 实现跨平台的编程特性。
UDDI 的好处
UDDI 规范帮助我们解决的问题:
- 使得在成百万当前在线的企业中发现正确的企业成为可能
- 定义一旦首选的企业被发现后如何启动商业
- 扩展新客户并增加对目前客户的访问
- 扩展销售并延伸市场范围
- 满足用户驱动的需要,为在全球 Internet 经济中快速合作的促进来清除障碍
UDDI 如何被使用
假如行业发布了一个用于航班比率检测和预订的 UDDI 标准,航空公司就可以把它们的服务注册到一个 UDDI 目录中。 然后旅行社就能够搜索这个 UDDI 目录以找到航空公司预订界面。 当此界面被找到后,旅行社就能够立即与此服务进行通信,这样由于它使用了一套定义良好的预订界面。
语法
描述于 W3C 工作草案的完整 WSDL 1.2 语法:
<wsdl:definitions name="nmtoken"? targetNamespace="uri">
<import namespace="uri" location="uri"/> *
<wsdl:documentation .... /> ?
<wsdl:types> ?
<wsdl:documentation .... /> ?
<xsd:schema .... /> *
</wsdl:types>
<wsdl:message name="ncname"> *
<wsdl:documentation .... /> ?
<part name="ncname" element="qname"? type="qname"?/> *
</wsdl:message>
<wsdl:portType name="ncname"> *
<wsdl:documentation .... /> ?
<wsdl:operation name="ncname"> *
<wsdl:documentation .... /> ?
<wsdl:input message="qname"> ?
<wsdl:documentation .... /> ?
</wsdl:input>
<wsdl:output message="qname"> ?
<wsdl:documentation .... /> ?
</wsdl:output>
<wsdl:fault name="ncname" message="qname"> *
<wsdl:documentation .... /> ?
</wsdl:fault>
</wsdl:operation>
</wsdl:portType>
<wsdl:serviceType name="ncname"> *
<wsdl:portType name="qname"/> +
</wsdl:serviceType>
<wsdl:binding name="ncname" type="qname"> *
<wsdl:documentation .... /> ?
<-- binding details --> *
<wsdl:operation name="ncname"> *
<wsdl:documentation .... /> ?
<-- binding details --> *
<wsdl:input> ?
<wsdl:documentation .... /> ?
<-- binding details -->
</wsdl:input>
<wsdl:output> ?
<wsdl:documentation .... /> ?
<-- binding details --> *
</wsdl:output>
<wsdl:fault name="ncname"> *
<wsdl:documentation .... /> ?
<-- binding details --> *
</wsdl:fault>
</wsdl:operation>
</wsdl:binding>
<wsdl:service name="ncname" serviceType="qname"> *
<wsdl:documentation .... /> ?
<wsdl:port name="ncname" binding="qname"> *
<wsdl:documentation .... /> ?
<-- address details -->
</wsdl:port>
</wsdl:service>
</wsdl:definitions>