WS-I 基本概要，版本 1.0a

文档选项

将此页作为电子邮件发送
最新推荐

Java 应用开发源动力 － 下载免费软件，快速启动开发
级别: 初级
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 服务的实例需要订立在其可用时以某种方式运行的契约。
实例必须由 WSDL 1.1 服务描述语言、UDDI 绑定模板或两者同时进行描述。
在此上下文中，“描述”意味着如果经授权的消费者请求符合概要的服务实例的服务描述，服务实例提供者就必须使 WSDL 文档、UDDI 绑定模板或两者可用于消费者。服务实例可以提供对服务器中的 WSDL 文档的运行时访问，但是为了被认为是符合概要，并不需要这样做。同样地，服务实例提供者可以在 UDDI 注册中心注册实例，但是为了被认为是符合概要，并不需要这样做。在所有这些场景中，WSDL 契约都必须存在，但是可能需要根据环境通过各种机制来进行使用。
一致性声明可以与特定的 WSDL 元素（例如 wsdl:portType ）相关联，这样就把它们包含在该构造的范围内。
描述可以包含关于实例的一致性声明，正如一致性声明 Schema 中所定义的。
描述的一致性声明 必须是下列每个元素的 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 如下：

例如，
正确：
... ...
随着本概要的新版本以及其他的概要的发行，服务有可能支持多个概要。当接收消息时，服务可能希望能够将概要确定为该消息符合的概要。为了使 SOAP 消息能够指示它们符合的概要，WS-I 规定用 wsi:Claim 元素作为 SOAP 头。
消息可以包含一致性声明，正如在一致性声明 Schema 中所指定的。
消息的一致性声明 必须作为 SOAP 头代码块来携带。
消息可以包含多个概要的一致性声明。
发送者在发送包含一致性声明的 SOAP 头代码块时 绝不可以使用 soap:mustUnderstand 属性。
SOAP 消息可以包含作为 SOAP 头代码块携带的一致性声明来向接受者指示发送者声明消息符合一个或多个概要。消息中缺少一致性声明绝不可以解释为暗示消息符合或不符合一个或多个概要。另外，一致性声明头代码块被认为是用于提供信息的，因此绝不可以作为强制性的头代码块。故本概要制止在一致性声明头代码块中使用 soap:mustUnderstand 属性。
例如，
正确：

注解描述以及概要的一致性声明的各种元素的方式对 uddi:tModel 元素同样是有效的。 UDDI 中用于给 uddi:tModel 添加属性的固有机制是定义和使用分类系统。本概要采用这种机制来给 uddi:tModel s 添加断言符合 WS-I 概要特别是本概要的能力。
声明符合概要的 uddi:tModel 类型的 注册中心数据必须使用 ws-i-org:conformsTo:2002_12 分类法进行分类。
声明符合概要的 uddi:tModel 类型的 注册中心数据必须使用对应于本概要的一致性声明的类别值 ws-i-org:conformsTo:2002_12。
注册中心数据必须通过添加 ws-i-org:conformsTo:2002_12 tModel 定义到其注册中心内容来支持 WS-I 一致性分类系统。
ws-i-org:conformsTo:2002_12 tModel 的 tModel 的内容如下：
ws-i-org:conformsTo:2002_12 Category system used for UDDI entities to point to the WS-I concept to which they conform to http://ws-i.org/schemas/conformanceClaim/
例如，
正确：
BarSOAPService Bar‘s SOAP Service ...
由于 wsdl:service 元素不必映射到单个 uddi:businessService ，并且还不受一致性声明的影响，所以如果 uddi:businessEntity 或 uddi:businessService 元素声明符合本概要，则 wsdl:service 元素的含义是不明确的。此外，不能对 uddi:bindingTemplate 元素进行分类，因为 UDDI V2 XML Schema 没有为它们提供 uddi:categoryBag 。因而， wsdl:port 元素所作的一致性声明不能包含在相应的 uddi:bindingTemplate 中。
不同于表示符合概要的 Web 服务类型的 uddi:tModel 元素 的 注册中心数据绝不可以使用 ws-i-org:conformsTo:2002_12 分类法和“http://ws-i.org/profiles/basic/1.0”分类类别来分类。
如果 uddi:tModel 所作的一致性声明与其使用的 wsdl:binding 所作的一致性声明不一致，则这种语义是模糊的。
必须构造 uddi:tModel 类型的 注册中心数据，这样它所作的一致性声明就会与其引用的 wsdl:binding 所作的一致性声明相一致。




