Web 服务描述语言 （WSDL）

《Web 服务描述语言 （WSDL）》由会员分享，可在线阅读，更多相关《Web 服务描述语言 （WSDL）（45页珍藏版）》请在装配图网上搜索。

1、Web 服务描述语言 (WSDL) 1.0 2000年9月25日 作者（按姓氏字母顺序排列）： Erik Christensen，Microsoft Francisco Curbera，IBM Greg Meredith，Microsoft Sanjiva Weerawarana，IBM 版权所有© 2000 Ariba，International Business Machines Corporation，Microsoft 摘要 WSDL 是一种 XML 格式，用于将网络服务描述为一组端点，这些端点对包含面向文档信息或面向过程信息的消息进行操作。这种格式首先

2、对操作和消息进行抽象描述，然后将其绑定到具体的网络协议和消息格式上以定义端点。相关的具体端点即组合成为抽象端点（服务）。可以对 WSDL 进行扩展，这样无论通信时使用何种消息格式或网络协议，都可以对端点及其消息进行描述。但是，本文档中所述的绑定只涉及有关如何将 WSDL 与 SOAP 1.1、HTTP GET/POST 和 MIME 一起使用的问题。 此版本的 WSDL 语言尚处于初步阶段，没有提供框架来说明端点的撰写过程。描述这些约定的完整框架应包含撰写服务的方式和表达服务行为的方式（即相应的用于发送和接收消息的规则）。服务的撰写应满足两个要求：(1) 确保类型的安全性，(2) 允许在运行

3、时通过交换和绑定服务引用来传递引用。后面的这一条对于在运行期协商约定以及捕获引用服务和代理服务的行为至关重要。 WSDL 规范的作者希望及时发布 WSDL 的修订版和/或一些附加文档，包括：(1) 撰写服务的框架；(2) 描述服务行为的框架。 状态 本草案介绍了 Ariba、IBM 和 Microsoft 当前在服务描述方面的一些思路。它对 NASSL、SCL 和 SDL（有关这方面的早期建议）中的一些概念进行了整理合并。 目录 1. 简介 2. 服务定义 o 文档结构 o 类型 o 消息 o 端口类型 o 绑定 o 端口 o 服务 3. SO

4、AP 绑定 o SOAP 示例 o SOAP 绑定如何扩展 WSDL o soap:binding o soap:operation o soap:body o soap:fault o soap:header o soap:address 4. HTTP GET 和 POST 绑定 o HTTP GET/POST 示例 o HTTP GET/POST 绑定如何扩展 WSDL o http:address o http:binding o http:operation o http:urlEncoded o http:urlRep

5、lacement 5. MIME 绑定 o MIME 绑定示例 o MIME 绑定如何扩展 WSDL o mime:content o mime:multipartRelated o soap:body o mime:mimeXml 6. 参考资料 o 有关 URI 的说明 o WSDL 示例的线上格式 o 扩展性元素的位置 o 架构 简介 由于通信协议和消息格式在 Web 社区中已经过标准化，因而有可能以某种结构化的方式对通信加以描述，而且实现这一点也显得日益重要。WSDL 定义了一种 XML 语法，将网络服务描述为能够进行消息

6、交换的通信端点的集合，从而满足了这种需求。WSDL 服务定义为分布式系统提供了文档，并且可用于自动执行应用程序通信中所涉及的细节。 WSDL 文档将服务定义为网络端点或端口的集合。在 WSDL 中，由于端点和消息的抽象定义已从具体的网络部署或数据格式绑定中分离出来，因此可以对抽象定义进行再次使用：消息，指对交换数据的抽象描述；而端口类型，指操作的抽象集合。用于特定端口类型的具体协议和数据格式规范构成了可以再次使用的绑定。将网络地址与可再次使用的绑定相关联，可以定义一个端口，而端口的集合则定义为服务。因此，WSDL 文档在网络服务的定义中使用下列元素： · Types - 数据类型定义的容器

