级别： 初级 IBM, 作者
2003 年 3 月 01 日 本文档定义了 WS-I 基本概要 1.0（WS-I Basic Profile 1.0），本概要由一组非专有的 Web 服务规范以及对这些旨在促进互操作性的规范的说明和修正组成。
编辑： Keith Ballinger，Microsoft David Ehnebuske，IBM Martin Gudgin，Microsoft
Mark Nottingham，BEA Systems Prasad Yendluri,，webMethods 管理联系人：
secretary@ws-i.org
摘要
本文档定义了 WS-I 基本概要 1.0，本概要由一组非专有的 Web 服务规范以及对这些旨在促进互操作性的规范的说明和修正组成。
本文档的状态
这是最终的规范。读者应该访问
WS-I.orgweb 站点来获得勘误表和更新。
目录
1.
引言
1.1.
指导原则
1.2.
词语约定
2.
概要的范围
3.
概要的一致性
3.1.
构件的一致性
3.2.
服务、消费者和注册中心的一致性
3.3.
描述中的一致性注解
3.4.
消息中的一致性注解
3.5.
注册中心数据中的一致性注解
4.
消息传递
4.1.
SOAP 消息中的 XML 表示
4.1.1.
SOAP 消息和 Unicode BOM
4.1.2.
SOAP Fault 语法
4.1.3.
SOAP Fault 和名称空间
4.1.4.
SOAP Fault 可扩展性
4.1.5.
SOAP Fault 语言
4.1.6.
SOAP 自定义 Fault 代码
4.1.7.
SOAP encodingStyle 属性
4.1.8.
SOAP 的 XML 的使用
4.1.9.
SOAP 和 XML 声明
4.1.10.
SOAP 尾部
4.1.11.
可接受的 SOAP 字符编码
4.1.12.
SOAP mustUnderstand 属性
4.1.13.
SOAP 体和名称空间
4.1.14.
SOAP 信封名称空间
4.1.15.
xsi:type 属性的使用
4.2.
SOAP 处理模型
4.2.1.
强制性头
4.2.2.
生成 mustUnderstand Fault
4.2.3.
SOAP Fault 处理
4.3.
HTTP 中的 SOAP 的使用
4.3.1.
HTTP 版本
4.3.2.
识别 SOAP Fault
4.3.3.
HTTP 方法和扩展
4.3.4.
SOAPAction 头语法
4.3.5.
HTTP 和 TCP 端口
4.3.6.
HTTP 成功状态码
4.3.7.
HTTP 重定向状态码
4.3.8.
HTTP 客户端错误状态码
4.3.9.
HTTP 服务器错误状态码
4.3.10.
HTTP Cookies
5.
服务描述
5.1.
文档结构
5.1.1.
WSDL Schema 定义
5.1.2.
WSDL 和 Schema 导入
5.1.3.
WSDL 导入 location 属性语法
5.1.4.
WSDL 导入 location 属性语义
5.1.5.
WSDL 导入元素的位置
5.1.6.
XML 版本需求
5.1.7.
WSDL 和 Unicode BOM
5.1.8.
可接受的 WSDL 字符编码
5.1.9.
名称空间强制
5.1.10.
WSDL documentation 元素
5.1.11.
WSDL 扩展
5.2.
类型
5.2.1.
QName 引用
5.2.2.
Schema targetNamespace 语法
5.2.3.
soapenc:Array
5.2.4.
WSDL 和 Schema 定义目标名称空间
5.3.
消息
5.3.1.
绑定和部分
5.3.2.
绑定和 Fault
5.3.3.
未绑定的 portType 元素内容
5.3.4.
声明 part 元素
5.4.
端口类型
5.4.1.
part 元素的排序
5.4.2.
允许的操作
5.4.3.
独特的操作
5.4.4.
parameterOrder 属性构造
5.4.5.
类型和元素属性的排他性
5.5.
绑定
5.5.1.
SOAP 绑定的使用
5.6.
SOAP 绑定
5.6.1.
指定 transport 属性
5.6.2.
HTTP 传输
5.6.3.
style 属性的一致性
5.6.4.
编码和 use 属性
5.6.5.
use 属性的缺省值
5.6.6.
portType 元素的多个绑定
5.6.7.
操作的有线签名
5.6.8.
端点上的多个端口
5.6.9.
文档-文字绑定的子元素
5.6.10.
单向操作
5.6.11.
soapbind 元素的名称空间
5.6.12.
portType 和绑定元素的一致性
5.6.13.
描述 headerfault 元素
5.6.14.
Fault 的枚举
5.6.15.
SOAP 绑定元素的类型和名称
5.6.16.
Fault 中的 name 属性
5.6.17.
use 属性的省略
5.6.18.
消息与描述的一致性
5.6.19.
响应包装器
5.6.20.
部分访问器的名称空间
5.6.21.
部分访问器元素的子元素的名称空间
5.6.22.
必需的头
5.6.23.
允许的未描述头
5.6.24.
头的排序
5.6.25.
描述 SOAPAction
5.6.26.
SOAP 绑定扩展
5.7.
XML Schema 的使用
6.
服务发布和发现
6.1.
bindingTemplates
6.2.
tModels
7.
安全性
7.1.
HTTPS 的使用
附录 I:
引用的规范
附录 II:
可扩展性点
附录 III:
致谢
 |