回页首
本概要的这一节通过引用并入了下列规范，并且定义了这些规范中的可扩展性点：
简单对象访问协议（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 规定。
可扩展标记语言（Extensible Markup Language，XML）1.0（第二版）
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）将连接转换到任意协议。
RFC2965：HTTP 状态管理机制（State Management Mechanism）
在此规范的这一节中引用了下列规范（或其中的章节）：
SOAP 1.1，第 4 节
SOAP 1.1 为传递消息定义了一种基于 XML 的结构。本概要要求使用这种结构，并且对其使用提出了以下约束条件：
XML 1.0 允许 UTF-8 编码包括 BOM；因此，消息的接收者必须准备接受它们。对于按照 UTF-16 编码 XML，BOM 是强制性的。
接收者必须接受包括 Unicode 字节顺序标记（Byte Order Mark，BOM）。C
SOAP Fault 是一个 SOAP 消息，它包含 soap:Body 元素的一个子元素，这个元素就是 soap:Fault 元素。本概要将 soap:Fault 元素的内容限制为 SOAP 1.1 中描述的元素。
当 消息包含 soap:Fault 元素时，该元素 绝不可以有 faultcode 、 faultstring 、 faultactor 和 detail 之外的子元素。
例如，
错误：
soap:Client Invalid message format http://example.org/someactor There were lots of elements in the message that I did not understand Severe
正确：
soap:Client Invalid message format http://example.org/someactor There were lots of elements in the message that I did not understand Severe
soap:Fault 元素的子元素局限于该元素，因此名称空间限定是不必要的。
当 消息包含 soap:Fault 元素时，它的子元素 必须是未限定的。
例如，
错误：
soap:Client Invalid message format http://example.org/someactor There were lots of elements in the message that I did not understand
正确：
soap:Client Invalid message format http://example.org/someactor There were lots of elements in the message that I did not understand
为了可扩展性，允许附加属性出现在 detail 元素中，并且还允许附加元素作为 detail 元素的子元素出现。
接收者必须接受包含任何数目（包括零在内）作为 detail 元素的子元素出现的 的元素。这样的元素可以是限定的，也可以是未限定的。
接收者必须接受包含任何数目（包括零在内）出现在 detail 元素中的限定或未限定属性。限定属性的名称空间可以是不同于“http://schemas.xmlsoap.org/soap/envelope/”的任何名称空间。
faultstring 是人易读的描述，用于指示 Fault 的性质。同样地，它们不可以使用特定的语言，因此可以用 xml:lang 来指示 faultstring 的语言。
接收者必须在 faultstring 元素中带有 xml:lang 属性的 Fault 消息。
SOAP 1.1 通过使用“点”符号允许自定义 Fault 代码出现在 faultcode 元素中。
使用这种机制来扩展 SOAP 1.1 定义的 Fault 代码的含义可能会导致名称空间冲突。故应该避免它的使用，因为在通过右手边的“.”（点）使用相同的名称来传送不同的含义时这样做可能会导致互操作性问题。
而本概要鼓励使用 SOAP 1.1 中定义的 Fault 代码以及 detail 元素的附加信息来传送 Fault 的性质。
此外，在由指定机构控制的名称空间中定义自定义 Fault 代码也是可以接受的。
许多规范已经使用“.”（点）定义了自定义 Fault 代码。尽管如此，在未来的规范中，它们的使用是不鼓励的。
当 消息包含 faultcode 时，该元素的内容 应该是 SOAP 1.1 中定义的 Fault 代码之一或名称空间限定的 Fault 代码。
当 消息包含 faultcode 元素时，该元素的内容 不应该使用 SOAP 1.1 中的“.”（点）符号来重新定义 Fault 的含义。
推荐需要自定义 Fault 代码的应用程序或者使用 SOAP1.1 定义的 Fault 代码并且在 detail 元素中提供附加信息，或者在由指定机构控制的名称空间中定义这些代码。
例如，
错误：
soap:Server.ProcessingError An error occurred while processing the message
正确：
c:ProcessingError An error occured while processing the message
正确：
soap:Server An error occured while processing the message
soap:encodingStyle 属性用于指示在将数据编码到 XML 中时所用的特定 Scheme。然而，通过使用 XML 名称空间也可以提供这种功能。因此，本概要推荐使用文字的、非编码的 XML。
消息绝不可以在名称空间的名称为“ http://schemas.xmlsoap.org/soap/envelope/”的任何元素中包含 soap:encodingStyle 属性。
消息绝不可以 在 soap:Body 的任何子元素中包含 soap:encodingStyle 属性。
在 rpc-文字样式的绑定中描述的 消息绝不可以在 soap:Body 的任何孙子元素中包含 soap:encodingStyle 属性。
SOAP 消息中处理消息语义的开销和模糊的 XML DTD 和 PI 可能会引入安全性脆弱性。因此，这些 XML 构造不为 SOAP 1.1 的第 3 节所允许。
消息绝不可以包含文档类型声明（ Document Type Declaration） 。 C
消息绝不可以包含处理指令（Processing Instructions）。C
是否存在 XML 声明并不影响互操作性。某些实现可能总是在 XML 声明之前进行 XML 序列化。
接收者必须接受包含 XML 声明的消息。 C
soap:Body 元素之后的兄弟元素的解释是不清楚的。因此，不允许有这样的元素。
消息在 soap:Body 元素之后 绝不可以有 soap:Envelope 的任何子元素。
这种需求表明了 SOAP 1.1 规范和 SOAP 1.1 XML Schema 之间的不匹配。
例如，
错误：
Here is some data with the message
正确：
Here is some data with the message
为了促进互操作性，本概要要求所有的 XML 处理器都需要支持“UTF-8”和“UTF-16”字符编码。
由于这个缘故以及 SOAP 1.1 要求使用文本/xml 媒体类型（其缺省的字符编码为“us-ascii”）， charset 参数必须总是在 SOAP 信封的媒体类型中出现。同样是由于这个缘故，总是忽略消息中的 XML 声明的伪属性，以便合乎 XML 1.0 和 RFC3023 “XML 媒体类型” 的需求。
消息必须序列化为 UTF-8 或 UTF-16。
消息的信封的媒体类型 必须使用 charset 参数指示正确的字符编码。 C
当 SOAP 与 HTTP 绑定一起使用时，媒体类型是在 Content-Type HTTP 头字段中携带的。
soap:mustUnderstand 属性有限制型的“xsd:boolean”，它只接受“0”或“1”。因此，只有这两个值是允许的。
包含 soap:mustUnderstand 属性的 消息必须只使用词法形式的“0”和“1”。 C
未限定的元素名的使用可能会导致命名冲突，因此 soap:Body 的子元素必须使用限定名。
消息中的 soap:Body 元素的子元素 必须是名称空间限定的。
SOAP 1.1 声明，如果消息的 Envelope 元素的名称空间名不同于“http://schemas.xmlsoap.org/soap/envelope/”，则该消息应该丢弃。本概要要求改为生成 Fault 消息，以确保明确的操作。
如果 接收者遇到的消息的文档元素有局部名称“ Envelope”而其名称空间名不是“http://schemas.xmlsoap.org/soap/envelope/”，则他们 必须生成 Fault 消息。
在许多情况下，发送者和接收者将共享与交换的消息有关的某种形式的信息。只是在没有这样的 Schema 存在并且双方都假定所有的交换项都是“xsd:anyType”的情况下，才需要 xsi:type 属性。
接收者绝不可以要求在消息中使用 xsi:type 属性，除非是为了指示派生的类型而需要（参见 XML Schema 第一部分：结构（第 2.6.1 节））。
本概要的这一节引用下列规范（或其中的章节）：
SOAP 1.1，第 2 节
SOAP 1.1 为处理消息定义了消息交换模型。特别地，它定义了处理头代码块和消息体的规则。它还定义了与 Fault 的生成有关的规则。本概要对处理模型提出以下约束条件：
SOAP 1.1 关于处理强制性头代码块的处理机制是尚未得以确认的。强制性代码块是含有值为“1”的 soap:mustUnderstand 属性的 soap:Header 元素的子元素。
接收者必须以这样的方式处理消息，在任何实际的处理之前执行对强制性头代码块的所有检查。SOAP12
这种需求保证了在处理完消息的其他方之后不良的副作用将不会因注意到强制性头代码块而出现。
本概要要求接收者在遇到不理解的针对他们的头代码块时生成 Fault。
当消息包含针对接收者的强制性头代码块（即含有值为“ 1”的 soap:mustUnderstand 属性的元素）而接收者不理解时， 接收者必须生成“ soap:MustUnderstand” Fault。
当 Fault 生成时，就不应该再进行进一步的处理。在请求－响应交换中，Fault 消息将传送给请求消息的发送者，而某些应用程序级错误将显示给用户。
当 接收者生成 Fault 时，就 不应该再对 SOAP 消息进行进一步的处理，除了这种处理是回滚或补偿在生成 Fault 之前处理消息的任何影响所必需的以外。
在 SOAP 消息的正常输出将导致传送 SOAP 响应而不是改为生成 SOAP Fault 的情况下， 接收者必须传送 SOAP Fault 消息来代替响应。
如果可能，生成 SOAP Fault 的 接收者应该通过任何适于该环境的方式通知终端用户 SOAP Fault 已经生成。
本概要的这一节引用下列规范（或其中的章节）：
SOAP 1.1，第 6 节
HTTP/1.1
HTTP 状态管理机制（State Management Mechanism）
SOAP 1.1 为 HTTP 定义了一个协议绑定。本概要要求使用该绑定，并且对其使用提出以下约束条件：
定义了几个版本的 HTTP。HTTP/1.1 具有性能优势，并且与 HTTP/1.0 相比，指定更明确。
应该使用 HTTP/1.1 来发送 消息。
必须使用 HTTP/1.1 或 HTTP/1.0 来发送 消息。
注意，HTTP/1.1 中内含对 HTTP/1.0 的支持，并且中介可以更改消息的版本；要获得更多的关于 HTTP 版本的信息，可以参见 RFC2145 “HTTP 版本编号的使用和解释”。
一些消费者实现只使用 HTTP 状态码来确定 SOAP Fault 的出现。因为存在 Web 基础架构更改 HTTP 状态码的情况，并且为了获得更一般的可靠性，本概要要求它们检验信封。
接收者必须解释只包含 soap:Fault 元素作为 Fault 的 SOAP 消息。
SOAP1.1 规范定义了它的 HTTP 绑定，这样就可以使用两种可能的方法：HTTP POST 方法和 HTTP 扩展框架（HTTP Extension Framework）的 M-POST 方法。本概要要求只使用 HTTP POST 方法而把 HTTP 扩展框架的使用排除在外。
HTTP 请求 消息必须使用 HTTP POST 方法。
消息绝不可以使用 HTTP 扩展框架（RFC2774）。
HTTP 扩展框架是试验性的机制，用于以模块化的方式扩展 HTTP。因为它没有得到广泛部署，并且还因为它在使用 SOAP 方面的好处是不可靠的，所以本概要不允许使用它。
测试已经表明，需要引用 SOAPAction HTTP 头字段值提高了实现的互操作性。尽管 HTTP 允许未引用的头字段值，但是一些 SOAP 实现需要引用它们。
对于处理器而言， SOAPAction 纯粹是一个提示。所有关于消息的意图的重要信息都是在 soap:Envelope 中携带的。
HTTP 请求 消息中的 SOAPAction HTTP 头字段的值 必须是引用字符串。C
如果 SOAPAction HTTP 头字段的值不是引用的，则 接收者可以以 Fault 进行响应。C
例如，
正确：
含有：