7、，它使用某种类型系统（如 XSD）。 · Message - 通信数据的抽象类型化定义。 · Operation - 对服务所支持的操作的抽象描述。 · Port Type - 操作的抽象集合，这些操作由一个或多个端点支持。 · Binding - 特定端口类型的具体协议和数据格式规范。 · Port - 定义为绑定和网络地址组合的单个端点。 · Service - 相关端点的集合。 将在第二节中对这些元素进行详细说明。应该注意的是，WSDL 并没有引入新的类型定义语言。虽然 WSDL 知道，要描述消息格式需要丰富的类型系统，并且它也支持“XML 架构规范 (XSD

8、)”作为其标准类型系统，但是，由于不可能只用一种类型系统语法来描述现在和将来的所有消息格式，因此 WSDL 允许通过扩展来使用其它类型定义语言。 此外，WSDL 还定义了通用的绑定机制。通过该机制可使特定的协议、数据格式或结构与抽象的消息、操作或端点相关联。该机制还允许对抽象定义进行再次使用。 虽然本文档定义了上述语言扩展，但这些扩展均位于核心服务定义框架的上部。所以一定能将 WSDL 与其它绑定扩展一起使用。 WSDL 文档示例 下例是一个提供股票报价的简单服务的 WSDL 定义。该服务支持名为 GetLastTradePrice 的单一操作，这个操作是通过在 HTTP 上运行 S

9、OAP 1.1 协议来实现的。该请求接受一个类型为字符串的 ticker 符号，并返回类型为浮点数的价格。有关此定义中所用元素的详细说明，请参见第 2 节（核心语言）和第 3 节（SOAP 绑定）。 示例 1 通过 HTTP 运行的 SOAP 1.1 请求/响应

10、mas.xmlsoap.org/wsdl/soap/" xmlns="http://schemas.xmlsoap.org/wsdl/">

11、

12、

13、"xsd1:TradePriceResult"/>

14、inding name="StockQuoteSoapBinding" type="tns:StockQuotePortType">

15、eral" namespace=" encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"/>

<

16、/output> 我的第一次服务 * ? ? ? * <-- extensibility element --> *

22、 * * ? *

23、> ? ? ? ? ?

24、ge="qname"> * ? * ? <-- extensibility element --> * *

25、 ? <-- extensibility element --> * ? ? <-- extensibility element --> ?

26、l:documentation…/> ? <-- extensibility element --> * * ? <-- extensibility element --> *

27、 * ? * ? <-- extensibility element --> <-- extensibility element --> <--

28、 extensibility element --> * 服务是使用以下五个主要元素来定义的： · types：提供用于描述所交换消息的数据类型定义。 · message：代表所传输数据的抽象定义。消息由一些逻辑片段构成，每个逻辑片段分别与某个类型系统中的定义相关联。 · portType：指抽象操作的集合。每个操作引用一条输入消息和一条输出消息。 · binding：为由特定 portType 定义的操作和消息指定具体的协议和数据格式规范。 · port：为绑定指定一个地址，从而定义一个通信端点。 · service：用

29、于聚合一组相关端口。 将在第 2.2 至 2.7 节中对这些元素进行详细说明。本节的其余部分将介绍 WSDL 中有关文档命名、引用文档定义、使用语言扩展和添加上下文文档等方面的规则。 文档命名和链接 可以为 WSDL 文档分配一个类型为 NCNAME 的可选 name 属性（该属性将作为文档的一种轻量级形式）。或者，也可以指定一个类型为 URI 的 targetNamespace 属性。该 URI 不能是相对 URI。 WSDL 允许使用 import 语句将名称空间与文档位置相关联：

30、ocation="uri"/> * WSDL 中的 QNames 解析方法与 XML 架构规范中所述的 QNames 解析方法相似。 使用 QName 可以创建对 WSDL 定义的引用。可以引用 WSDL 文档中的以下各类定义： · WSDL 定义：service、port、message、bindings 和 portType · 其它定义：如果通过扩展添加了其它定义，这些定义应使用 QName 链接。 上面列出的每种 WSDL 定义类型都有自己的名称范围（也就是说，端口名称和消息名称绝对不会发生冲突）。同一个名称范围内的名称在 WSDL 文档中

31、必须是唯一的。 撰写样式 使用 import 元素可以将服务定义的不同元素分别放入单独的文档中，需要时再将其导入。这种技术可以根据定义的抽象级别将其分开，这样有助于编写更为清晰的服务定义。使 用这种技术还可以对各种服务定义进行最大限度的再利用。因此，具有这种结构的 WSDL 文档更易于使用和维护。在示例 2 中，我们将定义分为数据类型定义、抽象定义和特定服务绑定三类，并将其分别放入三个文档中。当然，这种机制的使用并不仅限于此例中明确出现的定义（这些定 义只使用了本规范中所定义的语言元素），也可以使用类似的方式对基于其它语言扩展的其它定义类型进行编码和再利用。 示例 2. 示例 1 中

32、所述服务的另一种撰写样式。

33、

34、tNamespace=" xmlns:tns=" xmlns:xsd1=" xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/" xmlns="http://schemas.xmlsoap.org/wsdl/">

35、element="xsd1:GetLastTradePrice"/>

36、"tns:GetLastTradePriceRequest"/>

