Physical Address
304 North Cardinal St.
Dorchester Center, MA 02124
ISO/IEC 29363 — Web Services Interoperability — WS-I Simple SOAP Binding Profile 版本1.0
WS-I简单SOAP绑定规范：一致性、序列化与互操作性工程参考
ISO/IEC 29363 定义了 WS-I 简单 SOAP 绑定规范 1.0 版，这是一个配套规范，通过约束 SOAP 1.1 的绑定实践，在异构 Web 服务栈之间实现尽可能高水平的互操作性。虽然 SOAP 1.1 被广泛实现，但它在编码风格、序列化规则和传输绑定方面的灵活性历来是互操作性失败的根源。该规范将这种灵活性缩小到一个定义明确的子集——”简单”绑定——所有主流平台（Java、.NET、Python 和 C++）都能以一致的结果支持该子集。
简单 SOAP 绑定规范实际上已弃用 SOAP 编码（SOAP 1.1 规范的第 5 节），转而支持字面 XML 表示。设计新 Web 服务的团队应默认使用带有命名包装元素的 document/literal，以获得最大的工具链兼容性。
1. 核心绑定约束与序列化规则
该规范强制使用了 SOAP 1.1 特性的严格子集。最重要的约束是禁止使用 SOAP 编码风格（http://schemas.xmlsoap.org/soap/encoding/）。消息必须使用字面 XML 表示，这意味着 SOAP 主体包含实际的 XML Schema 类型，没有编码相关的工件（如 soapenc:Array 或 soapenc:struct）。下表总结了关键的序列化规则。
| 约束 | 要求 | 影响 |
|---|---|---|
| SOAP 编码风格 | 不得使用 | 数组类型使用 xsd:sequence 替代 soapenc:Array |
| 主体子元素命名空间 | 必须有前缀（不得在默认命名空间中） | 防止元素 QName 解析中的歧义 |
| use 属性（绑定） | 必须为 “literal” | 无 SOAP 编码序列化；保留 XML Infoset |
| transport 属性 | 必须为 “http://schemas.xmlsoap.org/soap/http” | 仅支持 HTTP 绑定 |
| style 属性（绑定） | “document” 或 “rpc” | 两者均允许；强烈推荐 “document” |
| soap:Header 条目 | mustUse=”literal” | 头部块也使用字面 XML 序列化 |
| soap:Fault detail | 子元素必须有命名空间前缀 | 确保故障详情能被可靠处理 |
对于 RPC 风格的绑定，规范要求包装元素（过程名）必须有命名空间前缀，并且各部分直接映射到包装元素下的子元素。关键是，SOAP 编码中使用的 soapenc:root 属性和 soapenc:offset 属性均被禁止，从而大大简化了反序列化逻辑。
一个常见的一致性失败是在主体子元素上省略命名空间前缀。当 SOAP 主体包含无前缀的元素时，.NET 和 CXF 中的模式感知验证器将拒绝该消息并返回验证错误。始终验证主体的第一个子元素是否带有显式的 xmlns 属性或带前缀的命名空间。
2. Document/Literal 与 RPC/Literal 之工程决策
该规范允许 document/literal 和 RPC/literal 两种风格，但每种风格都有不同的工程权衡。Document/literal 是首选模式，因为它让开发者完全控制 XML Schema 契约——SOAP 主体直接包含一个或多个经过模式验证的元素。RPC/literal 虽然从 IDL 风格接口生成更简单，但引入了一个包装元素，其名称来源于操作名称，这导致 WSDL 与编程模型之间的耦合更紧密。
对于新的服务开发，采用 document/literal 包装模式：定义一个请求包装元素（例如 SubmitOrderRequest）和一个响应包装（SubmitOrderResponse）。这种模式生成的消息自描述性强，易于验证、版本管理以及通过企业服务总线进行路由。
下表在规范的约束背景下比较了两种绑定风格。
| 方面 | Document/Literal | RPC/Literal |
|---|---|---|
| 主体包含 | 一个或多个模式元素 | 以操作名称为包装，包含子部分 |
| WSDL 复杂性 | 需要显式的模式类型 | 更简单；类型从部分推断 |
| 模式验证 | 完整的 XSD 1.0 验证适用 | 包装元素必须在模式中定义 |
| 版本管理 | 更容易——添加可选元素即可 | 更困难——更改部分会更改包装签名 |
| 工具包成熟度 | 所有现代栈均支持 | 广泛支持但被视为遗留 |
| WS-I 一致性 | 强烈推荐 | 在包装约束下允许 |
3. 传输绑定与 HTTP 考量
该规范明确将传输绑定限制为 HTTP，实际上已弃用 SMTP、JMS 和其他 WS-I 一致性的协议绑定。SOAPAction HTTP 头必须存在，其值必须是带引号的字符串，与 WSDL 绑定中的 soapAction 属性匹配。省略或计算错误的 SOAPAction 头的服务将无法通过 WS-I 合规性验证。
一个特别隐蔽的问题出现在 HTTP 中间件或反向代理修改 SOAP 请求的 Content-Type 头时。规范要求 Content-Type: text/xml; charset=utf-8。如果代理将其重写为 application/soap+xml（SOAP 1.2 使用），SOAP 1.1 处理器将拒绝该消息。确保基础设施层不会在 SOAP 版本之间转换 Content-Type 头。
HTTP 状态码处理也受到约束：成功的 SOAP 响应必须使用 HTTP 200，而 SOAP 故障必须在 HTTP 500 响应中携带。非常规用法（如用于异步接受的 HTTP 202）不在规范范围内。
4. 一致性测试与规范断言
该标准包括一套全面的规范断言，可以使用 WS-I 一致性声明附件机制进行验证。声称一致性的实现必须满足所有强制断言，涵盖信封结构、序列化规则、头部处理和故障构建。WS-I 测试工具提供自动验证；工程团队应将这些工具集成到 CI/CD 管道中，以尽早捕获回归问题。
对于使用契约优先开发（先有 WSDL 后有代码）的团队，该规范提供了一个明显的优势：可以在设计时（远在编写实现代码之前）根据规范的约束验证 WSDL 文档。这可以在规范阶段捕获互操作性问题，而这是修复问题成本最低的阶段。
问：我可以将简单 SOAP 绑定规范与 SOAP 1.2 一起使用吗？
答：不可以——该规范专门针对 SOAP 1.1。SOAP 1.2 有自己的绑定框架，在 SOAP 1.2 规范和 W3C SOAP 1.2 绑定建议中定义。WS-I 基本规范（BP 1.2）涵盖了 SOAP 1.2 场景。
问：该规范是否禁止多引用访问器？
答：是的，隐式禁止。多引用访问器是 SOAP 编码（第 5 节）的特性，该编码已被完全禁止。所有值必须使用字面 XML 内联序列化；不支持基于引用的图结构。
问：如何处理字面序列化中的可为空元素？
答：在元素上使用 xsi:nil=”true”。这与字面 XML 序列化完全兼容，并得到所有符合 WS-I 的工具包支持。除非模式明确使用 minOccurs=”0″ 使其成为可选元素，否则不要完全省略该元素。
问：该规范是否与 WS-Addressing 兼容？
答：是的——WS-Addressing 头部（wsa:Action、wsa:MessageID、wsa:To 等）是 SOAP 头部块，与字面头部序列化要求完全兼容。该规范不限制 WS-Addressing 的使用；它只要求头部块使用字面序列化和显式的命名空间限定。