的 WSDL 描述会产生带有如下 SOAPAction HTTP 头字段的消息：
SOAPAction: "foo"
正确：
含有：

或

的 WSDL 描述会产生带有如下相应的 SOAPAction HTTP 头字段的消息：
SOAPAction: ""
SOAP 设计成能利用 HTTP 基础架构的优势。然而，在有些情况下（例如，包括代理、防火墙或其他中介），可能会存在有害的副作用。因此，实例可能会发现使用 HTTP 的缺省端口（端口 80）之外的端口是可取的。
实例可以接受 TCP 端口 80（HTTP）上的连接。C
在 W3C 和 IETF 内部，关于适当地使用绑定到 HTTP 的 SOAP 消息的端口 80 有相当多的争论。最后得出的结论是，这是一个可以接受的惯例。
HTTP 使用 2xx 序列状态码来显示成功。特别地，200 是成功消息的缺省状态码，而 202 可以用来指示消息已经提交供处理。另外，其他的 2xx 状态码也可能是适当的，这取决于 HTTP 交互的性质。
实例必须使用 2xx HTTP 状态码作为指示请求的成功输出的响应。
实例应该使用“ 200 OK” HTTP 状态码作为包含非 SOAP Fault 的 SOAP 消息的响应。
实例应该使用“ 200 OK”或“ 202 Accepted”状态码作为不包含 SOAP 消息但是指示请求的成功 HTTP 输出的响应。
使用许多 HTTP 状态码会产生互操作性问题，这些问题通常表现在是否使用原始方法或 GET 方面。本概要要求将“307 Temporary Redirect”作为正确的重定向状态码。要了解更多的信息，请参见 RFC2616 中描述的 3xx 状态码。
实例在将请求重定向到不同的端点时 必须使用 HTTP 状态码“307 Temporary Redirect”。
消费者在遇到响应中的“ 307 Temporary Redirect” HTTP 状态码时 可以自动重定向请求。
RFC2616 指出，用户代理不应该自动重定向请求；然而，这种需求针对的是浏览器而不是自动流程（许多 Web 服务将是这样的）。因此，本概要允许但是不要求消费者自动遵循重定向。
HTTP 使用 4xx 系列的状态码来指示因客户端错误而导致的失败。虽然有许多情况可能会产生这样的代码，但本概要强调的是 HTTP 请求的有效负载不是正确的媒体类型（即 SOAP/HTTP 绑定所需的“文本/xml”）以及没有使用预期的方法。
实例必须使用 4xx HTTP 状态码作为指示请求的格式问题的响应。
如果请求信息是畸形的 HTTP 请求或不是结构良好的 XML，则 实例应该使用“400 Bad Request”HTTP 状态码。
如果请求方法不是“ POST”，则 实例应该使用“405 Method not Allowed” HTTP 状态码。
如果 Content-Type HTTP 请求头不含有与为输入消息的相应绑定指定的值相一致的值，则 实例应该使用“415 Unsupported Media Type”HTTP 状态码。
注意，这些需求并不强制要求实例响应请求。在某些情况下（比如拒绝服务（Denial of Service）攻击），实例可以选择忽略请求。
HTTP 使用 5xx 序列码来指示因服务器错误而导致的失败。
如果响应消息是 SOAP Fault，则 实例必须使用“500 Internal Server Error”HTTP 状态码。
HTTP 状态管理机制（“Cookies”）允许创建 Web 浏览器和服务器之间的有状态会话。由于是为超文本浏览而设计的，所以 Cookies 并没有定义明确的 Web 服务语义，并且因为它们相对于 SOAP 信封是外部的，所以 SOAP 1.1 或 WSDL 1.1 都没有附带。然而，在有些情况下使用 Cookies 是必需的，例如，在服务器之间的负载平衡和遗留系统的集成中使用 Cookies。由于这些原因，本概要限制使用 Cookies 的方式，而没有完全禁止它们。
实例可以使用 HTTP 状态机制（“Cookies”）。
使用 Cookies 的 实例应该符合 RFC2965。
实例不应该为了正确地运行而要求支持 Cookies。
Cookies 的值 必须认为是对 消费者不透明的。
本概要推荐实例不要为了正确地运行而使用 Cookies；它们应该是用于最优化的提示，而并不显著地影响 Web 服务的执行。然而在遗留系统集成和其他的特殊用况中，它们可能是必需的，所以需要它们并没有使实例变得不符合概要。虽然 Cookies 因而对实例有意义，但是它们不应该用作实例和消费者之间的额外数据通道。因此，Cookies 的解释根本不为消费者所允许——消费者需要把它们看作是不透明的（即对消费者没有意义）。