38、 > 我的第一个服务

39、on="http://my.org/stockquote"/> 语言的扩展性和绑定 在 WSDL 中，术语“绑定”表示将协议或数据格式信息与某个抽象实体（如 message、operation 或 portType 等）相关联的过程。WSDL 允许将代表特定技术的元素（此处称为扩展性元素）放置在 WSDL 所定义的各种元素之下。这些可扩展点通常用于指定特定协议或消息格式的绑定信息，但也可用于其它用途。扩展性元素所用的 XML 名称空间不能与 WSDL 的名称空间相同。附录 A3 中详细说明了

40、扩展性元素可在文档中的哪些位置出现。 扩展性元素通常用于指定某种特定技术的绑定。为了区分特定技术绑定的语义对通信是必需的还是可选的，可以在扩展性元素上设置一个布尔型的 wsdl:required 属性。该属性的默认值为假 (false)。定义该属性的名称空间为“http://schemas.xmlsoap.org/wsdl/soap/”。 有关扩展性元素的示例，请参见第 3 节、第 4 节和第 5 节。 文档 WSDL 使用可选的 wsdl:document 元素作为可阅读文档的容器。该元素的内容可以是任意文本和元素（混杂在 XSD 中）。在所有 WSDL 语言元素中，都允许使用文档

41、元素。 类型 types 元素包含与交换的消息相关的数据类型定义。为了获得最大程度的互操作性和平台中立性，WSDL 选用 XSD 作为标准类型系统，并将其当作固有类型系统。 * 可以使用 XSD 类型系统来定义消息中的类型，无论所得到的线上格式是否为 XML，也无论所得到的 XSD 架构是否验证了该特定线上格式。如果同一消息具有多个绑定，或者虽然只有一个绑定，但该绑定类型的类型系统不通用，则会出现非常有趣的情况。在这种情况

42、下，如果使用 XSD 对抽象类型进行编码，建议遵循下列原则： · 使用元素形式（不要使用属性）。 · 不要使用对线上编码非常特殊的属性或元素（也就是说，与消息的抽象内容无关的属性或元素），例如，soap:root、soap:encodingStyle、xmi:id 和 xmi:name 等。 · 使用 Soap:Array 类型来为数组类型建模（无论最终形式是否实际使用 SOAP 1.1 版文档的第 5 节中指定的编码方式）。使用 ArrayOfXXX 作为数组类型的名称（其中，XXX 表示数组中项的类型）。 但是，由于不可能使用一种类型系统语法来描述现在和将来的所有抽象类型，因

43、此，WSDL 允许通过扩展性元素来添加类型系统。扩展性元素可能出现在 types 元素之下，它标识正在使用的类型定义系统并为类型定义提供 XML 容器元素。该元素的作用与 XML 架构语言的 schema 元素的作用相似。 <-- type-system extensibility element --> * 消息 消息由一个或多个逻辑片段构成。每个片段使用一个消息类型属性与某个类型系统的类型相关联。消息类型属性的集合是可扩展的。WSDL 定义了以下几个

44、消息类型属性，与 XSD 一起使用： · element：使用 QName 引用一个 XSD 元素。 · type：使用 QName 引用一个 XSD simpleType 或 complexType。 如果使用的名称空间与 WSDL 所用的名称空间不同，还可以定义其它消息类型属性。绑定扩展性元素也可以使用消息类型属性。 定义消息的语法如下所示。其中，消息类型属性以粗体显示（消息类型属性因所用类型系统而异）。 *

45、"qname" type="qname"?/> * 消息 name 属性所指定的名称在其所在 WSDL 文档定义的全部消息中是唯一的。 片段 name 属性所指定的名称在其所在消息的所有片段中是唯一的。 消息片段 片段是一种用于描述消息的逻辑抽象内容的灵活机制。绑定可以引用片段的名称来指定有关该片段的绑定专用信息。例如，如果定义用于 RPC 的消息，片段可以代表消息中的参数。但是，为了确定该片段的实际含义，必须对绑定进行检查。 如果消息有多个逻辑单元，则使用多个片段元素。例如，以下消息包括“订单”和“客户”两个片段元

46、素。

47、

48、

49、types> 但是，如果消息内容十分复杂，则需要使用另一种语法，通过直接使用类型系统来指定消息的复合结构。在下例中，主体是一个订单或一组客户。

50、xType name="POType">

51、

53、s="0" maxOccurs="unbounded" type="tns:CustomerType"/> 抽象消息与具体消息 消 息定义始终被当作消息内容的抽象定义。消息绑定描述如何将抽象内