|
引言
本文档定义了 WS-I 基本概要 1.0（以下简称为“概要”），本概要由一组非专有的 Web
服务规范以及对这些旨在促进互操作性的规范的说明和修正组成。
第 1 节简要介绍了本概要，并且讲述了它采用的关于互操作性的基本原理。
第 2
节，“概要的范围”，描述了本概要提高互操作性的方面。
第 3 节，“概要的一致性”，解释了符合本概要的含义。
随后的每一节都各自讲解本概要的一个方面，由两部分组成：首先是概述，详细介绍了组成概要的规范以及它们的可扩展性点；接下来是若干子节，讲解组成概要的规范的各个部分。注意，本文档中的子节编号与引用的规范的编号无关。
指导原则
本概要是按照一组原则制订的，这些原则一起构成了本概要的基本原理，因为它涉及促进互操作性。本节叙述这些原则。
- 不保证互操作性
- 完全保证特定服务的互操作性是不可能的。然而，本概要解决实现经历到目前为止暴露出的问题。
- 应用程序语义
- 虽然应用程序语义的传递可以通过组成本概要的技术加以简化，但是确保对这些语义有共同的理解的问题并未因此而解决。
- 可测试性
- 如果可能，本概要可以使语句具有可测试性。然而，这样的可测试性并不是必需的。最好以非干扰的方式完成测试（例如，检验构件是否“在线（on the
wire）”）。
- 需求强度
- 本概要使强需求（比如
必须、
绝不可以）在无论何处都是可行的；如果在一些合理的情况下，这样的需求不能满足，就可以使用条件需求（例如，
应该、
不应该）。可选需求和条件需求引入了实现之间的模糊和失配。
- 限制与放松
- 在放大引用的规范的需求时，本概要可以限制它们，但是不放松它们（例如，将
必须改为
可以）。
- 多种机制
- 如果引用的规范允许交替地使用多种机制，则本概要就选择好理解的、广泛使用的、有效的机制。外部的或尚未得以确认的机制和扩展会带来复杂性，并因而减少互操作性。
- 未来兼容性
- 如果可能，本概要会根据它引用的规范的修订来定位其需求（例如 SOAP
1.2、WSDL 1.2）。这可以帮助实现人员顺利地进行过渡，并且确保 WS-I
不从这些工作中“分叉”。 当本概要不能解决所引用的规范中的问题时，可以将这种信息传递给适当的组织以提请它加以考虑。
- 与已部署的服务的兼容性
- 与已部署的 Web 服务的向后兼容并不是本概要的目标，但是对这个问题也给予了适当的考虑；本概要并不引入对所引用规范的需求的更改，除非这样做能够解决特定的互操作性问题。
- 集中于互操作性
- 虽然在所引用的规范中可能存在许多不一致的地方或设计错误，但是本概要只解决那些影响互操作性的问题。
- 一致性目标
- 如果有可能，本概要会将需求设置在构件（例如 WSDL
描述、SOAP
消息）之中，而不是产生或使用软件的行为或角色。构件是具体的，这使它们更易于检验，因而使一致性更易于理解并不容易出错。
- 低层互操作性
- 本概要论及应用程序层的互操作性；它假定低层协议（例如
TCP、IP、Ethernet）的互操作性是足够的并且是好理解的。同样地，也只有在出现明确影响 Web
服务的问题时，它才提及应用程序层的底层协议；WS-I
并未试图确保这些协议作为一个整体的互操作性。这保证了 WS-I
专注和集中于有效地使用 Web 服务标准。
词语约定
本文档中的关键字“
必须（MUST）”、“
绝不可以（MUST NOT）”、“
需要的（REQUIRED）”、“
将（SHALL）”、“
将不（SHALL NOT）”、“
应该（SHOULD）”、“
不应该（SHOULD NOT）”、“
推荐（RECOMMENDED）”、“
可以（MAY）”和“
可选的（OPTIONAL）”应该按照
RFC2119 中的描述进行解释。
本概要中的标准化语句（即“概要一致性”中概述的影响一致性的语句）以下列方式进行表述：
Rnnnn 语句 文本。
其中，“nnnn”由语句编号替代。每个语句只包含一个需求级别关键字（例如
必须）和一个一致性目标关键字（例如“
消息”）。
有些语句说明所引用的规范，但是不对实现提出附加的约束条件。为了方便起见，这样的说明以下列方式进注解：C
有些语句源于对所引用的规范正在进行的标准化工作。为了方便起见，这样提前获得的语句以下列方式进行注解：xxxx，其中“xxxx”是规范的标识符（例如，“SOAP12”表示正在制订的 SOAP
版本 1.2 ）。注意，由于这些工作还没有最后完成，所以从中得出需求的规范可能会发生改变；包括这种信息只是为了给实现人员提供方便。
在整个规范中使用了许多名称空间；下面列出了其相关的
URI。注意，任何名称空间前缀的选择都是任意的，并且在语义上没有什么影响。
-
soap—— “http://schemas.xmlsoap.org/soap/envelope/”
-
xsi—— “http://www.w3.org/2001/XMLSchema-instance”
-
xsd—— “http://www.w3.org/2001/XMLSchema”
-
soapenc—— “http://schemas.xmlsoap.org/soap/encoding/”
-
wsdl—— “http://schemas.xmlsoap.org/wsdl/”
-
soapbind—— “http://schemas.xmlsoap.org/wsdl/soap/”
-
wsi—— “http://ws-i.org/schemas/conformanceClaim/”
-
uddi—— “urn:uddi-org:api_v2”
概要的范围
概要的
范围描述它解决的技术问题；换句话说，本概要只试图提高它自己的范围内的互操作性。最初，概要的范围是以它引用的规范为界的；要获得本概要引用的规范的完整清单，请参见附录
I。
概要的范围进一步通过
可扩展性点得以细化。所引用的规范往往会提供扩展机制和尚未得以确认或尚未定型的配置参数。如果标识为可扩展性点，则这样的机制或参数就超出了本概要的范围，并且其使用不以符合本概要为条件。
因为可扩展性点的使用可能会削弱互操作性，所以 Web
服务的各方应该以某种方式协商和文档化它们的使用；例如，这可以采取额外协定的形式。
注意，此规范仍然可以提出对可扩展性点的使用的需求，而无需约束它的范围。另外，可扩展性点的特定使用还可以通过其他概要进一步限制，以便提高它们在与本概要一起使用时的互操作性。
要获得本概要的可扩展性点的完整清单，请参见附录 II。
概要的一致性
符合本概要定义为遵循本概要的范围内特定目标的一组需求。
概要的范围定义如上（“概要的范围”）；符合本概要依赖于符合在范围内引用的规范，只是在与概要的需求相冲突时，才优先考虑一致性的目的。
需求声明在其规定的范围内符合本概要的标准。它们使其中提高互操作性的细化、解释和说明具体化。需求级别使用 RFC2119
语言（例如
必须、
可以、
应该）来指示需求的性质及其对一致性的影响。为了方便起见，每个需求都是单独标识的。
可以在本概要中包括其他的文本来说明需求（例如基本原理和示例）；然而，在确定一致性时应该仅仅考虑需求语句。
目标供在不同的上下文中描述一致性之用，这使得可以对构件（比如 SOAP
消息和 WSDL 描述）、Web 服务实例、Web
服务消费者进行一致性测试和认证。下面的几节描述本概要的一致性目标。
为了使服务能够通告符合本概要，可以通过
一致性声明来注解消息、描述和注册中心，一致性声明使用
URI 来断言符合特定的概要。
本概要的一致性声明 URI 为“http://ws-i.org/profiles/basic/1.0”。
构件的一致性
最基本的一致性级别是构件的一致性。本概要对三种构件进行了需求声明：
-
消息 —— 通常在网络上交换并且对
Web 服务产生影响的协议元素（例如 SOAP/HTTP
消息）。
-
描述 ——
对类型、消息、接口及其具体协议和数据格式绑定、和与 Web
服务相关的网络访问点的描述（例如 WSDL 描述）。
-
注册中心数据 —— 涉及 Web
服务的注册和发现的注册中心元素（例如 UDDI tModel）。
如果与构件的实例相关的所有需求都满足，就可以认为其符合概要。
服务、消费者和注册中心的一致性
如果已部署的 Web 服务的实例（由
wsdl:port
or
uddi:bindingTemplate
指定）只产生符合概要的构件，并且能够使用符合概要的适当构件，就可以认为其符合概要。请注意，在可能存在多个符合概要的组件的情况下，符合概要的服务必须能够使用它们中的全部（例如，在发送消息时，如何发送者可以选择或者 UTF-8
或者 UTF-16 来编码 XML，则接收者就必须能够使用这两种编码方式）。
同样地，如果服务实例的消费者只产生符合概要的的构件，并且能够使用符合概要的适当构件，就可以认为其符合概要。
最后，如果注册中心满足目标
注册中心的概要的需求，就可以认为其符合概要。
-
实例 —— 实现
wsdl:port 或
uddi:bindingTemplate
的软件。
-
消费者—— 调用
实例的软件。
-
注册中心 —— UDDI
注册中心，能够管理
注册中心数据。
符合概要的 Web 服务实例必须遵循与
实例相关的所有需求语句。
同样地，符合概要的消费者必须遵循所有与
消费者相关的需求语句。
符合概要的 Web 服务实例和消费者必须适当地遵循与
发送者和
接收者相关的需求语句：
-
发送者 ——
按照与其相关的协议生成消息的软件。
-
接收者 ——
按照与其相关的协议生成消息的软件（例如 SOAP
处理器）。
注意，一致性并不应用于作为一个整体的服务；只有在确定实例的一致性时才会考虑端口。因此，本概要没有对
wsdl:service
定义提出约束条件。特别地，它们可以包含多个
wsdl:port
元素，而其中的每一个都可以符合概要也可以不符合概要。
如果 Web 服务的类型（由
wsdl:binding 和
wsdl:portType
描述）在正确地实现并部署到预定运行的环境中之后产生符合概要的实例，则可以认为其符合概要。
此外，Web
服务的实例需要订立在其可用时以某种方式运行的契约。
R0001
实例必须由 WSDL 1.1 服务描述语言、UDDI
绑定模板或两者同时进行描述。
在此上下文中，“描述”意味着如果经授权的消费者请求符合概要的服务实例的服务描述，服务实例提供者就必须使 WSDL
文档、UDDI
绑定模板或两者可用于消费者。服务实例可以提供对服务器中的 WSDL
文档的运行时访问，但是为了被认为是符合概要，并不需要这样做。同样地，服务实例提供者可以在 UDDI
注册中心注册实例，但是为了被认为是符合概要，并不需要这样做。在所有这些场景中，WSDL
契约都必须存在，但是可能需要根据环境通过各种机制来进行使用。
描述中的一致性注解
一致性声明可以与特定的 WSDL 元素（例如
wsdl:portType ）相关联，这样就把它们包含在该构造的范围内。
R0002
描述可以包含关于实例的一致性声明，正如一致性声明
Schema 中所定义的。
R0003
描述的一致性声明
必须是下列每个元素的
wsdl:documentation
元素的子元素：
wsdl:port 、
wsdl:binding 、
wsdl:portType 、
wsdl:operation （作为
wsdl:portType 而不是
wsdl:binding
的子元素）和
wsdl:message 。
元素的一致性声明意味着元素符合（和它表示的实例，就端口而言）符合它声明遵守的概要的的需求，这些需求对于元素的这种类型是相关的。
根据以下递归应用的传递性原则，元素的声明还暗示着同样的声明是对它使用的所有元素作出的：
-
wsdl:port 的声明是通过引用的
wsdl:binding 继承得到的。
-
wsdl:binding 的声明是通过引用的
wsdl:portType 继承得到的。
-
wsdl:portType 的声明是通过引用的
wsdl:operation s 继承得到的。
- A claim on a
wsdl:operation
的声明是通过它的子元素
wsdl:output
和/或
wsdl:input is 引用的
wsdl:message s
继承得到的。
一致性声明 Schema 如下：
<?xml version="1.0" encoding="UTF-8" ?>
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"
targetNamespace="http://ws-i.org/schemas/conformanceClaim/"
xmlns:tns="http://ws-i.org/schemas/conformanceClaim/"
xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"
elementFormDefault="qualified"
attributeFormDefault="unqualified" >
<xsd:import namespace="http://schemas.xmlsoap.org/soap/envelope/"
schemaLocation="http://schemas.xmlsoap.org/soap/envelope/" />
<xsd:element name="Claim" >
<xsd:complexType>
<xsd:sequence>
<xsd:any namespace="##any" processContents="lax"
minOccurs="0" maxOccurs="unbounded" />
</xsd:sequence>
<xsd:attribute name="conformsTo" type="xsd:anyURI" use="required"/>
<xsd:attribute ref="soap:mustUnderstand" use="prohibited" />
<xsd:anyAttribute namespace="##any" processContents="lax"/>
</xsd:complexType>
</xsd:element>
</xsd:schema>
|
例如，
正确：
<wsdl:definitions xmlns:wsdl="http://schemas.xmlsoap.org/wsdl"
xmlns:tns="http://example.org/myservice"
xmlns:soapbind="http://schemas.xmlsoap.org/wsdl/soap"
xmlns:wsi="http://ws-i.org/schemas/conformanceClaim/"
targetNamespace="http://example.org/myservice">
<wsdl:portType name="MyPortType">
...
</wsdl:portType>
<wsdl:binding name="MyBinding" portType="MyPortType" >
...
</wsdl:binding>
<wsdl:service name="MyService" >
<wsdl:port name="MyPort" binding="tns:MyBinding" >
<wsdl:documentation>
<wsi:Claim conformsTo="http://ws-i.org/profiles/basic/1.0" />
</wsdl:documentation>
<soapbind:address location="http://example.org/myservice/myport" />
</wsdl:port>
</wsdl:service>
</wsdl:definitions>
|
消息中的一致性注解
随着本概要的新版本以及其他的概要的发行，服务有可能支持多个概要。当接收消息时，服务可能希望能够将概要确定为该消息符合的概要。为了使 SOAP
消息能够指示它们符合的概要，WS-I 规定用 wsi:Claim
元素作为 SOAP 头。
R0004
消息可以包含一致性声明，正如在一致性声明
Schema 中所指定的。
R0005
消息的一致性声明
必须作为
SOAP 头代码块来携带。
R0006
消息可以包含多个概要的一致性声明。
R0007
发送者在发送包含一致性声明的 SOAP
头代码块时
绝不可以使用
soap:mustUnderstand
属性。
SOAP 消息可以包含作为 SOAP
头代码块携带的一致性声明来向接受者指示发送者声明消息符合一个或多个概要。消息中缺少一致性声明绝不可以解释为暗示消息符合或不符合一个或多个概要。另外，一致性声明头代码块被认为是用于提供信息的，因此绝不可以作为强制性的头代码块。故本概要制止在一致性声明头代码块中使用 soap:mustUnderstand
属性。
例如，
正确：
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" >
<soap:Header>
<!-- other headers -->
<wsi:Claim conformsTo="http://ws-i.org/profiles/basic/1.0"
xmlns:wsi="http://ws-i.org/schemas/conformanceClaim/" />
<!-- other headers -->
</soap:Header>
<soap:Body>
<!-- body content -->
</soap:Body>
</soap:Envelope> |
3.5 注册中心数据中的一致性注解
注解描述以及概要的一致性声明的各种元素的方式对
uddi:tModel
元素同样是有效的。 UDDI 中用于给
uddi:tModel
添加属性的固有机制是定义和使用分类系统。本概要采用这种机制来给
uddi:tModel s
添加断言符合
WS-I 概要特别是本概要的能力。
R3020
声明符合概要的
uddi:tModel
类型的
注册中心数据必须使用 ws-i-org:conformsTo:2002_12
分类法进行分类。
R3030
声明符合概要的
uddi:tModel
类型的
注册中心数据必须使用对应于本概要的一致性声明的类别值 ws-i-org:conformsTo:2002_12。
R3021
注册中心数据必须通过添加 ws-i-org:conformsTo:2002_12 tModel
定义到其注册中心内容来支持 WS-I
一致性分类系统。
ws-i-org:conformsTo:2002_12 tModel 的 tModel
的内容如下：
<tModel tModelKey="uuid:65719168-72c6-3f29-8c20-62defb0961c0">
<name>ws-i-org:conformsTo:2002_12</name>
<description xml:lang="EN">Category system used for UDDI entities
to point to the WS-I concept to which they conform to</description>
<overviewDoc>
<overviewURL>http://ws-i.org/schemas/conformanceClaim/</overviewURL>
</overviewDoc>
<categoryBag>
<keyedReference
keyName="uddi-org:types:categorization"
keyValue="categorization"
tModelKey="uuid:C1ACF26D-9672-4404-9D70-39B756E62AB4" />
</categoryBag>
</tModel>
|
例如，
正确：
<tModel tModelKey="...">
<name>BarSOAPService</name>
<description xml:lang="EN">Bar's SOAP Service</description>
<overviewDoc>...</overviewDoc>
<categoryBag>
<keyedReference
tModelKey="uuid:65719168-72c6-3f29-8c20-62defb0961c0"
keyName="ws-I_conformance:BasicProfile1.0"
keyValue="http://ws-i.org/profiles/basic/1.0" />
</categoryBag> |
由于
wsdl:service 元素不必映射到单个
uddi:businessService ，并且还不受一致性声明的影响，所以如果
uddi:businessEntity
或
uddi:businessService
元素声明符合本概要，则
wsdl:service
元素的含义是不明确的。此外，不能对
uddi:bindingTemplate
元素进行分类，因为 UDDI V2 XML Schema
没有为它们提供
uddi:categoryBag 。因而，
wsdl:port
元素所作的一致性声明不能包含在相应的
uddi:bindingTemplate 中。
R3005
不同于表示符合概要的 Web 服务类型的
uddi:tModel
元素 的
注册中心数据绝不可以使用 ws-i-org:conformsTo:2002_12
分类法和“http://ws-i.org/profiles/basic/1.0”分类类别来分类。
如果
uddi:tModel
所作的一致性声明与其使用的
wsdl:binding
所作的一致性声明不一致，则这种语义是模糊的。
R3004
必须构造
uddi:tModel
类型的
注册中心数据，这样它所作的一致性声明就会与其引用的
wsdl:binding
所作的一致性声明相一致。
4. 消息传递
本概要的这一节通过引用并入了下列规范，并且定义了这些规范中的可扩展性点：
4.1 SOAP 消息中的 XML 表示
在此规范的这一节中引用了下列规范（或其中的章节）：
SOAP 1.1 为传递消息定义了一种基于 XML 的结构。本概要要求使用这种结构，并且对其使用提出了以下约束条件：
4.1.1 SOAP 消息和 Unicode BOM
XML 1.0 允许 UTF-8 编码包括 BOM；因此，消息的接收者必须准备接受它们。对于按照
UTF-16 编码 XML，BOM 是强制性的。
R4001
接收者必须接受包括 Unicode
字节顺序标记（Byte Order Mark，BOM）。C
4.1.2 SOAP Fault 语法
SOAP Fault
是一个 SOAP 消息，它包含
soap:Body
元素的一个子元素，这个元素就是
soap:Fault 元素。本概要将
soap:Fault
元素的内容限制为 SOAP 1.1 中描述的元素。
R1000
当
消息包含
soap:Fault
元素时，该元素
绝不可以有
faultcode 、
faultstring 、
faultactor
和
detail 之外的子元素。
例如，
错误：
<soap:Fault xmlns:soap='http://schemas.xmlsoap.org/soap/envelope/' >
<faultcode>soap:Client</faultcode>
<faultstring>Invalid message format</faultstring>
<faultactor>http://example.org/someactor</faultactor>
<detail>There were <b>lots</b> of elements in the message
that I did not understand
</detail>
<m:Exception xmlns:m='http://example.org/faults/exceptions' >
<m:ExceptionType>Severe</m:ExceptionType>
</m:Exception>
</soap:Fault> |
正确：
<soap:Fault xmlns:soap='http://schemas.xmlsoap.org/soap/envelope/' >
<faultcode>soap:Client</faultcode>
<faultstring>Invalid message format</faultstring>
<faultactor>http://example.org/someactor</faultactor>
<detail>
<m:msg xmlns:m='http://example.org/faults/exceptions'>
There were <b>lots</b> of elements in the message that I did not understand
</m:msg>
<m:Exception xmlns:m='http://example.org/faults/exceptions'>
<m:ExceptionType>Severe</m:ExceptionType>
</m:Exception>
</detail>
</soap:Fault> |
4.1.3 SOAP Fault 和名称空间
soap:Fault
元素的子元素局限于该元素，因此名称空间限定是不必要的。
R1001
当
消息包含
soap:Fault
元素时，它的子元素
必须是未限定的。
例如，
错误：
<soap:Fault xmlns:soap='http://schemas.xmlsoap.org/soap/envelope/' >
<soap:faultcode>soap:Client</soap:faultcode>
<soap:faultstring>Invalid message format</soap:faultstring>
<soap:faultactor>http://example.org/someactor</soap:faultactor>
<soap:detail>
<m:msg xmlns:m='http://example.org/faults/exceptions'>
There were <b>lots</b> of elements in the message that
I did not understand
</m:msg>
</soap:detail>
</soap:Fault> |
正确：
<soap:Fault xmlns:soap='http://schemas.xmlsoap.org/soap/envelope/'
xmlns='' >
<faultcode>soap:Client</faultcode>
<faultstring>Invalid message format</faultstring>
<faultactor>http://example.org/someactor</faultactor>
<detail>
<m:msg xmlns:m='http://example.org/faults/exceptions'>
There were <b>lots</b> of elements in the message that
I did not understand
</m:msg>
</detail>
</soap:Fault> |
4.1.4 SOAP Fault 可扩展性
为了可扩展性，允许附加属性出现在
detail
元素中，并且还允许附加元素作为
detail
元素的子元素出现。
R1002
接收者必须接受包含任何数目（包括零在内）作为
detail
元素的子元素出现的 的元素。这样的元素可以是限定的，也可以是未限定的。
R1003
接收者必须接受包含任何数目（包括零在内）出现在
detail
元素中的限定或未限定属性。限定属性的名称空间可以是不同于“http://schemas.xmlsoap.org/soap/envelope/”的任何名称空间。
4.1.5 SOAP Fault 语言
faultstring 是人易读的描述，用于指示 Fault
的性质。同样地，它们不可以使用特定的语言，因此可以用 xml:lang
来指示 faultstring 的语言。
R1016
接收者必须在
faultstring 元素中带有
xml:lang
属性的 Fault 消息。
4.1.6 SOAP 自定义 Fault 代码
SOAP 1.1 通过使用“点”符号允许自定义 Fault
代码出现在
faultcode 元素中。
使用这种机制来扩展 SOAP 1.1 定义的 Fault
代码的含义可能会导致名称空间冲突。故应该避免它的使用，因为在通过右手边的“.”（点）使用相同的名称来传送不同的含义时这样做可能会导致互操作性问题。
而本概要鼓励使用 SOAP 1.1 中定义的 Fault
代码以及
detail
元素的附加信息来传送 Fault 的性质。
此外，在由指定机构控制的名称空间中定义自定义
Fault 代码也是可以接受的。
许多规范已经使用“.”（点）定义了自定义 Fault
代码。尽管如此，在未来的规范中，它们的使用是不鼓励的。
R1004
当
消息包含
faultcode 时，该元素的内容
应该是 SOAP 1.1
中定义的 Fault 代码之一或名称空间限定的 Fault
代码。
R1031
当
消息包含
faultcode 元素时，该元素的内容
不应该使用 SOAP 1.1
中的“.”（点）符号来重新定义 Fault 的含义。
推荐需要自定义 Fault 代码的应用程序或者使用
SOAP1.1 定义的 Fault 代码并且在 detail
元素中提供附加信息，或者在由指定机构控制的名称空间中定义这些代码。
例如，
错误：
<soap:Fault xmlns:soap='http://schemas.xmlsoap.org/soap/envelope/'
xmlns:c='http://example.org/faultcodes' >
<faultcode>soap:Server.ProcessingError</faultcode>
<faultstring>An error occurred while processing the message
</faultstring>
</soap:Fault> |
正确：
<soap:Fault xmlns:soap='http://schemas.xmlsoap.org/soap/envelope/'
xmlns:c='http://example.org/faultcodes' >
<faultcode>c:ProcessingError</faultcode>
<faultstring>An error occured while processing the message
</faultstring>
</soap:Fault> |
正确：
<soap:Fault xmlns:soap='http://schemas.xmlsoap.org/soap/envelope/' >
<faultcode>soap:Server</faultcode>
<faultstring>An error occured while processing the message
</faultstring>
</soap:Fault> |
4.1.7 SOAP encodingStyle 属性
soap:encodingStyle
属性用于指示在将数据编码到 XML
中时所用的特定 Scheme。然而，通过使用 XML
名称空间也可以提供这种功能。因此，本概要推荐使用文字的、非编码的
XML。
R1005
消息绝不可以在名称空间的名称为“ http://schemas.xmlsoap.org/soap/envelope/”的任何元素中包含
soap:encodingStyle
属性。
R1006
消息绝不可以 在
soap:Body
的任何子元素中包含
soap:encodingStyle
属性。
R1007
在 rpc-文字样式的绑定中描述的
消息绝不可以在
soap:Body
的任何孙子元素中包含
soap:encodingStyle
属性。
4.1.8 SOAP 的 XML 的使用
SOAP 消息中处理消息语义的开销和模糊的 XML
DTD 和 PI 可能会引入安全性脆弱性。因此，这些
XML 构造不为 SOAP 1.1 的第 3 节所允许。
R1008
消息绝不可以包含文档类型声明（ Document Type
Declaration） 。 C
R1009
消息绝不可以包含处理指令（Processing
Instructions）。C
4.1.9 SOAP 和 XML 声明
是否存在 XML
声明并不影响互操作性。某些实现可能总是在 XML
声明之前进行 XML 序列化。
R1010
接收者必须接受包含 XML 声明的消息。 C
4.1.10 SOAP 尾部
soap:Body
元素之后的兄弟元素的解释是不清楚的。因此，不允许有这样的元素。
R1011
消息在
soap:Body
元素之后
绝不可以有
soap:Envelope 的任何子元素。
这种需求表明了 SOAP 1.1 规范和 SOAP 1.1 XML Schema
之间的不匹配。
例如，
错误：
<soap:Envelope xmlns:soap='http://schemas.xmlsoap.org/soap/envelope/' >
<soap:Body>
<p:Process xmlns:p='http://example.org/Operations' />
</soap:Body>
<m:Data xmlns:m='http://example.org/information' >
Here is some data with the message
</m:Data>
</soap:Envelope> |
正确：
<soap:Envelope xmlns:soap='http://schemas.xmlsoap.org/soap/envelope/' >
<soap:Body>
<p:Process xmlns:p='http://example.org/Operations' >
<m:Data xmlns:m='http://example.org/information' >
Here is some data with the message
</m:Data>
</p:Process>
</soap:Body>
</soap:Envelope> |
4.1.11 可接受的 SOAP 字符编码
为了促进互操作性，本概要要求所有的 XML
处理器都需要支持“UTF-8”和“UTF-16”字符编码。
由于这个缘故以及 SOAP 1.1 要求使用文本/xml
媒体类型（其缺省的字符编码为“us-ascii”），
charset
参数必须总是在 SOAP
信封的媒体类型中出现。同样是由于这个缘故，总是忽略消息中的 XML
声明的伪属性，以便合乎 XML 1.0 和 RFC3023 “XML
媒体类型” 的需求。
R1012
消息必须序列化为 UTF-8 或 UTF-16。
R1018
消息的信封的媒体类型
必须使用 charset
参数指示正确的字符编码。 C
当 SOAP 与 HTTP 绑定一起使用时，媒体类型是在
Content-Type HTTP
头字段中携带的。
4.1.12 SOAP mustUnderstand 属性
soap:mustUnderstand 属性有限制型的“xsd:boolean”，它只接受“0”或“1”。因此，只有这两个值是允许的。
R1013
包含
soap:mustUnderstand 属性的
消息必须只使用词法形式的“0”和“1”。 C
4.1.13 SOAP 体和名称空间
未限定的元素名的使用可能会导致命名冲突，因此
soap:Body
的子元素必须使用限定名。
R1014
消息中的
soap:Body
元素的子元素
必须是名称空间限定的。
4.1.14 SOAP 信封名称空间
SOAP 1.1 声明，如果消息的
Envelope 元素的名称空间名不同于“http://schemas.xmlsoap.org/soap/envelope/”，则该消息应该丢弃。本概要要求改为生成 Fault
消息，以确保明确的操作。
R1015
如果
接收者遇到的消息的文档元素有局部名称“ Envelope”而其名称空间名不是“http://schemas.xmlsoap.org/soap/envelope/”，则他们
必须生成 Fault
消息。
4.1.15 xsi:type 属性的使用
在许多情况下，发送者和接收者将共享与交换的消息有关的某种形式的信息。只是在没有这样的
Schema 存在并且双方都假定所有的交换项都是“xsd:anyType”的情况下，才需要
xsi:type
属性。
R1017
接收者绝不可以要求在消息中使用
xsi:type
属性，除非是为了指示派生的类型而需要（参见 XML Schema
第一部分：结构（第 2.6.1 节））。
4.2 SOAP 处理模型
本概要的这一节引用下列规范（或其中的章节）：
SOAP 1.1
为处理消息定义了消息交换模型。特别地，它定义了处理头代码块和消息体的规则。它还定义了与
Fault 的生成有关的规则。本概要对处理模型提出以下约束条件：
4.2.1 强制性头
SOAP 1.1
关于处理强制性头代码块的处理机制是尚未得以确认的。强制性代码块是含有值为“1”的
soap:mustUnderstand 属性的
soap:Header
元素的子元素。
R1025
接收者必须以这样的方式处理消息，在任何实际的处理之前执行对强制性头代码块的所有检查。SOAP12
这种需求保证了在处理完消息的其他方之后不良的副作用将不会因注意到强制性头代码块而出现。
4.2.2 生成 mustUnderstand Fault
本概要要求接收者在遇到不理解的针对他们的头代码块时生成 Fault。
R1027
当消息包含针对接收者的强制性头代码块（即含有值为“ 1”的
soap:mustUnderstand
属性的元素）而接收者不理解时，
接收者必须生成“ soap:MustUnderstand” Fault。
4.2.3 SOAP Fault 处理
当 Fault
生成时，就不应该再进行进一步的处理。在请求－响应交换中，Fault
消息将传送给请求消息的发送者，而某些应用程序级错误将显示给用户。
R1028
当
接收者生成 Fault 时，就
不应该再对 SOAP
消息进行进一步的处理，除了这种处理是回滚或补偿在生成 Fault
之前处理消息的任何影响所必需的以外。
R1029
在 SOAP 消息的正常输出将导致传送
SOAP 响应而不是改为生成 SOAP Fault 的情况下，
接收者必须传送 SOAP Fault
消息来代替响应。
R1030
如果可能，生成 SOAP Fault 的
接收者应该通过任何适于该环境的方式通知终端用户
SOAP Fault 已经生成。
4.3 HTTP 中的 SOAP 的使用
本概要的这一节引用下列规范（或其中的章节）：
SOAP 1.1 为 HTTP
定义了一个协议绑定。本概要要求使用该绑定，并且对其使用提出以下约束条件：
4.3.1 HTTP 版本
定义了几个版本的 HTTP。HTTP/1.1
具有性能优势，并且与 HTTP/1.0
相比，指定更明确。
R1140
应该使用 HTTP/1.1 来发送
消息。
R1141
必须使用 HTTP/1.1 或 HTTP/1.0 来发送
消息。
注意，HTTP/1.1 中内含对 HTTP/1.0
的支持，并且中介可以更改消息的版本；要获得更多的关于 HTTP
版本的信息，可以参见 RFC2145 “HTTP
版本编号的使用和解释”。
4.3.2 识别 SOAP Fault
一些消费者实现只使用 HTTP 状态码来确定 SOAP
Fault 的出现。因为存在 Web 基础架构更改 HTTP
状态码的情况，并且为了获得更一般的可靠性，本概要要求它们检验信封。
R1107
接收者必须解释只包含
soap:Fault
元素作为 Fault 的 SOAP 消息。
4.3.3 HTTP 方法和扩展
SOAP1.1 规范定义了它的 HTTP
绑定，这样就可以使用两种可能的方法：HTTP POST
方法和 HTTP 扩展框架（HTTP Extension Framework）的 M-POST
方法。本概要要求只使用 HTTP POST 方法而把 HTTP
扩展框架的使用排除在外。
R1132HTTP 请求
消息必须使用
HTTP POST 方法。
R1108
消息绝不可以使用 HTTP 扩展框架（RFC2774）。
HTTP
扩展框架是试验性的机制，用于以模块化的方式扩展 HTTP。因为它没有得到广泛部署，并且还因为它在使用 SOAP
方面的好处是不可靠的，所以本概要不允许使用它。
4.3.4 SOAPAction 头语法
测试已经表明，需要引用
SOAPAction HTTP
头字段值提高了实现的互操作性。尽管 HTTP
允许未引用的头字段值，但是一些
SOAP 实现需要引用它们。
对于处理器而言，
SOAPAction
纯粹是一个提示。所有关于消息的意图的重要信息都是在
soap:Envelope
中携带的。
R1109
HTTP 请求
消息中的
SOAPAction HTTP
头字段的值
必须是引用字符串。C
R1119
如果
SOAPAction HTTP
头字段的值不是引用的，则
接收者可以以 Fault
进行响应。C
例如，
正确：
含有：
<soapbind:operation soapAction="foo" />
的 WSDL 描述会产生带有如下 SOAPAction HTTP
头字段的消息：
SOAPAction: "foo"
正确：
含有：
<soapbind:operation />
或
<soapbind:operation soapAction="" />
的 WSDL 描述会产生带有如下相应的 SOAPAction HTTP
头字段的消息：
SOAPAction: ""
4.3.5 HTTP 和 TCP 端口
SOAP 设计成能利用 HTTP
基础架构的优势。然而，在有些情况下（例如，包括代理、防火墙或其他中介），可能会存在有害的副作用。因此，实例可能会发现使用 HTTP
的缺省端口（端口 80）之外的端口是可取的。
R1110
实例可以接受 TCP 端口 80（HTTP）上的连接。C
在 W3C 和 IETF 内部，关于适当地使用绑定到 HTTP
的 SOAP 消息的端口 80
有相当多的争论。最后得出的结论是，这是一个可以接受的惯例。
4.3.6 HTTP 成功状态码
HTTP 使用 2xx 序列状态码来显示成功。特别地，200
是成功消息的缺省状态码，而 202
可以用来指示消息已经提交供处理。另外，其他的 2xx
状态码也可能是适当的，这取决于 HTTP
交互的性质。
R1124
实例必须使用 2xx HTTP
状态码作为指示请求的成功输出的响应。
R1111
实例应该使用“ 200 OK” HTTP
状态码作为包含非 SOAP Fault 的 SOAP 消息的响应。
R1112
实例应该使用“ 200 OK”或“ 202
Accepted”状态码作为不包含 SOAP
消息但是指示请求的成功 HTTP 输出的响应。
4.3.7 HTTP 重定向状态码
使用许多 HTTP
状态码会产生互操作性问题，这些问题通常表现在是否使用原始方法或
GET 方面。本概要要求将“307 Temporary Redirect”作为正确的重定向状态码。要了解更多的信息，请参见
RFC2616 中描述的 3xx 状态码。
R1130
实例在将请求重定向到不同的端点时
必须使用 HTTP
状态码“307 Temporary Redirect”。
R1131
消费者在遇到响应中的“ 307 Temporary
Redirect” HTTP 状态码时
可以自动重定向请求。
RFC2616
指出，用户代理不应该自动重定向请求；然而，这种需求针对的是浏览器而不是自动流程（许多 Web
服务将是这样的）。因此，本概要允许但是不要求消费者自动遵循重定向。
4.3.8 HTTP 客户端错误状态码
HTTP 使用 4xx
系列的状态码来指示因客户端错误而导致的失败。虽然有许多情况可能会产生这样的代码，但本概要强调的是 HTTP
请求的有效负载不是正确的媒体类型（即 SOAP/HTTP
绑定所需的“文本/xml”）以及没有使用预期的方法。
R1125
实例必须使用 4xx HTTP
状态码作为指示请求的格式问题的响应。
R1113
如果请求信息是畸形的 HTTP
请求或不是结构良好的 XML，则
实例应该使用“400 Bad Request”HTTP
状态码。
R1114
如果请求方法不是“ POST”，则
实例应该使用“405 Method not
Allowed” HTTP 状态码。
R1115
如果 Content-Type HTTP
请求头不含有与为输入消息的相应绑定指定的值相一致的值，则
实例应该使用“415 Unsupported Media
Type”HTTP 状态码。
注意，这些需求并不强制要求实例响应请求。在某些情况下（比如拒绝服务（Denial of Service）攻击），实例可以选择忽略请求。
4.3.9 HTTP 服务器错误状态码
HTTP 使用 5xx
序列码来指示因服务器错误而导致的失败。
R1126
如果响应消息是 SOAP Fault，则
实例必须使用“500 Internal Server
Error”HTTP 状态码。
4.3.10 HTTP Cookies
HTTP 状态管理机制（“Cookies”）允许创建 Web
浏览器和服务器之间的有状态会话。由于是为超文本浏览而设计的，所以
Cookies 并没有定义明确的
Web 服务语义，并且因为它们相对于 SOAP
信封是外部的，所以 SOAP 1.1 或 WSDL 1.1
都没有附带。然而，在有些情况下使用 Cookies
是必需的，例如，在服务器之间的负载平衡和遗留系统的集成中使用
Cookies。由于这些原因，本概要限制使用 Cookies
的方式，而没有完全禁止它们。
R1120
实例可以使用 HTTP 状态机制（“Cookies”）。
R1122
使用 Cookies 的
实例应该符合 RFC2965。
R1121
实例不应该为了正确地运行而要求支持 Cookies。
R1123
Cookies 的值
必须认为是对
消费者不透明的。
本概要推荐实例不要为了正确地运行而使用 Cookies；它们应该是用于最优化的提示，而并不显著地影响 Web
服务的执行。然而在遗留系统集成和其他的特殊用况中，它们可能是必需的，所以需要它们并没有使实例变得不符合概要。虽然
Cookies
因而对实例有意义，但是它们不应该用作实例和消费者之间的额外数据通道。因此，Cookies
的解释根本不为消费者所允许——消费者需要把它们看作是不透明的（即对消费者没有意义）。
5. 服务描述
本概要采用的是 Web 服务描述语言（Web Services Description Language，WSDL），这使得可以将服务描述成对消息进行处理的端点集。
本概要的这一节通过引用并入了以下规范，并且定义了其中的可扩展性点：
5.1 文档结构
本概要的这一节引用了以下规范（或其他的章节）：
WSDL 1.1 为描述 Web 服务定义了基于 XML
的结构。本概要要求使用这种结构，并且对其使用提出以下约束条件：
5.1.1 WSDL Schema 定义
WSDL 1.1 规范的附录 4 中 WSDL 的标准化 Schema
与该规范的标准化文本有矛盾的地方。本概要引用的是新的
Schema 文档，其中修改了已知的错误。
R2028
根据“ http://schemas.xmlsoap.org/wsdl/2003-02-11.xsd”中的 XML Schema，使用 WSDL
名称空间（在本概要中其前缀为“wsdl”）的
描述必须是有效的。
R2029
根据“http://schemas.xmlsoap.org/wsdl/2003-02-11.xsd”中的 XML Schema，使用 WSDL SOAP
绑定名称空间（在本概要中其前缀为“soapbind”）的
描述必须是有效的。
虽然本概要要求 WSDL 描述是 Schema
有效的，但是它并不要求消费者验证 WSDL
文档。而由 WSDL 文档的作者确保它是 Schema
有效的。
5.1.2 WSDL 和 Schema 导入
WSDL 1.1 中的一些示例错误地展示了用于导入 XML Schema
定义的 WSDL
导入声明。本概要说明了导入机制的使用，以便保证它们是一致的并且被限制到它们各自的域中。导入的
Schema 需求也通过 XML 版本和与这些导入
WSDL 文档一致的编码需求加以约束。
R2001
描述必须只使用 WSDL“导入”语句来导入另一个 WSDL
描述。
R2002
要导入 XML Schema 定义，
描述必须使用 XML Schema“导入”语句。
R2003
描述必须只使用类型章节的
xsd:schema
元素中的 XML Schema“导入”语句。
R2004
描述绝不可以使用 XML Schema“导入”语句来从根元素不是名称空间“http://www.w3.org/2001/XMLSchema”中的“Schema”的任何文档导入 Schema。
R2009
由
描述直接或间接导入的 XML Schema
可以包括
Unicode 字节顺序标记（Byte Order Mark，BOM）。
R2010
由
描述直接或间接导入的
XML Schema
必须使用
UTF-8 或 UTF-16 编码。
R2011
由
描述直接或间接导入的
XML Schema
必须使用可扩展标记语言 W3C 推荐标准（eXtensible Markup Language W3C
Recommendation）的版本
1.0。
例如，
错误：
<definitions name="StockQuote"
targetNamespace="http://example.com/stockquote/definitions"
xmlns:xsd1="http://example.com/stockquote/schemas""
...
xmlns="http://schemas.xmlsoap.org/wsdl/">
<import namespace="http://example.com/stockquote/schemas"
location="http://example.com/stockquote/stockquote.xsd"/>
<message name="GetLastTradePriceInput">
<part name="body" element="xsd1:TradePriceRequest"/>
</message>
...
</definitions> |
正确：
<definitions name="StockQuote"
targetNamespace="http://example.com/stockquote/definitions">
<import namespace="http://example.com/stockquote/definitions"
location="http://example.com/stockquote/stockquote.wsdl"/>
<message name="GetLastTradePriceInput">
<part name="body" element="..."/>
</message>
...
</definitions> |
正确：
<definitions name="StockQuote"
targetNamespace="http://example.com/stockquote/"
xmlns:xsd1="http://example.com/stockquote/schemas"
...
xmlns="http://schemas.xmlsoap.org/wsdl/">
<import namespace="http://example.com/stockquote/definitions"
location="http://example.com/stockquote/stockquote.wsdl"/>
<message name="GetLastTradePriceInput">
<part name="body" element="xsd1:TradePriceRequest"/>
</message>
...
</definitions> |
5.1.3 WSDL 导入 location 属性语法
WSDL 1.1 并未明确规定
wsdl:import 语句是否需要
location
属性或其必需的内容。
R2007
描述必须在
wsdl:import 元素中指定非空的
location
属性。
虽然
wsdl:import 语句是模仿
xsd:import 语句，但是
location
属性是
wsdl:import 所必需的，而
xsd:import
中的相应属性
schemaLocation 是可选的。与
location
一致是必需的，其内容规定为非空。
5.1.4 WSDL 导入 location 属性语义
WSDL 1.1 并未明确规定 WSDL
处理器是否必须实际检索和处理来自它遇到的
wsdl:import
语句的
location 属性指定的 URI 中的 WSDL
文档。
R2008
对
wsdl:import 元素的
location
属性值的
描述应该看作是提示。C
这意味着 WSDL 元素可以但是却不需要检索来自
wsdl:import
元素的
location 属性指定的 URI 中的 WSDL
描述，因为 WSDL
处理器可能会有其他的方式来定位特定名称空间的 WSDL
描述。例如，它可能已经有缓存的或内置的表示，或者它可能检索来自元数据存储库或 UDDI
服务器检索中的表示。
5.1.5 WSDL 导入元素的位置
WSDL 1.1 第 3.1 节中的示例 3 会导致关于
wsdl:import
的位置的混乱。
R2022
当
wsdl:import 元素出现在
描述中时，它们
必须在所有来自 WSDL
名称空间的其他元素（
wsdl:documentation
除外）之前。
R2023
当
wsdl:types 元素出现在
描述中时，它们
必须在所有来自 WSDL
名称空间的其他元素（
wsdl:documentation 和
wsdl:import
除外）之前。
例如，
错误：
<definitions name="StockQuote"
...
xmlns="http://schemas.xmlsoap.org/wsdl/">
<import namespace="http://example.com/stockquote/definitions"
location="http://example.com/stockquote/stockquote.wsdl"/>
<message name="GetLastTradePriceInput">
<part name="body" type="tns:TradePriceRequest"/>
</message>
...
<service name="StockQuoteService">
<port name="StockQuotePort" binding="tns:StockQuoteSoap">
....
</port>
</service>
<types>
<schema targetNamespace="http://example.com/stockquote/schemas"
xmlns="http://www.w3.org/2001/XMLSchema">
.......
</schema>
</types>
</definitions> |
正确：
<definitions name="StockQuote"
targetNamespace="http://example.com/stockquote/definitions">
<import namespace="http://example.com/stockquote/base"
location="http://example.com/stockquote/stockquote.wsdl"/>
<message name="GetLastTradePriceInput">
<part name="body" element="..."/>
</message>
...
</definitions> |
正确：
<definitions name="StockQuote"
...
xmlns="http://schemas.xmlsoap.org/wsdl/">
<types>
<schema targetNamespace="http://example.com/stockquote/schemas"
xmlns="http://www.w3.org/2001/XMLSchema">
.......
</schema>
</types>
<message name="GetLastTradePriceInput">
<part name="body" element="tns:TradePriceRequest"/>
</message>
...
<service name="StockQuoteService">
<port name="StockQuotePort" binding="tns:StockQuoteSoap">
....
</port>
</service>
</definitions> |
5.1.6 XML 版本需求
WSDL 1.1 和 XML Schema 1.0 都不要求特定版本的 XML。出于互操作性的原因，用 XML
表示的 WSDL 文档及其导入的 Schema 必须使用版本
1.0。
R4004
描述必须使用可扩展性标记语言 W3C
推荐标准（eXtensible Markup Language W3C Recommendation）的 1.0
版。
5.1.7 WSDL 和 Unicode BOM
XML 1.0 允许文档使用 UTF-8 字符编码来包括 BOM；因此，描述处理器必须准备接受它们。
R4002
描述可以包括 Unicode
字节顺序标记（Byte Order Mark，BOM）。C
5.1.8 可接受的 WSDL 字符编码
本概要一贯地要求 SOAP 和 WSDL 使用 UTF-8 或 UTF-16
编码（同时参阅 R1012）。
R4003
描述必须使用 UTF-8 或 UTF-16 编码。
5.1.9 名称空间强制
本概要不允许
wsdl:import
中的名称空间强制。
R2005
导入描述的
wsdl:definitions
元素的
targetNamespace 属性
必须具有与导入
描述的
wsdl:import 元素中的
namespace
属性相同的值。
5.1.10 WSDL documentation 元素
WSDL 1.1 Schema 和 WSDL 1.1 规范对于
wsdl:documentation
元素的位置是不一致的。
R2020
wsdl:documentation
元素
可以作为
描述中的
wsdl:import 元素的子元素而出现。WSDL12
R2021
wsdl:documentation
元素
可以作为
描述中的
wsdl:part 元素的子元素而出现。WSDL12
R2024
wsdl:documentation
元素
可以作为
描述中的
wsdl:definitions
元素的第一个子元素而出现。WSDL12
5.1.11 WSDL 扩展
需要支持这个或另外的
WS-I 概要没有显式指定的 WSDL
扩展可能会导致还无法理解这些扩展的开发工具的互操作性问题。
R2025
包含 WSDL 扩展的
描述绝不可以使这些扩展与本概要的其他需求相抵触。
R2026
描述不应该包括声明符合本概要的任何
WSDL 构造（
wsdl:binding 、
wsdl:portType 、
wsdl:message 、
wsdl:types
或
wsdl:import ）中
wsdl:required
的属性值为“true”的扩展元素。
R2027
如果在处理描述中的 WSDL
名称空间内的元素的过程中，消费者遇到这样的 WSDL
扩展元素，其中的子元素具有消费者不理解或不能处理的布尔值为“true”的
wsdl:required 属性，则
消费者必须停止处理
WSDL 名称空间内的该元素。
使用 WSDL 描述和生成 Web
服务实例的软件的开发工具可能没有理解未知
WSDL 扩展的内置功能。因而应该避免使用必需 WSDL
扩展。使用没有可用的使用和语义规范的必需
WSDL 扩展可能会给扩展的作者以外的所有人带来难以处理的互操作性问题。使用有可用的使用和语义规范的必需
WSDL
扩展这方面的问题将减少，但是不会消除产生这种细化的互操作性问题。
以下元素只能通过属性进行扩展：
-
wsdl:import
-
wsdl:part
-
wsdl:portType
-
wsdl:input （在 portType 操作中）
-
wsdl:output （在 portType 操作中）
-
wsdl:fault （在 portType 操作中）
以下元素可以通过元素以及属性进行扩展：
-
wsdl:definitions
-
wsdl:types
-
wsdl:message
-
wsdl:operation
-
wsdl:binding
-
wsdl:input （在 binding 操作中）
-
wsdl:output （在 binding 操作中）
-
wsdl:fault （在 binding 操作中）
-
wsdl:service
-
wsdl:port
5.2 类型
本概要的这一节引用了下列规范（或其中的章节）：
WSDL 1.1 的
wsdl:types 元素封闭了与所描述的 Web
服务有关的数据类型定义。本概要对 WSDL
元素引用来进行概要一致性声明的
wsdl:types
元素的这些内容提出了以下约束条件：
5.2.1 QName 引用
XML Schema 要求每个 QName
引用或者使用目标名称空间或者使用导入名称空间（用
xsd:import
元素显式标记的名称空间）。不允许 QName
引用指向只由嵌套的导入表示的名称空间。
WSDL 1.1 并未明确规定哪些 Schema
目标名称空间适合于 WSDL 元素中的 QName
引用。本概要允许 WSDL 元素中的 QName
引用既可以指向由
xsd:schema
元素定义的目标名称空间，也可以指向导入名称空间。类似于 XML
Schema，不是直接在 WSDL
文件中引用的名称空间（通过
xsd:schema
中的
targetNamespace 属性或通过
xsd:import
中的 namespace 属性）适合于用在 QName
引用中。不允许只通过嵌套的导入定义的指向名称空间的
QName 引用。
R2101
描述绝不可以使用指向既没有导入又没有在引用的 WSDL
文档中定义的名称空间中的元素的 QName 引用。
R2102
指向
描述中的 Schema 组件的 QName 引用
必须使用在
xsd:schema
元素的
targetNamespace
属性中定义的名称空间或在
xsd:schema
元素内的
xsd:import 元素的
namespace
属性中定义的名称空间。
5.2.2 Schema targetNamespace 语法
要求
wsdl:types 的所有子元素都具有 targetNamespace
属性是一种良好的习惯做法，这将 WSDL
文档的作者的负担减少到最低限度，并且避免了没有尽可能地明确定义的情况。
R2105
描述中的
wsdl:types
元素所包含的全部
xsd:schema 元素
必须包含具有有效和非零的值的
targetNamespace 属性，
除非
xsd:schema
元素有
xsd:import 和/或
xsd:annotation
作为其惟一的子元素。
5.2.3 soapenc:Array
在 WSDL 1.1 第 2.2 节中的关于声明数组类型的建议已经存在几种解释方式，这导致了互操作性问题。此外，还有一些其他的方式可以更明确地声明数组。
R2110
在
描述中，数组声明
绝不可以扩展或限制
soapenc:Array 类型。
R2111
在
描述中，数组声明
绝不可以在类型声明中使用
wsdl:arrayType 属性。
R2112
在
描述中，数组声明 wrapper 元素
不应该使用约定
ArrayOfXXX 进行命名。
R2113
包含序列化数组的
消息绝不可以包含
soapenc:arrayType
属性。
例如，
错误：
Given the WSDL Description:
<xsd:element name="MyArray2" type="tns:MyArray2Type"/>
<xsd:complexType name="MyArray2Type"
xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/"
xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/" >
<xsd:complexContent>
<xsd:restriction base="soapenc:Array">
<xsd:sequence>
<xsd:element name="x" type="xsd:string"
minOccurs="0" maxOccurs="unbounded"/>
</xsd:sequence>
<xsd:attribute ref="soapenc:arrayType"
wsdl:arrayType="tns:MyArray2Type[]"/>
</xsd:restriction>
</xsd:complexContent>
</xsd:complexType> |
该 SOAP
消息将序列化为（为了清楚起见，略去了名称空间声明）：
<MyArray2 soapenc:arrayType="tns:MyArray2Type[]" >
<x>abcd</x>
<x>efgh</x>
</MyArray2>
|
正确：
给定如下 WSDL 描述：
<xsd:element name="MyArray1" type="tns:MyArray1Type"/>
<xsd:complexType name="MyArray1Type">
<xsd:sequence>
<xsd:element name="x" type="xsd:string"
minOccurs="0" maxOccurs="unbounded"/>
</xsd:sequence>
</xsd:complexType> |
SOAP
消息将序列化为（为了清楚起见，略去了名称空间声明）：
<MyArray1>
<x>abcd</x>
<x>efgh</x>
</MyArray1> |
5.2.4 WSDL 和 Schema
定义目标名称空间
由 Schema 定义的名称和指定给 WSDL
定义的名称都在单独的符号空间中。
R2114
在
描述中， WSDL
定义的目标名称空间和 Schema 定义的目标名称空间
可以是相同的。WSDL12
5.3 消息
本概要的这一节引用了下列规范（或其中的章节）：
在 WSDL 1.1 中，
wsdl:message
元素用于表示传递的数据的抽象定义。它使用
wsdl:binding
元素来定义抽象定义如何绑定到特定的有线格式。本概要对
wsdl:message
元素以及符合概要的
wsdl:binding 元素可以如何使用
wsdl:message
元素提出了以下约束。
在本节中，以下定义用来使需求更紧凑、更容易理解。
“rpc-文字的绑定”是 wsdl:binding 元素，其子元素
wsdl:operation
都是 rpc-文字的操作。An "rpc-literal binding" is a wsdl:binding element whose child
wsdl:operation elements are all rpc-literal operations.
“rpc-文字的操作”是
wsdl:binding 的
wsdl:operation
子元素，它的所有
soapbind:body
后代元素都指定具有值“literal”的
use
属性，并且其中的每个元素或者：
- 指定具有值“rpc”的 style 属性；或者
- 是
soapbind:binding
元素的子元素，它指定具有值“rpc”的
style
属性，并且本身不包含指定的
style
属性。
“文档-文字的绑定”是
wsdl:binding
元素，它的子元素
wsdl:operation
都是文档-文字的操作。
“文档-文字的操作”是
wsdl:binding 的
wsdl:operation
子元素，它的所有
soapbind:body
后代元素都指定具有值“literal”的
use
属性，并且其中的每个元素或者：
- 指定具有值“document”的 style 属性；或者
- 是
soapbind:binding
元素的子元素，它指定具有值“document”的
style
属性，并且本身不包含指定的
style
属性；或者
- 是
soapbind:binding
元素的子元素，它不包含指定的
style
属性，并且本身不包含指定的
style
属性。
5.3.1 绑定和部分
关于文档-文字的绑定和 rpc-文字的绑定容许或需要多少
wsdl:part
元素和它们必须如何进行定义有多种解释。
R2201
描述中的文档 -文字的绑定
必须至多有一个在
parts
属性中列出的部分（如果
parts
属性是指定的话）。
R2210
如果
描述中的文档-文字的绑定没有在
soapbind:body 元素中指定
parts
属性，则相应的抽象
wsdl:message 就
必须定义零个或一个
wsdl:part s。
R2202
描述中的
wsdl:binding
可以包含
soapbind:body
元素来指定构成
soap:Body 的 zero 部分。
R2203
描述中的 rpc-文字的绑定在其
soapbind:body
元素中
必须只引用使用
type
属性定义的
wsdl:part 元素。
R2211
通过 rpc-文字的绑定描述的
消息绝不可以在部分访问器中包含具有值“1”或“true”的
xsi:nil
属性。
R2207
描述中的
wsdl:message
可以包含使用
elements 属性的
wsdl:part s，前提是这些
wsdl:part s
不是在 rpc-文字的绑定中由
soapbind:body 引用的。
R2204
描述中的文档-文字的绑定在其每个
soapbind:body
元素中
必须只引用使用
element
属性定义的
wsdl:part 元素。
R2208
描述中的绑定
可以包含
soapbind:header
元素，
soapbind:header 元素在由它的
soapbind:body 元素引用的相同
wsdl:message
中引用
wsdl:part s。
在文档样式中使用带有 zero 部分的
wsdl:message
元素是容许的，这使得操作可以发送或接收带有空的
soap:Body s 的消息。在 RPC
样式中使用带有 zero 部分的
wsdl:message
元素是容许的，这使得操作可以没有（有零个）参数和/或返回值。
对于文档-文字的绑定，本概要要求至多一个在
element
属性中抽象定义的部分序列化成
soap:Body
元素。
当
wsdl:part 元素是使用
type
属性定义的时，该部分的有线表示等同于具有值“1”的
minOccurs
属性的显式（XML Schema）限定、一个具有值“1”的
maxOccurs 属性和一个具有值“false”的
nillable
属性。
5.3.2 绑定和 Fault
描述
soapbind:fault 、
soapbind:header
和
soapbind:headerfault
的
wsdl:part
元素应该如何定义有多种解释。
R2205
描述中的
wsdl:binding
在其每个
soapbind:header 、
soapbind:headerfault
和
soapbind:fault 元素中都
必须只引用已经使用
element
属性定义的
wsdl:part
元素。
因为 Fault 和头不包含参数，所以
soapbind:fault 、
soapbind:header
和
soapbind:headerfault 根据 WSDL 1.1
假定
style 属性的值为“document”。R2204
要求所有包含值为“document”的
style
属性且绑定到
soapbind:body 的
wsdl:part
元素使用
element
属性进行定义。该需求对
soapbind:fault 、
soapbind:header
和
soapbind:headerfault 元素是一样的。
5.3.3 未绑定的 portType 元素内容
WSDL 1.1 并未显式规定
wsdl:binding
是否容许取消对未指定的
wsdl:portType
定义的内容部分的绑定。
R2209
描述中的
wsdl:binding
应该将
wsdl:portType
中的
wsdl:message 的每个
wsdl:part
绑定到它引用的
soapbind:body 、
soapbind:header 、
soapbind:fault
或
soapbind:headerfault 中的某一个。
portType
定义了带有一组命名的操作和相关联的抽象消息的抽象契约。虽然并未禁止，但是在使用 WSDL 1.1
第 3 节讨论的 SOAP 绑定时，如果有可能，希望将 portType
中指定的抽象输入、输出和 Fault
消息的每个部分都绑定到
soapbind:body 或
soapbind:header （及其他）。
5.3.4 声明 part 元素
WSDL 1.1 第 3.1 节中的示例 4 和 5
错误地展示了将 XML Schema 类型（例如“xsd:string”）用作
wsdl:part 元素的
element
属性的有效值。
R2206
描述中包含使用
element
属性的
wsdl:part 的
wsdl:message
必须在该属性中引用全局元素声明。
例如，
错误：
<message name="GetTradePriceInput">
<part name="tickerSymbol" element="xsd:string"/>
<part name="time" element="xsd:timeInstant"/>
</message> |
错误：
<message name="GetTradePriceInput">
<part name="tickerSymbol" element="xsd:string"/>
</message> |
正确：
<message name="GetTradePriceInput">
<part name="body" element="tns:SubscribeToQuotes"/>
</message> |
5.4 端口类型
本概要的这一节引用了下列规范（或其中的章节）：
在 WSDL 1.1 中，
wsdl:portType
元素用于建立一组抽象操作。本概要对符合概要的
wsdl:portType
元素提出以下约束条件：
5.4.1 part 元素的排序
容许使用
parameterOrder
有助于代码生成器方法签名和在线消息之间的映射。
R2301
消息的
soap:body
中的元素的顺序
必须与描述它的
wsdl:message 中的
wsdl:part s
的顺序相同。
R2302
描述可以使用
wsdl:operation 元素的
parameterOrder
属性来指示作为对代码生成器的提示的返回值和方法签名。
5.4.2 允许的操作
WSDL 1.1 并未明确地定义要求-响应（Solicit-Response）和通知（Notification）操作；此外，WSDL 1.1
还没有定义它们的绑定。
R2303
描述绝不可以在
wsdl:portType 定义中使用要求-响应（Solicit-Response）和通知（ Notification）类型的操作。
5.4.3 独特的操作
本概要不允许
wsdl:portType
中的操作名重载。
R2304
描述中的
wsdl:portType
必须包含其
name 属性具有独特的值的操作。
注意，这种需求只应用于特定
wsdl:portType 内的
wsdl:operation s。
wsdl:portType
可以有名称与在其他的
wsdl:portType s
中可以找到的名称相同的
wsdl:operation s。
5.4.4 parameterOrder 属性构造
WSDL 1.1 并未明确地规定
wsdl:portType
的
parameterOrder
属性应该如何构造。
R2305
必须构造
描述中的
wsdl:portType ，这样
parameterOrder
属性（如果有的话）就可以至多省略输出消息中的一个
wsdl:part 。
如果输出消息中的
wsdl:part 从
wsdl:part s
的列表中省略（它是
parameterOrder
属性的值），则这个省略的
wsdl:part
就是返回值。对返回值的类型没有限制。如果没有部分被省略，则没有返回值。
5.4.5 类型和元素属性的排他性
WSDL 1.1 并未明确规定不能同时指定
type
和
element
属性来定义
wsdl:message 中的
wsdl:part 。
R2306
描述中的
wsdl:message
绝不可以在相同的
wsdl:part
中同时指定
type 和
element
属性。
5.5 绑定
本概要的这一节引用了下列规范（或其中的章节）：
在 WSDL 1.1 中，
wsdl:binding 提供由特定
wsdl:portType
定义的操作和消息的具体协议和数据格式规范。本概要对符合概要的绑定规范提出以下约束条件：
5.5.1 SOAP 绑定的使用
本概要将绑定的选择限制为定义明确且最常使用的 SOAP
绑定。本概要不容许 MIME 和 HTTP GET/POST 绑定。
R2401
描述中的
wsdl:binding 元素
必须使用 WSDL 1.1
第 3 节定义的 WSDL SOAP 绑定。
注意，这对符合概要的
wsdl:binding
元素的构造提出了需求。它没有对作为一个整体的描述提出需求；特别地，它没有排除 WSDL
文档包含不遵循概要的
wsdl:binding
元素的可能性。
5.6 SOAP 绑定
本概要的这一节引用了下列规范（或其中的章节）：
WSDL 1.1 定义了 SOAP 1.1 端点的绑定。本概要要求使用 WSDL 1.1
中定义的 SOAP 绑定，并且对其使用提出了以下约束条件：
5.6.1 指定 transport 属性
WSDL 1.1 规范和 WSDL 1.1 Schema 之间关于
transport
属性存在不一致的地方。WSDL 1.1 规范需要它；而 WSDL 1.1
Schema 将其表示为可选的。
R2701
必须构造
描述中的
wsdl:binding
元素，这样它的
soapbind:binding
子元素就可以指定
transport 属性。
5.6.2 HTTP 传输
本概要将基础传输协议限制为 HTTP。
R2702
描述中的
wsdl:binding 元素
必须指定带有 SOAP
绑定的 HTTP 传输协议。具体来说，它的
soapbind:binding
子元素的
transport 属性
必须具有值“http://schemas.xmlsoap.org/soap/http”。
注意，这种需求并未禁止使用 HTTPS；参见 See
R5000。
5.6.3 style 属性的一致性
交互的样式（“文档”或“rpc”）是在
wsdl:operation 层指定的，允许
wsdl:binding s
的
wsdl:operation s
有不同的样式。这已经导致了互操作性问题。
R2705
描述中的
wsdl:binding
必须使用
rpc-文字的绑定或文档-文字的绑定。
5.6.4 编码和 use 属性
本概要禁止使用编码（包括 SOAP 编码在内）。
R2706
描述中的
wsdl:binding
必须使用“literal”值作为所有
soapbind:body 、
soapbind:fault 、
soapbind:header
和
soapbind:headerfault 元素的
use
属性。
5.6.5 use 属性的缺省值
WSDL 1.1 规范和 WSDL 1.1 Schema
之间在以下两个方面存在不一致的地方：
use
属性在
soapbind:body 、
soapbind:header
和
soapbind:headerfault
中是否是可选的；如果是这样，省略该属性意味着什么。
R2707
描述中包含一个或多个未指定
use
属性的
soapbind:body 、
soapbind:fault 、
soapbind:header
或
soapbind:headerfault 的
wsdl:binding
必须进行解释，好像在每种情况下都指定了值“literal”一样。
5.6.6 portType 元素的多个绑定
本概要明确容许相同 portType 的多个绑定。
R2709
描述中的
wsdl:portType
可以有零个或多个定义在相同或不同的 WSDL
文档中的引用它的
wsdl:binding s。
5.6.7 操作的有线签名
支持多个操作的端点必须明确地标识根据它接收的输入消息调用的操作。只有当与端点相关的
wsdl:binding
中指定的所有操作都有惟一的有线签名时，这才是有可能的。
R2710
描述中的
wsdl:binding
的操作
必须产生各自不同的有线签名。
本概要将操作的“有线签名”定义为全限定名，这种全限定名是它描述的 SOAP
输入消息的
soap:Body 的子元素。对于空
soap:Body 的情况，该名为空字符串。
在 rpc-文字的绑定的情况下，操作名用作部分访问器的包装器。在文档-文字的情况下，由于带有操作名的包装器不存在，所以必须正确地设计消息签名，以便它们满足这种需求。
5.6.8 端点上的多个端口
当去往同一网络端点上的两个不同的
wsdl:port s
的输入消息在线上难以分区时，确定它们调用的
wsdl:port
也许就是不可能的了。这可能会导致互操作性问题。然而，可能会存在需要定位一个端点上的多个端口的情况（例如
SOAP
版本控制、应用程序版本控制、不同概要的一致性）；因而本概要对此是允许的。
R2711
描述不应该有
soapbind:address
元素的
location 属性具有相同的值的多个
wsdl:port 。
5.6.9 文档-文字绑定的子元素
WSDL 1.1
并未十分明确地规定文档-文字样式的绑定中
soap:Body
的子元素是什么。
R2712
文档-文字的绑定
必须在线表示为带有
soap:Body 的
消息，
soap:Body
的子元素是相应的
wsdl:message
部分引用的全局元素声明的实例。
5.6.10 单向操作
在执行单向操作时如何使用 HTTP
有不同的解释。
R2714
对于单向操作，
实例绝不可以返回包含 SOAP
信封的 HTTP 响应。具体来说，HTTP
响应实体的主体必须为空。
R2750
消费者必须忽略在来自单向操作的响应中携带的 SOAP
响应。
R2727
对于单向操作，
消费者绝不可以将成功的 HTTP
响应状态码（即 2xx）解释为表示消息是有效的或接收者将处理它。
单向操作不产生 SOAP
响应。因此，本概要禁止发送 SOAP
信封来响应单向操作。这意味着单向操作的传输不会导致处理层响应或错误。例如，不会返回“500 Internal Server
Error”HTTP 响应，其中的 SOAP 消息包含 SOAP Fault
元素。
单向操作的 HTTP
响应指示消息传输的成功或失败。基于 HTTP
协议所支持的不同响应状态码的语义，本概要指定“200”和“202”作为发送者应该需要的首选状态码，用来表示单向消息已接收。成功的传输并不指示 SOAP
处理层和应用程序逻辑有机会验证消息或已将其提交以进行处理。
尽管存在 HTTP 1.1 给响应状态码“200”和“202”指定了不同的含义这样的事实，但是在本概要的上下文中，请求的启动者应该将它们看作是等同的。本概要之所以采用两个状态码，是因为一些 SOAP
实现对 HTTP
协议实现的控制非常少，并且不能控制发送这些响应状态码中的哪一个。
5.6.11 soapbind 元素的名称空间
关于什么名称空间与
soap:Envelope
的各个子元素的子元素相关联有些混乱。本概要定义了这些名称空间。
R2716
描述中的文档-文字的绑定
绝不可以有在所包含的
soapbind:body 、
soapbind:header 、
soapbind:headerfault
和
soapbind:fault 元素内指定的
namespace 属性。
R2717
描述中的 rpc-文字的绑定
必须有指定的
namespace
属性，其值必须是所包含的
soapbind:body 元素中的绝对 URI。
R2726
描述中的 rpc-文字的绑定
绝不可以有在所包含的
soapbind:header 、
soapbind:headerfault
和
soapbind:fault 元素中指定的
namespace
属性。
在文档-文字的 SOAP 绑定中，
soap:Body
的序列化子元素从定义该元素的 Schema 的 targetNamespace
中获取它的名称空间。使用
soapbind:body
元素的
namespace
属性将会覆盖该元素的名称空间。本概要不允许这样做。
相反地，在 rpc-文字的 SOAP 绑定中，
soap:Body
元素的序列化子元素包括 wrapper
元素，其名称空间是
soapbind:body
元素的
namespace
属性的值，而其本地名称或者是该操作的名称或者是前缀为“Response”的操作的名称。
namespace
属性是必需的而不是可选的，目的是确保
soap:Body
元素的子元素是名称空间限定的。
5.6.12 portType
和绑定元素的一致性
WSDL 描述在
wsdl:portType 和
wsdl:binding
层必须是一致的。
R2718
描述中的
wsdl:binding
必须有同一组
wsdl:operation s 作为它引用的
wsdl:portType 。C
5.6.13 描述 headerfault 元素
WSDL 规范文本和 WSDL Schema 之间关于
soapbind:headerfault s 有不一致的地方。
R2719
如果没有已知的头 Fault，
描述中的
wsdl:binding
可以不包含
soapbind:headerfault 元素。
WSDL 1.1 Schema 要求操作的
wsdl:input 和
wsdl:output
元素指定
soapbind:headerfault ，而 WSDL 1.1
将它们标记为可选的。该规范是正确的。
5.6.14 Fault 的枚举
Web 服务描述应该包括在定义服务时已知的所有
Fault。还需要容许生成在定义 Web
服务时还没有标识的新 Fault。
R2740
描述中的
wsdl:binding
应该包含描述每个已知的
Fault 的
soapbind:fault 。
R2741
描述中的
wsdl:binding
应该包含描述每个已知的头
Fault 的
soapbind:headerfault 。
R2742
消息可以包含相应的 WSDL 描述中的
wsdl:fault 元素没有描述的 SOAP Fault
内的 Fault 细节条目。
R2743
消息可以包含相应的 WSDL 描述中的
wsdl:headerfault
元素没有描述的 SOAP 头代码块内与头处理有关的 Fault
细节。
5.6.15 SOAP
绑定元素的类型和名称
WSDL 1.1 Schema 与 WSDL 1.1 规范关于
soapbind:header 和
soapbind:headerfault
元素的属性的名称和类型有不一致的地方。
R2720
描述中的
wsdl:binding
必须在所包含的全部
soapbind:header
和
soapbind:headerfault 元素中都使用 Schema
类型为“NMTOKEN”名为
part
的属性。
R2749
描述中的
wsdl:binding
绝不可以在所包含的
soapbind:header 和
soapbind:headerfault
元素中使用名为
parts
的属性。
WSDL Schema 给定该属性的名称为“parts”而类型为“NMTOKENS”。该 Schema
是错误的，因为每个
soapbind:header
和
soapbind:headerfault 元素都引用单个
wsdl:part 。
例如，
正确：
<binding name="StockQuoteSoap" type="tns:StockQuotePortType">
<soapbind:binding style="document"
transport="http://schemas.xmlsoap.org/soap/http"/>
<operation name="SubscribeToQuotes">
<input message="tns:SubscribeToQuotes">
<soapbind:body parts="body" use="literal"/>
<soapbind:header message="tns:SubscribeToQuotes"
part="subscribeheader" use="literal"/>
</input>
</operation>
</binding> |
5.6.16 Fault 中的 name 属性
WSDL 1.1 规范和 WSDL 1.1 Schema
之间有不一致的地方，WSDL 1.1 Schema 没有列出
name
属性。
R2721
描述中的
wsdl:binding
必须在所包含的全部
soapbind:fault
元素中都指定
name 属性。
R2754
在
描述中，
soapbind:fault
元素的
name 属性的值
必须与它的父
wsdl:fault
元素中的
name 属性的值相匹配。
5.6.17 use 属性的省略
WSDL 1.1 规范和 WSDL 1.1 Schema 之间关于
use 属性有不一致的地方。
R2722
描述中的
wsdl:binding
可以在所包含的
soapbind:fault 元素中指定
use 属性。C
R2723
如果
描述中的
wsdl:binding
所包含的
soapbind:fault 元素具有
use
属性，则它的值
必须为“literal”。
R2728
描述中在所包含的
soapbind:fault 元素内省略了
use
属性的
wsdl:binding
必须进行解释，就好像已经指定
use =“literal”一样。C
WSDL 1.1 第 3.6 节指出
soapbind:fault
的属性是必需的，而在该 Schema 中，
use
属性定义为可选的。本概要将其定义为可选的，以便与
soapbind:body 一致。
由于
use
属性是可选的，所以本概要在省略时为该属性标识缺省值。
最后，为了确保本概要是自相一致的，只容许
use
属性的值为“literal”。
5.6.18 消息与描述的一致性
这些需求规定，当实例接收不符合 WSDL
描述的消息时应该生成 Fault，除非实例不顾这种情况自己负责处理消息。
正如 SOAP 处理模型所规定的，（a）如果“Envelope”元素的名称空间是错误的，就必须生成“VersionMismatch”Fault
代码，（b）如果实例不理解
soap:mustUnderstand
属性值为“1”的 SOAP 头代码块，就必须生成“MustUnderstand”Fault。在所有其他消息与它的 WSDL
描述不一致的情况下，都应该生成带有“Client”Fault
代码的 Fault。
R2724
如果
实例接收到与它的 WSDL
描述不一致的消息，它就
应该生成带有“Client”Fault
代码的
soap:Fault ，除非生成了“MustUnderstand”或“VersionMismatch”Fault。
R2725
如果
实例接收到与它的
WSDL 描述不一致的消息，它就
必须依次检查“VersionMismatch”、“MustUnderstand”和“Client”Fault
条件。
5.6.19 响应包装器
WSDL 1.1 第 3.5 节可以解释为必须将 RPC 响应 wrapper
元素命名为等同于
wsdl:operation
的名称。
R2729
通过 rpc-文字的绑定描述的
消息（它是响应消息）
必须有 wrapper
元素，其名称是相应的
wsdl:operation
名称，前缀为字符串“Response”。
5.6.20 部分访问器的名称空间
对于 rpc-文字的 SOAP 消息，WSDL 1.1
并未明确规定参数和返回值的访问器元素是什么名称空间的一部分。不同的实现有不同的选择，这导致了互操作性的问题。
R2735
通过 rpc-文字的绑定描述的
消息必须把参数和返回值的部分访问器元素放在空名称空间中。
可选方案的稳定对于获得互操作性是至关重要的。本概要不把部分访问器元素放在名称空间中，因为这样做比较简单，包括了所有的情况，并且不会导致逻辑不一致的问题。
5.6.21
部分访问器元素的子元素的名称空间
对于 rpc-文字的 SOAP 消息，WSDL 1.1
并没有明确规定，当相应的抽象部分的定义为与该抽象部分的 WSDL
描述的
targetNamespace
不同的名称空间中的类型时，如何正确地限定部分访问器元素的子元素的名称空间。
R2737
对于具有定义其类型的 targetNamespace
的参数和返回值，通过 rpc-文字的绑定描述的
消息必须限定部分访问器元素的子元素的名称空间。
WSDL 1.1 第 3.5
节规定：“输入名称空间属性的所有部分名称、类型和值以进行编码，即便名称空间属性只应用于由抽象类型非显式定义的内容”。
然而，它并没有明确规定将抽象（complexType）类型的元素和属性内容的名称空间限定为定义这些元素和属性的 targetNamespace。WSDL 1.1
规定采用与 XML Schema
大致相同的方式。因而实现必须遵循与 XML Schema
相同的规则。如果采用具有
targetNamespace “B”的
Schema 的元素声明导入和引用了在
targetNamespace “A”中定义的 complexType，则该 complexType
的子元素的元素和属性内容将限定到名称空间“A”，而该元素将限定到名称空间“B”。
例如，
正确：
下面的 WSDL 在“http://example.org/foo/”名称空间中定义了一些
Schema，“http://example.org/foo/”名称空间在
wsdl:definitions
包含的
wsdl:types 部分，而
wsdl:definitions
包含具有“http://example.org/bar/”属性值的
wsdl:definitions （因而，其中的类型是在一个名称空间中声明的，而包含的元素是在另一个名称空间中定义的）：
<definitions xmlns="http://schemas.xmlsoap.org/wsdl/"
xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
xmlns:soapbind="http://schemas.xmlsoap.org/wsdl/soap/"
xmlns:http="http://schemas.xmlsoap.org/wsdl/http/"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:bar="http://example.org/bar/"
targetNamespace="http://example.org/bar/"
xmlns:foo="http://example.org/foo/">
<types>
<xsd:schema targetNamespace="http://example.org/foo/"
xmlns:tns="http://example.org/foo/"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
elementFormDefault="qualified"
attributeFormDefault="unqualified">
<xsd:complexType name="fooType">
<xsd:sequence>
<xsd:element ref="tns:bar"/>
<xsd:element ref="tns:baf"/>
</xsd:sequence>
</xsd:complexType>
<xsd:element name="bar" type="xsd:string"/>
<xsd:element name="baf" type="xsd:integer"/>
</xsd:schema>
</types>
<message name="BarMsg">
<part name="BarAccessor" type="foo:fooType"/>
</message>
<portType name="BarPortType">
<operation name="BarOperation">
<input message="bar:BarMsg"/>
</operation>
</portType>
<binding name="BarSOAPBinding" type="bar:BarPortType">
<soapbind:binding
transport="http://schemas.xmlsoap.org/soap/http/"
style="rpc"/>
<operation name="BarOperation">
<input message="bar:BarMsg">
<soapbind:body use="literal" namespace="http://example.org/bar/"/>
</input>
</operation>
</binding>
<service name="serviceName">
<port name="BarSOAPPort" binding="bar:BarSOAPBinding">
<soapbind:address location="http://example.org/myBarSOAPPort"/>
</port>
</service>
</definitions> |
最后所得到的 BarOperation 的 SOAP 消息如下：
<s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:foo="http://example.org/foo/">
<s:Header/>
<s:Body>
<m:BarOperation xmlns:m="http://example.org/bar/">
<BarAccessor>
<foo:bar>String</foo:bar>
<foo:baf>0</foo:baf>
</BarAccessor>
</m:BarOperation>
</s:Body>
</s:Envelope> |
5.6.22 必需的头
WSDL 1.1 并未明确规定，在传送时是否必须将 WSDL
描述的 SOAP 绑定部分中的
wsdl:operation 元素内的
wsdl:input
或
wsdl:output 元素中指定的所有
soapbind:header s
都包括在最后所得到的 SOAP 消息中。
R2738
消息必须包括在描述它的
wsdl:binding 的
wsdl:operation
内的
wsdl:input 或
wsdl:output
内指定的所有
soapbind:header s。
5.6.23 允许的未描述头
头是 SOAP 的可扩展性机制。由于种种原因， SOAP
消息可能需要包括没有在 WSDL 描述中定义的头。
R2739
消息可以包括没有在描述它的
wsdl:binding
中描述的 SOAP 头代码块。
R2753
没有在适当的
wsdl:binding 中描述的 SOAP
头代码块所包含的
消息可以具有在这样的 SOAP
头代码块中设置为“1”的属性。
5.6.24 头的排序
描述中的
soapbind:header s
的顺序和消息中的 SOAP
头代码块的顺序之间没有相关性。同样地，每个指定的 SOAP
头代码块的多个实例可以出现在消息中。
R2751
描述的
soapbind:binding
部分中的
soapbind:header 元素的顺序
必须认为是不依赖消息中的 SOAP
头代码块的顺序。
R2752
消息可以包含相应的描述中的
soapbind:binding
的适当子元素内每个
soapbind:header 元素的每个 SOAP
头代码块的多个实例。
5.6.25 描述 SOAPAction
互操作性测试表明，要求引用
SOAPAction HTTP
头字段-值增加了实现的互操作性。即使 HTTP
允许不引用头字段-值，但是一些实现还是要求引用该值。
对于处理器来说，
SOAPAction
纯粹是一种提示。所有关于消息的内容的重要信息都是在信封中携带的。
R2744
HTTP 请求
消息必须包含引用的值与
soapbind:operation
的
soapAction 属性的值相等的
SOAPAction HTTP
头字段（如果在相应的 WSDL 描述中，
soapbind:operation
的
soapAction 属性存在的话）。
R2745
HTTP 请求
消息必须包含具有引用的空字符串值的
SOAPAction HTTP
头字段（如果在相应的 WSDL 描述中，
soapbind:operation
的
soapAction
属性或者不存在，或者以空字符串作为它的值而存在）。
同时参阅 R1119 和相关的需求，以获得更多关于
SOAPAction 的讨论。
例如，
正确：
包含：
<soapbind:operation soapAction="foo" />
的 WSDL 描述会产生带有相应的 SOAPAction HTTP
头字段的消息，如下所示：
SOAPAction: "foo"
正确：
包含：
<soapbind:operation />
或
<soapbind:operation soapAction="" />
的 WSDL 描述会产生带有相应的 SOAPAction HTTP
头字段的消息，如下所示：
SOAPAction: ""
5.6.26 SOAP 绑定扩展
wsdl:required 属性被普遍误解了，有时，WSDL
作者会错误地使用该属性来指示
soapbind:header s
的可选性。按照 WSDL1.1 的规定，
wsdl:required
属性是针对 WSDL
处理器的可扩展性机制。它允许以优雅的方式引入新的
WSDL 扩展元素。
wsdl:required
的作用是通知 WSDL 处理器，是否需要由 WSDL
处理器来识别和理解扩展元素，以便正确地处理
WSDL 描述。按照规定，它不应该表示消息中包含的某些构造的条件性或可选性。例如，
soapbind:header
元素中具有“false”属性值的
wsdl:required
绝不可以解释为通知 WSDL 处理器，所描述的 SOAP
头代码块在从 WSDL
描述生成的消息中是有条件的或可选的。按照规定，它应该这样解释“为了发送消息到它描述的
soapbind:header 元素包括的端点，WSDL
处理器必须理解
soapbind:header
元素表示的语义”。
WSDL 1.1 SOAP
绑定扩展元素的
wsdl:required
属性的缺省值为“false”。大多数 WSDL
描述实际上并未在 SOAP 绑定扩展元素中指定
wsdl:required 属性，WSDL
处理器可能会将其解释为扩展元素可以忽略。本概要要求由消费者解释和处理所有的 WSDL SOAP 1.1
扩展，而不管扩展元素中是否存在
wsdl:required
属性或其值如何。
R2747
消费者必须理解和处理所有的 WSDL 1.1 SOAP
绑定扩展元素，而不管扩展元素中是否存在
wsdl:required
属性，也不管
wsdl:required
属性的值如何（如果存在的话）。
R2748
消费者绝不可以将
soapbind 扩展元素中存在属性值为“false”的
wsdl:required
解释为表示扩展元素在从 WSDL
描述生成的消息中是可选的。
5.7 XML Schema 的使用
本概要的这一节引用了下列规范（或其中的章节）：
WSDL 1.1 把 XML Schema 作为其类型系统之一。本概要要求将 XML
Schema 作为
Web 服务的 WSDL 描述的类型系统。
R2800
描述可以使用 XML Schema 1.0
中的构造。
R2801
描述必须将 XML Schema 1.0
推荐标准作为用户定义的数据类型和结构的基础。
6. 服务发布和发现
当需要发布或发现 Web 服务时，本概要采用 UDDI 作为描述 Web
服务提供者及其所提供的 Web 服务的机制。业务、计划使用和 Web
服务类型描述都采用 UDDI 术语；详细的技术描述采用 WSDL
术语。在两个规范定义重叠的描述数据和所用的两种描述形式的情况下，本概要规定这些描述绝不可以相冲突。
在 UDDI 注册中心中注册 Web
服务实例是可选的。在任何情况下，所有的使用场景都不要求 UDDI
提供元数据和发现的类型，但是在需要这样的功能的地方，UDDI
是获得认可的机制。
注意，构成 UDDI V2 的 Web 服务并不完全符合概要 1.0，因为根据该概要的需求，它们不接受同时用 UTF-8
和 UTF-16 编码的消息。（它们只接受
UTF-8）。存在这样的偏差应该是毫不奇怪的，因为 UDDI V2
是在该概要制订之前设计的，并且在许多情况下，也是在该概要制订之前实现的。UDDI
的设计人员意识到了 UDDI V2
的不一致性，并且将在以后的工作中对此加以考虑。
本概要的这一节通过引用了下列规范，并且定义了其中的可扩展性点：
6.1 bindingTemplates
本概要的这一节引用了下列规范（或其中的章节）：
UDDI 将 Web 服务实例表示为
uddi:bindingTemplate
元素。
uddi:bindingTemplate 的作用大致类似于
wsdl:port ，但是提供了不可以用 WSDL
表示的选项。为了保持实例的
WSDL 描述与它的 UDDI 描述的一致，本概要对可以如何构造
uddi:bindingTemplate
元素提出了以下约束条件。
WSDL 的
soapbind:address
元素要求直接指定实例的网址。相反，UDDI V2
提供了两种可选的方案来指定它它表示的实例的网址。一种方案的是，
uddi:accessPoint
通过直接指定地址来建立 WSDL
机制的镜像；另一种方案是，
uddi:hostingRedirector
提供基于 Web 服务的机制来解析地址，并且不与 WSDL
机制保持一致。
R3100
表示符合概要的
实例的
uddi:bindingTemplate
的
注册中心数据必须包含
uddi:accessPoint
元素。
例如，
错误：
<bindingTemplate bindingKey="...">
<description xml:lang="EN">BarSOAPPort</description>
<hostingRedirector bindingKey="..."/>
<tModelInstanceDetails>
...
</tModelInstanceDetails>
</bindingTemplate> |
正确：
<bindingTemplate bindingKey="...">
<description xml:lang="EN">BarSOAPPort</description>
<accessPoint>http://example.org/myBarSOAPPort</accessPoint>
<tModelInstanceDetails>
...
</tModelInstanceDetails>
</bindingTemplate> |
6.2 tModels
本概要的这一节引用了下列规范（或其中的章节）：
UDDI 将 Web 服务类型表示为
uddi:tModel
元素。（参见
UDDI
数据结构 第 8.1.1 节。）
这些元素可以但是不必（通过使用 URI）指向包含实际描述的文档。此外，UDDI
与用于描述 Web
服务类型的机制无关。之所以本概要不能与这种机制无关，是因为如果 Web
服务类型没有描述或可以采取多种形式进行描述，互操作性将非常复杂。
UDDI
API 规范，附录 I.1.2.1.1 允许但是不要求
uddi:tModel
元素使用 WSDL 来描述它们表示的 Web
服务类型，以便声明它们使用 WSDL
作为描述语言。不这样做会导致互操作性问题，因为这样一来，所使用的描述语言就是模糊的。
因此，本概要对可以如何构造
uddi:tModel
元素提出了以下约束条件。
本概要选择 WSDL
作为描述语言，因为它是迄今为止最广泛使用的这类语言。
R3002
表示符合概要的 Web 服务类型的
uddi:tModel
类型的
注册中心数据必须使用 WSDL
作为描述语言。
为了指定符合概要的 Web 服务类型使用 WSD，本概要采用
UDDI 类别来进行断言。
R3003
表示符合概要的 Web
服务类型的
uddi:tModel 类型的
注册中心数据必须使用 uddi:types
分类法和“wsdlSpec”类别进行分类。
对于
uddi:tModel 中的
uddi:overviewURL
解析为
wsdl:binding ，本概要必须采用约定来区分 WSDL
中的多个
wsdl:binding s。UDDI 最佳实践：在 UDDI
注册中心中使用 WSDL（Best Practice UDDI Best Practice for Using WSDL in a UDDI
Registry）指定了最广泛认可的这类约定。
R3010
表示符合概要的 Web 服务类型的
uddi:tModel
类型的
注册中心数据必须遵循
V1.08
of the UDDI Best Practice for Using WSDL in a UDDI Registry。
如果
uddi:tModel
引用的
wsdl:binding
不符合本概要，则它将是不一致的。
R3011
uddi:tModel 类型的
注册中心数据所引用的 wsdl:binding
本身
必须符合本概要。
7. 安全性
与所有面向网络的信息技术一样，安全性的主题对于 Web
服务也是至关重要的。对于 Web
服务以及其他信息技术，安全措施包括采取理解攻击者可能会发动的潜在威协并且应用可操作的物理和技术对策来将成功攻击的风险降低到可以接受的程度。因为“可接受的风险程度”随应用程序的不同而有很大的不同，并且实现对策的成本也有很大的变化，所以不可能有普遍适用的“正确答案”来保护 Web
服务的安全。选择绝对正确平衡的对策和可接受的风险只能在
Case by Case 的基础上才有可能做到。
经验表明，
有一些通用的对策模式可以将风险降低到许多 Web
服务可以接受的程度。本概要采用但是不要求使用其中最广泛使用的对策：采用 TLS 1.0
或 SSL 3.0 保护的（HTTPS）。也就是说，符合概要的 Web
服务可以使用 HTTPS，也可以使用其他的对策技术或根本就不使用这些技术。
普遍认为 HTTPS
是一个成熟的加密传输连接,可以提供基本的机密性。HTTPS
因而成为第一个也是最简单的实现许多现实世界中的 Web
服务应用程序所需的一些基本安全性特征。HTTPS
也可以用于通过使用客户端认证来提供客户端验证。
本概要的这一节引用了下列规范，并且定义了其中的可扩展性点：
7.1 HTTPS 的使用
HTTPS
是一种有效的得到广泛理解的基本安全性机制，本概要要求允许这种机制。
R5000
实例可以要求使用。
R5001
如果
实例要求使用 HTTPS，则它的
wsdl:port
描述中的
soapbind:address
元素的 location 属性就
必须是 Scheme 为“https”的
URI；要不然，它就必须是 Scheme 为“http”的 URI。
简单的 HTTPS 提供了由消费者验证 Web
服务的机制，而没有提供由实例验证消费者的机制。对于许多实例，这样做风险仍然太高，以致不能允许进行互操作。在本概要中包括 HTTPS
的互验证工具容许实例使用验证消费者的对策，这常常可以将风险降低到适当的程度，以便容许进行互操作。
R5010
实例可以要求使用 HTTPS
来进行相互验证。
附录 I: 引用的规范
除了由本概要取代的规范之外，本概要还引用了下列规范：
附录 II：可扩展性点
这一节标识了组成本概要的规范的可扩展性点，正如“概要的范围”中所定义的。
这些机制超出了本概要的范围；它们的使用可能影响互操作性，并且可能需要 Web
服务的各方之间的私有协定。
在
简单对象访问协议（Simple Object Access Protocol，SOAP）1.1
中：
-
头
代码块（Header blocks）—— 头代码块是 SOAP 中的基本可扩展性机制。
-
处理顺序（Processing order）—— SOAP 消息的组件（例如头）的处理顺序尚未指定，因而可能会需要额外协商。
-
中介的使用（Use of intermediaries）—— SOAP 中介是 SOAP 1.1 中尚未得以确认的机制，并且它们的使用可能会需要额外协商。它们的使用可能还需要仔细考虑在何处度量概要一致性。
-
soap:actor 值（soap:actor values）—— soap:actor 属性的值是 Web 服务各方之间的私有协定。
-
Fault 细节（Fault details）—— Fault 的 detail 元素的内容不由 SOAP 1.1 规定。
在
RFC2616：超文本传输协议（Hypertext Transfer Protocol）——
HTTP/1.1中：
-
HTTP 验证（HTTP Authentication）—— HTTP 验证允许采用扩展 Scheme、任意摘要哈希算法和参数。
-
未指定的头字段（Unspecified Header Fields）—— HTTP 允许任意头出现在消息中。
-
Expect 扩展（Expect-extensions）—— HTTP 中的 Expect/Continue 机制允许采用 Expect 扩展。
-
内容编码（Content-Encoding）—— HTTP 所允许的内容编码集尚未定型。
-
转换编码（Transfer-Encoding）—— HTTP 所允许的转换编码集尚未定型。
-
升级（Upgrade）—— HTTP 使得可以通过升级头（Upgrade header）将连接转换到任意协议。
在
Web 服务描述语言（Web Services Description Language，WSDL）1.1
中：
-
WSDL 扩展—— WSDL 允许在某些地方存在扩展元素；使用这样的扩展需要额外协商。
-
相关的 URI—— WSDL 并没有充分地指定相关 URI 的使用；它们的使用可能需要进一步的协调；请参见 XML Base 以了解更多的信息。
-
验证模式—— 不管用于读取 WSDL 和 XML Schema 文档的解析器是否执行 DTD 验证。
-
获取外部资源—— 不管用于读取 WSDL 和 XML Schema 文档的解析器是否获取外部实体和 DTD。
在
XML Schema
第一部分：结构中：
-
Schema 注解—— XML Schema 提供了注解，这可以用来传送关于数据结构的附加信息。
在
RFC2246：TLS 协议（版本
1.0）中：
-
TLS 密码包—— TLS 允许使用任意加密算法。
-
TLS 扩展TLS 允许握手阶段中的扩展。
在
SSL 协议（版本
3.0）中：
在
RFC2459: Internet X.509 Public Key Infrastructure Certificate and
CRL Profile中：
-
认证机构—— 认证机构的选择是各方之间的私有协定。
-
认证扩展—— X509 允许任意的认证扩展。
关于作者 | | | IBM has authored this article |
对本文的评价
| 