回页首
本概要采用的是 Web 服务描述语言（Web Services Description Language，WSDL），这使得可以将服务描述成对消息进行处理的端点集。
本概要的这一节通过引用并入了以下规范，并且定义了其中的可扩展性点：
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 提供了注解，这可以用来传送关于数据结构的附加信息。
XML Schema 第二部分：数据类型
本概要的这一节引用了以下规范（或其他的章节）：
WSDL 1.1，第 2.1 节
WSDL 1.1 为描述 Web 服务定义了基于 XML 的结构。本概要要求使用这种结构，并且对其使用提出以下约束条件：
WSDL 1.1 规范的附录 4 中 WSDL 的标准化 Schema 与该规范的标准化文本有矛盾的地方。本概要引用的是新的 Schema 文档，其中修改了已知的错误。
根据“ http://schemas.xmlsoap.org/wsdl/2003-02-11.xsd”中的 XML Schema，使用 WSDL 名称空间（在本概要中其前缀为“wsdl”）的 描述必须是有效的。
根据“http://schemas.xmlsoap.org/wsdl/2003-02-11.xsd”中的 XML Schema，使用 WSDL SOAP 绑定名称空间（在本概要中其前缀为“soapbind”）的 描述必须是有效的。
虽然本概要要求 WSDL 描述是 Schema 有效的，但是它并不要求消费者验证 WSDL 文档。而由 WSDL 文档的作者确保它是 Schema 有效的。
WSDL 1.1 中的一些示例错误地展示了用于导入 XML Schema 定义的 WSDL 导入声明。本概要说明了导入机制的使用，以便保证它们是一致的并且被限制到它们各自的域中。导入的 Schema 需求也通过 XML 版本和与这些导入 WSDL 文档一致的编码需求加以约束。
描述必须只使用 WSDL“导入”语句来导入另一个 WSDL 描述。
要导入 XML Schema 定义， 描述必须使用 XML Schema“导入”语句。
描述必须只使用类型章节的 xsd:schema 元素中的 XML Schema“导入”语句。
描述绝不可以使用 XML Schema“导入”语句来从根元素不是名称空间“http://www.w3.org/2001/XMLSchema”中的“Schema”的任何文档导入 Schema。
由 描述直接或间接导入的 XML Schema 可以包括 Unicode 字节顺序标记（Byte Order Mark，BOM）。
由 描述直接或间接导入的 XML Schema 必须使用 UTF-8 或 UTF-16 编码。
由 描述直接或间接导入的 XML Schema 必须使用可扩展标记语言 W3C 推荐标准（eXtensible Markup Language W3C Recommendation）的版本 1.0。
例如，
错误：
...
正确：
...
正确：
...
WSDL 1.1 并未明确规定 wsdl:import 语句是否需要 location 属性或其必需的内容。
描述必须在 wsdl:import 元素中指定非空的 location 属性。
虽然 wsdl:import 语句是模仿 xsd:import 语句，但是 location 属性是 wsdl:import 所必需的，而 xsd:import 中的相应属性 schemaLocation 是可选的。与 location 一致是必需的，其内容规定为非空。
WSDL 1.1 并未明确规定 WSDL 处理器是否必须实际检索和处理来自它遇到的 wsdl:import 语句的 location 属性指定的 URI 中的 WSDL 文档。
对 wsdl:import 元素的 location 属性值的 描述应该看作是提示。C
这意味着 WSDL 元素可以但是却不需要检索来自 wsdl:import 元素的 location 属性指定的 URI 中的 WSDL 描述，因为 WSDL 处理器可能会有其他的方式来定位特定名称空间的 WSDL 描述。例如，它可能已经有缓存的或内置的表示，或者它可能检索来自元数据存储库或 UDDI 服务器检索中的表示。
WSDL 1.1 第 3.1 节中的示例 3 会导致关于 wsdl:import 的位置的混乱。
当 wsdl:import 元素出现在 描述中时，它们 必须在所有来自 WSDL 名称空间的其他元素（ wsdl:documentation 除外）之前。
当 wsdl:types 元素出现在 描述中时，它们 必须在所有来自 WSDL 名称空间的其他元素（ wsdl:documentation 和 wsdl:import 除外）之前。
例如，
错误：
... .... .......
正确：
...
正确：
....... ... ....
WSDL 1.1 和 XML Schema 1.0 都不要求特定版本的 XML。出于互操作性的原因，用 XML 表示的 WSDL 文档及其导入的 Schema 必须使用版本 1.0。
描述必须使用可扩展性标记语言 W3C 推荐标准（eXtensible Markup Language W3C Recommendation）的 1.0 版。
XML 1.0 允许文档使用 UTF-8 字符编码来包括 BOM；因此，描述处理器必须准备接受它们。
描述可以包括 Unicode 字节顺序标记（Byte Order Mark，BOM）。C
本概要一贯地要求 SOAP 和 WSDL 使用 UTF-8 或 UTF-16 编码（同时参阅 R1012）。
描述必须使用 UTF-8 或 UTF-16 编码。
本概要不允许 wsdl:import 中的名称空间强制。
导入描述的 wsdl:definitions 元素的 targetNamespace 属性 必须具有与导入 描述的 wsdl:import 元素中的 namespace 属性相同的值。
WSDL 1.1 Schema 和 WSDL 1.1 规范对于 wsdl:documentation 元素的位置是不一致的。
wsdl:documentation 元素 可以作为 描述中的 wsdl:import 元素的子元素而出现。WSDL12
wsdl:documentation 元素 可以作为 描述中的 wsdl:part 元素的子元素而出现。WSDL12
wsdl:documentation 元素 可以作为 描述中的 wsdl:definitions 元素的第一个子元素而出现。WSDL12
需要支持这个或另外的 WS-I 概要没有显式指定的 WSDL 扩展可能会导致还无法理解这些扩展的开发工具的互操作性问题。
包含 WSDL 扩展的 描述绝不可以使这些扩展与本概要的其他需求相抵触。
描述不应该包括声明符合本概要的任何 WSDL 构造（ wsdl:binding 、 wsdl:portType 、 wsdl:message 、 wsdl:types 或 wsdl:import ）中 wsdl:required 的属性值为“true”的扩展元素。
如果在处理描述中的 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
本概要的这一节引用了下列规范（或其中的章节）：
WSDL 1.1，第 2.2 节
WSDL 1.1 的 wsdl:types 元素封闭了与所描述的 Web 服务有关的数据类型定义。本概要对 WSDL 元素引用来进行概要一致性声明的 wsdl:types 元素的这些内容提出了以下约束条件：
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 引用。
描述绝不可以使用指向既没有导入又没有在引用的 WSDL 文档中定义的名称空间中的元素的 QName 引用。
指向 描述中的 Schema 组件的 QName 引用 必须使用在 xsd:schema 元素的 targetNamespace 属性中定义的名称空间或在 xsd:schema 元素内的 xsd:import 元素的 namespace 属性中定义的名称空间。
要求 wsdl:types 的所有子元素都具有 targetNamespace 属性是一种良好的习惯做法，这将 WSDL 文档的作者的负担减少到最低限度，并且避免了没有尽可能地明确定义的情况。
描述中的 wsdl:types 元素所包含的全部 xsd:schema 元素 必须包含具有有效和非零的值的 targetNamespace 属性， 除非 xsd:schema 元素有 xsd:import 和/或 xsd:annotation 作为其惟一的子元素。
在 WSDL 1.1 第 2.2 节中的关于声明数组类型的建议已经存在几种解释方式，这导致了互操作性问题。此外，还有一些其他的方式可以更明确地声明数组。
在 描述中，数组声明 绝不可以扩展或限制 soapenc:Array 类型。
在 描述中，数组声明 绝不可以在类型声明中使用 wsdl:arrayType 属性。
在 描述中，数组声明 wrapper 元素 不应该使用约定 ArrayOfXXX 进行命名。
包含序列化数组的 消息绝不可以包含 soapenc:arrayType 属性。
例如，
错误：
Given the WSDL Description:

该 SOAP 消息将序列化为（为了清楚起见，略去了名称空间声明）：
abcd efgh
正确：
给定如下 WSDL 描述：

SOAP 消息将序列化为（为了清楚起见，略去了名称空间声明）：
abcd efgh
由 Schema 定义的名称和指定给 WSDL 定义的名称都在单独的符号空间中。
在 描述中， WSDL 定义的目标名称空间和 Schema 定义的目标名称空间 可以是相同的。WSDL12
本概要的这一节引用了下列规范（或其中的章节）：
WSDL 1.1，第 2.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 属性。
关于文档-文字的绑定和 rpc-文字的绑定容许或需要多少 wsdl:part 元素和它们必须如何进行定义有多种解释。
描述中的文档 -文字的绑定 必须至多有一个在 parts 属性中列出的部分（如果 parts 属性是指定的话）。
如果 描述中的文档-文字的绑定没有在 soapbind:body 元素中指定 parts 属性，则相应的抽象 wsdl:message 就 必须定义零个或一个 wsdl:part s。
描述中的 wsdl:binding 可以包含 soapbind:body 元素来指定构成 soap:Body 的 zero 部分。
描述中的 rpc-文字的绑定在其 soapbind:body 元素中 必须只引用使用 type 属性定义的 wsdl:part 元素。
通过 rpc-文字的绑定描述的 消息绝不可以在部分访问器中包含具有值“1”或“true”的 xsi:nil 属性。
描述中的 wsdl:message 可以包含使用 elements 属性的 wsdl:part s，前提是这些 wsdl:part s 不是在 rpc-文字的绑定中由 soapbind:body 引用的。
描述中的文档-文字的绑定在其每个 soapbind:body 元素中 必须只引用使用 element 属性定义的 wsdl:part 元素。
描述中的绑定 可以包含 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 属性。
描述 soapbind:fault 、 soapbind:header 和 soapbind:headerfault 的 wsdl:part 元素应该如何定义有多种解释。
描述中的 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 元素是一样的。
WSDL 1.1 并未显式规定 wsdl:binding 是否容许取消对未指定的 wsdl:portType 定义的内容部分的绑定。
描述中的 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 （及其他）。
WSDL 1.1 第 3.1 节中的示例 4 和 5 错误地展示了将 XML Schema 类型（例如“xsd:string”）用作 wsdl:part 元素的 element 属性的有效值。
描述中包含使用 element 属性的 wsdl:part 的 wsdl:message 必须在该属性中引用全局元素声明。
例如，
错误：

错误：

正确：