54、容映射为具体的格式。但是，在某些情况下，抽象定义可能与一个或多个绑定的具体表示方式完 全相符或十分接近，致使这些绑定不能提供任何映射信息或只能提供少量信息；而同一消息定义的另一个绑定可能需要大量的映射信息。因此，只有在对绑定进行检 查之后，才能确定消息的实际“抽象程度”。 端口类型 端口类型是一组指定的抽象操作，以及所涉及的抽象消息。 *

55、sdl:definitions> 端口类型 name 属性所指定的名称在其所在 WSDL 文档定义的所有端口类型中是唯一的。 操作是通过 name 属性来命名的。 WSDL 提供以下四个可得到端点支持的传输原语： · 单向 (One-way)：端点接收消息。 · 请求响应 (Request-response)：端点接收消息，然后发送相关消息。 · 要求响应 (Solicit-response)：端点发送消息，然后接收相关消息。 · 通知 (Notification)：端点发送消息。 WSDL 称这些原语为操作。虽然可以使用两条单向消息抽象地模拟请求/响应或要求/响应，但

56、是将其作为原语操作类型模型也很有用，因为： · 经常需要使用这两个操作。 · 可以使顺序相互关联，而不必引入更为复杂的流信息。 · 某些端点可以只接收消息（如果它们是同步请求响应的结果）。 · 需要流定义时，可以通过算法从这些原语派生简单的流。 虽然请求/响应或要求/响应在 WSDL 文档中是逻辑相关的，仍然有一个特定的绑定描述具体的相关信息。例如，请求消息和响应消息可以作为一两个实际网络通信的一部分进行交换。 操作使用类型为 QName 的 message 属性来引用所涉及的消息。该属性遵循 WSDL 为链接定义的规则。 单向操作 单向操作的语法是：

57、:definitions…> * input 元素指定单向操作的抽象消息格式。 请求响应操作 请求响应操作的语法是： *

58、 *

59、itions> input 元素和 output 元素分别指定请求和响应的抽象消息格式。可选的 fault 元素为操作可能产生的错误消息（协议所特有的除外）指定抽象消息格式。 请注意，请求响应操作是一个抽象的概念；必须查询特定的绑定，才能确定消息的实际发送方式：是在同一个通信中发送（例如 HTTP 请求/响应），还是作为两个独立的通信发送（例如两个 HTTP 请求）。 要求响应操作 要求响应操作的语法是： *

60、eterOrder="nmtokens"> * output 元素和 input 元素分别指定所要求的请求和响

61、应的抽象消息格式。可选的 fault 元素为操作可能产生的错误消息（协议所特有的除外）指定抽象消息格式。 请注意，请求响应操作是一个抽象的概念；必须查询特定的绑定，才能确定消息的实际发送方式：是在同一个通信中发送（例如 HTTP 请求/响应），还是作为两个独立的通信发送（例如两个 HTTP 请求）。 通知操作 单向操作的语法是： *

62、sage="qname"/> output元素指定通知操作的抽象消息格式。 操作中的元素名称 inuput 元素和 output 元素的 name 属性所指定的名称在其所在端口类型的所有 input 元素和 output 元素中是唯一的。 为了避免需要为操作中的每个 input 元素和 output 元素指定名称，WSDL 提供了一些以操作名称为基础的默认值。如果未在单向消息或通知消息中指定 name 属性，则该属性默认为操作的名称；如果未在请

63、求响应或要求响应操作的输入或输出消息中指定 name 属性，则该属性默认为分别附带有“Request”/“Solicit”或“Response”的操作名称。 必须为每个 fault 元素指定名称，绑定才能指定错误消息的具体格式。fault 元素的名称在为该操作定义的错误集合中是唯一的。 操作中的参数顺序 操作并不指定它们是否与类似 RPC 这样的绑定一起使用。但是，当操作与 RPC 绑定一起使用时，能够捕获原始 RPC 函数签名非常有用。因此，请求响应或要求响应操作可以通过类型为 nmtokens 的 parameterOrder 属性来指定参数名称列表。该属性的值是一个由单个空格分隔的消息片段名称列表。指定的片段必须遵循以下规则： · 指定片段的顺序必须反映 RPC 签名中的参数顺序 · return 值片段不在列表中出现 · 如果片段名称同时在输入和输出消息中出现，则片段是 in/out 参数 · 如果片段名称只在输入消息中出现，则片段是 in 参数 · 如果片段名称只在输出消息中出现，则片段是 out 参数 请注意，该信息仅作为“提示”，对于那些不关心 RPC 签名的用户，完全可以忽略。而且，即使当操作与类似 RPC 这样的绑定一起使用时，也不是必须使用