Physical Address
304 North Cardinal St.
Dorchester Center, MA 02124
ISO/IEC 29362 — Web Services Interoperability — WS-I Attachments Profile 版本1.1
基于MIME的SOAP附件互操作性工程指南
ISO/IEC 29362 标准，即 WS-I 附件规范 1.1 版，定义了一个结构化的框架，用于在 SOAP 消息旁边以完全可互操作的方式打包和传输二进制或复合负载。在现代面向服务架构中，将图像、文档或大型数据对象嵌入 Web 服务会话的能力至关重要，但没有一个共享的规范，不同的实现会产生不兼容的在线格式。该标准通过强制采用一致的 MIME 多部分绑定、从 SOAP 信封引用附件的具体规则以及可实现者可以针对参考工具进行验证的合规模型来弥补这一差距。
对于构建文档密集型或内容密集型 Web 服务的工程团队而言，将 WS-I 附件规范作为设计时契约，可以消除最常见的附件相关互操作性缺陷——尤其是围绕内容传输编码、MIME 边界处理和 URI 引用解析方面的缺陷。
1. 架构与 MIME 多部分绑定
该规范规定，带附件的 SOAP 消息应序列化为符合 RFC 2387 和 RFC 2045 的 MIME multipart/related 消息。根正文部分必须是 SOAP 1.1 信封，Content-Type 为 “text/xml”，每个后续部分携带一个附件。下表总结了规范强制实施的关键 MIME 结构规则。
| MIME 参数 | 要求 | 原理 |
|---|---|---|
| Content-Type（根部分） | text/xml; charset=utf-8 | 确保所有 SOAP 处理器能无歧义地识别根部分 |
| Content-Transfer-Encoding | 7bit、8bit 或 binary（根 XML 不使用 quoted-printable 或 base64） | XML 使用 Base64 会隐藏结构；binary 可保持解析器效率 |
| Content-ID（cid: 方案） | 全局唯一；按 RFC 2392 使用尖括号括起 | wsa:Reference 机制所需；基于路径的引用不可移植 |
| 附件处置方式 | Content-Disposition 应省略或设为 “attachment” | inline 处置方式会使处理复杂化，不推荐使用 |
| MIME 版本 | 前导部分必须包含 MIME-Version: 1.0 | 按 RFC 2045，所有多部分消息均需此字段 |
根正文部分和附件通过 WS-Addressing 命名空间中定义的 wsa:Reference 元素链接。实现者必须确保 wsa:Reference 中的 URI 使用 cid:（内容 ID）方案进行直接部分查找。使用绝对文件路径或 URL 会破坏多部分消息的自包含性质，并在消息穿越中间件时导致失败。
WS-I 附件实现中的一个常见陷阱是使用非规范的 MIME 边界字符串。该规范要求边界分隔符以 CRLF 开头，且绝不能出现在任何正文部分内部。生成具有足够熵的边界——强烈建议使用基于 UUID 的边界，而不是基于时间或序列的替代方案。
2. 从 SOAP 信封引用附件
该规范规定了两种引用机制：WS-I 附件模式中定义的 swaRef 类型，以及 WS-Addressing 中的 wsa:Reference 元素。swaRef 机制使用一个 href 属性，其值是与某个 Content-ID 头匹配的 URI。这种间接方式将逻辑引用与物理 MIME 结构解耦，允许中间件重新排序正文部分而不会破坏引用。
生产级实现应在运行时验证每个 swaRef URI 是否都能解析到 MIME 包中对应的 Content-ID 头。未解析的引用是文档影像和电子签名工作流中部分消息错误的主要原因。
从工程角度来看，最稳健的方法是生成 UUID 格式的 Content-ID（例如 uuid:a1b2c3d4-...@ws-i.example.com），并在 swaRef 中嵌入相同的 UUID（不含尖括号）。这消除了大小写敏感性和 URI 规范化方面的歧义——这两种情况是难以调试的故障的常见来源。
3. 消息优化与性能考量
虽然该规范未强制要求 MTOM（消息传输优化机制），但设计新系统的工程师应评估 MTOM/XOP（XML 二进制优化封装）是否能提供更优的线路效率。WS-I 附件规范在逻辑上与 MTOM 兼容；关键区别在于 MTOM 在传输层将二进制内容移出 SOAP 信封，而附件规范使用并行的 MIME 结构。
| 特性 | WS-I 附件规范 | MTOM/XOP |
|---|---|---|
| 在线格式 | MIME multipart/related | 带有 XOP include 的 MIME multipart/related |
| 二进制表示 | cid 引用的 MIME 部分 | XML 中的 Base64 通过 xop:Include 替换 |
| SOAP 信封大小 | 不变 | 减小（二进制内容已排除） |
| 中间件透明性 | 完全（信封不变） | XOP 重新序列化后完全透明 |
| 引用解析 | swaRef + cid: URI | xop:Include + cid: URI |
| 工具包支持 | Axis 1.x, gSOAP, WCF | Axis 2, CXF, .NET 3.0+, Metro |
将传统 SwA 客户端迁移到新平台时，切勿假设附件顺序能端到端保留。ESB 和 API 网关等中间件经常重新排序 MIME 部分。始终使用基于 Content-ID 的引用而非位置索引，以确保在异构基础设施中的稳健性。
4. 互操作性测试与合规性
该标准附带了 WS-I 测试工具（分析器、监视器和声明测试器），用于验证消息是否符合附件规范的断言。声称符合 WS-I 附件规范的实现必须通过所有强制断言，涵盖 MIME 结构、SOAP 信封完整性、引用解析和字符编码规则。
对于工程团队，推荐的工作流程是：(1) 使用 WS-I 监视器检测服务端点以捕获在线消息，(2) 运行分析器以识别规范违规，(3) 在生产部署前进行整改。这种方法在大规模政府和医疗互操作性项目中已被证明是有效的，这些项目中附件处理失败直接影响运营。
问：WS-I 附件规范是否支持 SOAP 1.2？
答：该规范仅针对 SOAP 1.1 定义。对于 SOAP 1.2 系统，请使用 W3C 推荐的 SOAP 消息传输优化机制（MTOM），它提供了同等的功能且具有更好的性能特性。
问：我可以在没有 SOAP 信封包裹的情况下包含 XML 附件吗？
答：不可以——该规范要求根正文部分是一个完整的 SOAP 1.1 信封。附件是从信封内引用的附加 MIME 部分。没有包含 SOAP 消息的独立 XML 附件不在规范范围内。
问：建议的最大附件大小是多少？
答：该标准未定义大小限制。然而，实践经验表明，超过 50 MB 的 MIME 多部分消息会导致 Java EE 和 .NET 反序列化管道的性能下降。对于更大的负载，请考虑在 HTTP 传输层使用流式 MTOM 或分块传输编码。
问：如何确保附件加密符合规范要求？
答：该规范本身未规定安全机制。使用 WS-Security 加密 SOAP 信封主体，并考虑在应用层单独加密附件部分。请注意，加密附件不能被中间件检查，并且会影响消息吞吐量。对于端到端加密，应在传输层结合 TLS 1.3。