本概要的这一节引用了下列规范（或其中的章节）：
WSDL 1.1，第 2.4 节
在 WSDL 1.1 中， wsdl:portType 元素用于建立一组抽象操作。本概要对符合概要的 wsdl:portType 元素提出以下约束条件：
容许使用 parameterOrder 有助于代码生成器方法签名和在线消息之间的映射。
消息的 soap:body 中的元素的顺序 必须与描述它的 wsdl:message 中的 wsdl:part s 的顺序相同。
描述可以使用 wsdl:operation 元素的 parameterOrder 属性来指示作为对代码生成器的提示的返回值和方法签名。
WSDL 1.1 并未明确地定义要求-响应（Solicit-Response）和通知（Notification）操作；此外，WSDL 1.1 还没有定义它们的绑定。
描述绝不可以在 wsdl:portType 定义中使用要求-响应（Solicit-Response）和通知（ Notification）类型的操作。
本概要不允许 wsdl:portType 中的操作名重载。
描述中的 wsdl:portType 必须包含其 name 属性具有独特的值的操作。
注意，这种需求只应用于特定 wsdl:portType 内的 wsdl:operation s。 wsdl:portType 可以有名称与在其他的 wsdl:portType s 中可以找到的名称相同的 wsdl:operation s。
WSDL 1.1 并未明确地规定 wsdl:portType 的 parameterOrder 属性应该如何构造。
必须构造 描述中的 wsdl:portType ，这样 parameterOrder 属性（如果有的话）就可以至多省略输出消息中的一个 wsdl:part 。
如果输出消息中的 wsdl:part 从 wsdl:part s 的列表中省略（它是 parameterOrder 属性的值），则这个省略的 wsdl:part 就是返回值。对返回值的类型没有限制。如果没有部分被省略，则没有返回值。
WSDL 1.1 并未明确规定不能同时指定 type 和 element 属性来定义 wsdl:message 中的 wsdl:part 。
描述中的 wsdl:message 绝不可以在相同的 wsdl:part 中同时指定 type 和 element 属性。
本概要的这一节引用了下列规范（或其中的章节）：
WSDL 1.1，第 2.5 节
在 WSDL 1.1 中， wsdl:binding 提供由特定 wsdl:portType 定义的操作和消息的具体协议和数据格式规范。本概要对符合概要的绑定规范提出以下约束条件：
本概要将绑定的选择限制为定义明确且最常使用的 SOAP 绑定。本概要不容许 MIME 和 HTTP GET/POST 绑定。
描述中的 wsdl:binding 元素 必须使用 WSDL 1.1 第 3 节定义的 WSDL SOAP 绑定。
注意，这对符合概要的 wsdl:binding 元素的构造提出了需求。它没有对作为一个整体的描述提出需求；特别地，它没有排除 WSDL 文档包含不遵循概要的 wsdl:binding 元素的可能性。
本概要的这一节引用了下列规范（或其中的章节）：
WSDL 1.1，第 3.0 节
WSDL 1.1 定义了 SOAP 1.1 端点的绑定。本概要要求使用 WSDL 1.1 中定义的 SOAP 绑定，并且对其使用提出了以下约束条件：
WSDL 1.1 规范和 WSDL 1.1 Schema 之间关于 transport 属性存在不一致的地方。WSDL 1.1 规范需要它；而 WSDL 1.1 Schema 将其表示为可选的。
必须构造 描述中的 wsdl:binding 元素，这样它的 soapbind:binding 子元素就可以指定 transport 属性。
本概要将基础传输协议限制为 HTTP。
描述中的 wsdl:binding 元素 必须指定带有 SOAP 绑定的 HTTP 传输协议。具体来说，它的 soapbind:binding 子元素的 transport 属性 必须具有值“http://schemas.xmlsoap.org/soap/http”。
注意，这种需求并未禁止使用 HTTPS；参见 See R5000。
交互的样式（“文档”或“rpc”）是在 wsdl:operation 层指定的，允许 wsdl:binding s 的 wsdl:operation s 有不同的样式。这已经导致了互操作性问题。
描述中的 wsdl:binding 必须使用 rpc-文字的绑定或文档-文字的绑定。
本概要禁止使用编码（包括 SOAP 编码在内）。
描述中的 wsdl:binding 必须使用“literal”值作为所有 soapbind:body 、 soapbind:fault 、 soapbind:header 和 soapbind:headerfault 元素的 use 属性。
WSDL 1.1 规范和 WSDL 1.1 Schema 之间在以下两个方面存在不一致的地方： use 属性在 soapbind:body 、 soapbind:header 和 soapbind:headerfault 中是否是可选的；如果是这样，省略该属性意味着什么。
描述中包含一个或多个未指定 use 属性的 soapbind:body 、 soapbind:fault 、 soapbind:header 或 soapbind:headerfault 的 wsdl:binding 必须进行解释，好像在每种情况下都指定了值“literal”一样。
本概要明确容许相同 portType 的多个绑定。
描述中的 wsdl:portType 可以有零个或多个定义在相同或不同的 WSDL 文档中的引用它的 wsdl:binding s。
支持多个操作的端点必须明确地标识根据它接收的输入消息调用的操作。只有当与端点相关的 wsdl:binding 中指定的所有操作都有惟一的有线签名时，这才是有可能的。
描述中的 wsdl:binding 的操作 必须产生各自不同的有线签名。
本概要将操作的“有线签名”定义为全限定名，这种全限定名是它描述的 SOAP 输入消息的 soap:Body 的子元素。对于空 soap:Body 的情况，该名为空字符串。
在 rpc-文字的绑定的情况下，操作名用作部分访问器的包装器。在文档-文字的情况下，由于带有操作名的包装器不存在，所以必须正确地设计消息签名，以便它们满足这种需求。
当去往同一网络端点上的两个不同的 wsdl:port s 的输入消息在线上难以分区时，确定它们调用的 wsdl:port 也许就是不可能的了。这可能会导致互操作性问题。然而，可能会存在需要定位一个端点上的多个端口的情况（例如 SOAP 版本控制、应用程序版本控制、不同概要的一致性）；因而本概要对此是允许的。
描述不应该有 soapbind:address 元素的 location 属性具有相同的值的多个 wsdl:port 。
WSDL 1.1 并未十分明确地规定文档-文字样式的绑定中 soap:Body 的子元素是什么。
文档-文字的绑定 必须在线表示为带有 soap:Body 的 消息， soap:Body 的子元素是相应的 wsdl:message 部分引用的全局元素声明的实例。
在执行单向操作时如何使用 HTTP 有不同的解释。
对于单向操作， 实例绝不可以返回包含 SOAP 信封的 HTTP 响应。具体来说，HTTP 响应实体的主体必须为空。
消费者必须忽略在来自单向操作的响应中携带的 SOAP 响应。
对于单向操作， 消费者绝不可以将成功的 HTTP 响应状态码（即 2xx）解释为表示消息是有效的或接收者将处理它。
单向操作不产生 SOAP 响应。因此，本概要禁止发送 SOAP 信封来响应单向操作。这意味着单向操作的传输不会导致处理层响应或错误。例如，不会返回“500 Internal Server Error”HTTP 响应，其中的 SOAP 消息包含 SOAP Fault 元素。
单向操作的 HTTP 响应指示消息传输的成功或失败。基于 HTTP 协议所支持的不同响应状态码的语义，本概要指定“200”和“202”作为发送者应该需要的首选状态码，用来表示单向消息已接收。成功的传输并不指示 SOAP 处理层和应用程序逻辑有机会验证消息或已将其提交以进行处理。
尽管存在 HTTP 1.1 给响应状态码“200”和“202”指定了不同的含义这样的事实，但是在本概要的上下文中，请求的启动者应该将它们看作是等同的。本概要之所以采用两个状态码，是因为一些 SOAP 实现对 HTTP 协议实现的控制非常少，并且不能控制发送这些响应状态码中的哪一个。
关于什么名称空间与 soap:Envelope 的各个子元素的子元素相关联有些混乱。本概要定义了这些名称空间。
描述中的文档-文字的绑定 绝不可以有在所包含的 soapbind:body 、 soapbind:header 、 soapbind:headerfault 和 soapbind:fault 元素内指定的 namespace 属性。
描述中的 rpc-文字的绑定 必须有指定的 namespace 属性，其值必须是所包含的 soapbind:body 元素中的绝对 URI。
描述中的 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 元素的子元素是名称空间限定的。
WSDL 描述在 wsdl:portType 和 wsdl:binding 层必须是一致的。
描述中的 wsdl:binding 必须有同一组 wsdl:operation s 作为它引用的 wsdl:portType 。C
WSDL 规范文本和 WSDL Schema 之间关于 soapbind:headerfault s 有不一致的地方。
如果没有已知的头 Fault， 描述中的 wsdl:binding 可以不包含 soapbind:headerfault 元素。
WSDL 1.1 Schema 要求操作的 wsdl:input 和 wsdl:output 元素指定 soapbind:headerfault ，而 WSDL 1.1 将它们标记为可选的。该规范是正确的。
Web 服务描述应该包括在定义服务时已知的所有 Fault。还需要容许生成在定义 Web 服务时还没有标识的新 Fault。
描述中的 wsdl:binding 应该包含描述每个已知的 Fault 的 soapbind:fault 。
描述中的 wsdl:binding 应该包含描述每个已知的头 Fault 的 soapbind:headerfault 。
消息可以包含相应的 WSDL 描述中的 wsdl:fault 元素没有描述的 SOAP Fault 内的 Fault 细节条目。
消息可以包含相应的 WSDL 描述中的 wsdl:headerfault 元素没有描述的 SOAP 头代码块内与头处理有关的 Fault 细节。
WSDL 1.1 Schema 与 WSDL 1.1 规范关于 soapbind:header 和 soapbind:headerfault 元素的属性的名称和类型有不一致的地方。
描述中的 wsdl:binding 必须在所包含的全部 soapbind:header 和 soapbind:headerfault 元素中都使用 Schema 类型为“NMTOKEN”名为 part 的属性。
描述中的 wsdl:binding 绝不可以在所包含的 soapbind:header 和 soapbind:headerfault 元素中使用名为 parts 的属性。
WSDL Schema 给定该属性的名称为“parts”而类型为“NMTOKENS”。该 Schema 是错误的，因为每个 soapbind:header 和 soapbind:headerfault 元素都引用单个 wsdl:part 。
例如，
正确：

WSDL 1.1 规范和 WSDL 1.1 Schema 之间有不一致的地方，WSDL 1.1 Schema 没有列出 name 属性。
描述中的 wsdl:binding 必须在所包含的全部 soapbind:fault 元素中都指定 name 属性。
在 描述中， soapbind:fault 元素的 name 属性的值 必须与它的父 wsdl:fault 元素中的 name 属性的值相匹配。
WSDL 1.1 规范和 WSDL 1.1 Schema 之间关于 use 属性有不一致的地方。
描述中的 wsdl:binding 可以在所包含的 soapbind:fault 元素中指定 use 属性。C
如果 描述中的 wsdl:binding 所包含的 soapbind:fault 元素具有 use 属性，则它的值 必须为“literal”。
描述中在所包含的 soapbind:fault 元素内省略了 use 属性的 wsdl:binding 必须进行解释，就好像已经指定 use =“literal”一样。C
WSDL 1.1 第 3.6 节指出 soapbind:fault 的属性是必需的，而在该 Schema 中， use 属性定义为可选的。本概要将其定义为可选的，以便与 soapbind:body 一致。
由于 use 属性是可选的，所以本概要在省略时为该属性标识缺省值。
最后，为了确保本概要是自相一致的，只容许 use 属性的值为“literal”。
这些需求规定，当实例接收不符合 WSDL 描述的消息时应该生成 Fault，除非实例不顾这种情况自己负责处理消息。
正如 SOAP 处理模型所规定的，（a）如果“Envelope”元素的名称空间是错误的，就必须生成“VersionMismatch”Fault 代码，（b）如果实例不理解 soap:mustUnderstand 属性值为“1”的 SOAP 头代码块，就必须生成“MustUnderstand”Fault。在所有其他消息与它的 WSDL 描述不一致的情况下，都应该生成带有“Client”Fault 代码的 Fault。
如果 实例接收到与它的 WSDL 描述不一致的消息，它就 应该生成带有“Client”Fault 代码的 soap:Fault ，除非生成了“MustUnderstand”或“VersionMismatch”Fault。
如果 实例接收到与它的 WSDL 描述不一致的消息，它就 必须依次检查“VersionMismatch”、“MustUnderstand”和“Client”Fault 条件。
WSDL 1.1 第 3.5 节可以解释为必须将 RPC 响应 wrapper 元素命名为等同于 wsdl:operation 的名称。
通过 rpc-文字的绑定描述的 消息（它是响应消息） 必须有 wrapper 元素，其名称是相应的 wsdl:operation 名称，前缀为字符串“Response”。
对于 rpc-文字的 SOAP 消息，WSDL 1.1 并未明确规定参数和返回值的访问器元素是什么名称空间的一部分。不同的实现有不同的选择，这导致了互操作性的问题。
通过 rpc-文字的绑定描述的 消息必须把参数和返回值的部分访问器元素放在空名称空间中。
可选方案的稳定对于获得互操作性是至关重要的。本概要不把部分访问器元素放在名称空间中，因为这样做比较简单，包括了所有的情况，并且不会导致逻辑不一致的问题。
对于 rpc-文字的 SOAP 消息，WSDL 1.1 并没有明确规定，当相应的抽象部分的定义为与该抽象部分的 WSDL 描述的 targetNamespace 不同的名称空间中的类型时，如何正确地限定部分访问器元素的子元素的名称空间。
对于具有定义其类型的 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 （因而，其中的类型是在一个名称空间中声明的，而包含的元素是在另一个名称空间中定义的）：

最后所得到的 BarOperation 的 SOAP 消息如下：
String 0
WSDL 1.1 并未明确规定，在传送时是否必须将 WSDL 描述的 SOAP 绑定部分中的 wsdl:operation 元素内的 wsdl:input 或 wsdl:output 元素中指定的所有 soapbind:header s 都包括在最后所得到的 SOAP 消息中。
消息必须包括在描述它的 wsdl:binding 的 wsdl:operation 内的 wsdl:input 或 wsdl:output 内指定的所有 soapbind:header s。
头是 SOAP 的可扩展性机制。由于种种原因， SOAP 消息可能需要包括没有在 WSDL 描述中定义的头。
消息可以包括没有在描述它的 wsdl:binding 中描述的 SOAP 头代码块。
没有在适当的 wsdl:binding 中描述的 SOAP 头代码块所包含的 消息可以具有在这样的 SOAP 头代码块中设置为“1”的属性。
描述中的 soapbind:header s 的顺序和消息中的 SOAP 头代码块的顺序之间没有相关性。同样地，每个指定的 SOAP 头代码块的多个实例可以出现在消息中。
描述的 soapbind:binding 部分中的 soapbind:header 元素的顺序 必须认为是不依赖消息中的 SOAP 头代码块的顺序。
消息可以包含相应的描述中的 soapbind:binding 的适当子元素内每个 soapbind:header 元素的每个 SOAP 头代码块的多个实例。
互操作性测试表明，要求引用 SOAPAction HTTP 头字段-值增加了实现的互操作性。即使 HTTP 允许不引用头字段-值，但是一些实现还是要求引用该值。
对于处理器来说， SOAPAction 纯粹是一种提示。所有关于消息的内容的重要信息都是在信封中携带的。
HTTP 请求 消息必须包含引用的值与 soapbind:operation 的 soapAction 属性的值相等的 SOAPAction HTTP 头字段（如果在相应的 WSDL 描述中， soapbind:operation 的 soapAction 属性存在的话）。
HTTP 请求 消息必须包含具有引用的空字符串值的 SOAPAction HTTP 头字段（如果在相应的 WSDL 描述中， soapbind:operation 的 soapAction 属性或者不存在，或者以空字符串作为它的值而存在）。
同时参阅 R1119 和相关的需求，以获得更多关于 SOAPAction 的讨论。
例如，
正确：
包含：

的 WSDL 描述会产生带有相应的 SOAPAction HTTP 头字段的消息，如下所示：
SOAPAction: "foo"
正确：
包含：

或

的 WSDL 描述会产生带有相应的 SOAPAction HTTP 头字段的消息，如下所示：
SOAPAction: ""
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 属性或其值如何。
消费者必须理解和处理所有的 WSDL 1.1 SOAP 绑定扩展元素，而不管扩展元素中是否存在 wsdl:required 属性，也不管 wsdl:required 属性的值如何（如果存在的话）。
消费者绝不可以将 soapbind 扩展元素中存在属性值为“false”的 wsdl:required 解释为表示扩展元素在从 WSDL 描述生成的消息中是可选的。
本概要的这一节引用了下列规范（或其中的章节）：
XML Schema 第一部分：结构
XML Schema 第二部分：数据类型
WSDL 1.1 把 XML Schema 作为其类型系统之一。本概要要求将 XML Schema 作为 Web 服务的 WSDL 描述的类型系统。
描述可以使用 XML Schema 1.0 中的构造。
描述必须将 XML Schema 1.0 推荐标准作为用户定义的数据类型和结构的基础。




回页首
当需要发布或发现 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 的不一致性，并且将在以后的工作中对此加以考虑。
本概要的这一节通过引用了下列规范，并且定义了其中的可扩展性点：
UDDI 版本 2.04 API 规范（2002 年 7 月 19 日发布）
UDDI 版本 2.03 数据结构引用（2002 年 7 月 19 日发布）
UDDI 版本 2 XML Schema
本概要的这一节引用了下列规范（或其中的章节）：
UDDI 版本 2.03 数据结构引用，第 7 节
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 机制保持一致。
表示符合概要的 实例的 uddi:bindingTemplate 的 注册中心数据必须包含 uddi:accessPoint 元素。
例如，
错误：
BarSOAPPort ...
正确：
BarSOAPPort http://example.org/myBarSOAPPort ...
本概要的这一节引用了下列规范（或其中的章节）：
UDDI 版本 2.03 数据结构引用，第 8 节
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 作为描述语言，因为它是迄今为止最广泛使用的这类语言。
表示符合概要的 Web 服务类型的 uddi:tModel 类型的 注册中心数据必须使用 WSDL 作为描述语言。
为了指定符合概要的 Web 服务类型使用 WSD，本概要采用 UDDI 类别来进行断言。
表示符合概要的 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）指定了最广泛认可的这类约定。
表示符合概要的 Web 服务类型的 uddi:tModel 类型的 注册中心数据必须遵循V1.08 of the UDDI Best Practice for Using WSDL in a UDDI Registry。
如果 uddi:tModel 引用的 wsdl:binding 不符合本概要，则它将是不一致的。
uddi:tModel 类型的 注册中心数据所引用的 wsdl:binding 本身 必须符合本概要。




回页首
与所有面向网络的信息技术一样，安全性的主题对于 Web 服务也是至关重要的。对于 Web 服务以及其他信息技术，安全措施包括采取理解攻击者可能会发动的潜在威协并且应用可操作的物理和技术对策来将成功攻击的风险降低到可以接受的程度。因为“可接受的风险程度”随应用程序的不同而有很大的不同，并且实现对策的成本也有很大的变化，所以不可能有普遍适用的“正确答案”来保护 Web 服务的安全。选择绝对正确平衡的对策和可接受的风险只能在 Case by Case 的基础上才有可能做到。
经验表明， 有一些通用的对策模式可以将风险降低到许多 Web 服务可以接受的程度。本概要采用但是不要求使用其中最广泛使用的对策：采用 TLS 1.0 或 SSL 3.0 保护的（HTTPS）。也就是说，符合概要的 Web 服务可以使用 HTTPS，也可以使用其他的对策技术或根本就不使用这些技术。
普遍认为 HTTPS 是一个成熟的加密传输连接,可以提供基本的机密性。HTTPS 因而成为第一个也是最简单的实现许多现实世界中的 Web 服务应用程序所需的一些基本安全性特征。HTTPS 也可以用于通过使用客户端认证来提供客户端验证。
本概要的这一节引用了下列规范，并且定义了其中的可扩展性点：
RFC2818: HTTP Over TLS
RFC2246: The TLS Protocol Version 1.0
可扩展性点： TLS 密码包 —— TLS 允许使用任意加密算法。
TLS 扩展 —— TLS 允许握手阶段中的扩展。
The SSL Protocol Version 3.0
可扩展性点： SSL 密码包 - SSL 允许使用任意加密算法。
RFC2459: Internet X.509 Public Key Infrastructure Certificate and CRL Profile
可扩展性点： 认证机构 —— 认证机构的选择是各方之间的私有协定。
认证扩展 —— X509 允许任意的认证扩展。
HTTPS 是一种有效的得到广泛理解的基本安全性机制，本概要要求允许这种机制。
实例可以要求使用。
如果 实例要求使用 HTTPS，则它的 wsdl:port 描述中的 soapbind:address 元素的 location 属性就 必须是 Scheme 为“https”的 URI；要不然，它就必须是 Scheme 为“http”的 URI。
简单的 HTTPS 提供了由消费者验证 Web 服务的机制，而没有提供由实例验证消费者的机制。对于许多实例，这样做风险仍然太高，以致不能允许进行互操作。在本概要中包括 HTTPS 的互验证工具容许实例使用验证消费者的对策，这常常可以将风险降低到适当的程度，以便容许进行互操作。
实例可以要求使用 HTTPS 来进行相互验证。




回页首
除了由本概要取代的规范之外，本概要还引用了下列规范：
简单对象访问协议（Simple Object Access Protocol，SOAP）1.1
可扩展标记语言（Extensible Markup Language，XML）1.0（第二版）
RFC2616：超文本传输协议（Hypertext Transfer Protocol）—— HTTP/1.1
RFC2965：HTTP 状态管理机制（HTTP State Management Mechanism）
Web 服务描述语言（Web Services Description Language，WSDL）1.1
XML Schema 第一部分：结构
XML Schema 第二部分：数据类型
UDDI Version 2.04 API 规范（2002 年 7 月 19 日发布）
UDDI Version 2.03 数据结构应用（2002 年 7 月 19 日发布）
UDDI Version 2 XML Schema
RFC2818：HTTP Over TLS
RFC2246：TLS 协议（版本 1.0）
SSL 协议（版本 3.0）
RFC2459：Internet X.509 Public Key Infrastructure Certificate and CRL Profile




回页首
这一节标识了组成本概要的规范的可扩展性点，正如“概要的范围”中所定义的。
这些机制超出了本概要的范围；它们的使用可能影响互操作性，并且可能需要 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）中：
SSL 密码包- SSL 允许使用任意加密算法。
在RFC2459: Internet X.509 Public Key Infrastructure Certificate and CRL Profile中：
认证机构—— 认证机构的选择是各方之间的私有协定。
认证扩展—— X509 允许任意的认证扩展。




回页首




回页首




回页首
关于 IBM     隐私条约     联系 IBM