如何标记SOAP服务'；MTOM已启用'；

这不是Java特有的问题，但让我们举一个Java示例：添加

xmime:expectedContentTypes是Java世界的标准实践=“*/*

到base64元素以启用服务器端的MTOM处理-它导致

@xmlmetype

注释，使用

DataHandler

s而不是字节数组等。当然，这一描述大大简化了，

xmime:expectedContentTypes=“*/*

在模式中看到时，开发人员（更重要的是，实现库）通常会将其视为“MTOM就绪”。从我从这些例子中收集到的信息来看，C#世界的情况也是一样的

但是，这对我来说毫无意义——该属性指定了XML中实际需要的数据类型，而不是它可以与MTOM一起使用。我还没有在任何RFC或SOAP1.1的类似文档中找到预期内容类型和MTOM之间的任何直接联系

我的问题可以用两种方式表达：

该服务如何明确在请求/响应中接受/提供二进制数据作为MTOM附件

客户端如何正确识别二进制数据可以通过使用给定服务的MTOM附件来发送/获取

---

您似乎有点混淆了附件、SOAP附件和MTOM

SOAP附件最初是在（不是规范）中引入的，并定义了对SOAP 1.1中定义的传输绑定机制的扩展。特别是，本说明规定：

将SOAP 1.1消息绑定到MIME多部分/相关消息中，以保留SOAP 1.1消息的处理规则。用于封装复合文档的MIME多部分机制可用于绑定与SOAP 1.1消息相关的实体，如附件

简单地说，它定义了一种机制，使多个文档（附件）使用多部分mime传输结构以其本机格式与SOAP消息相关联。这是通过使用和来解释由“Content Location”头引用的URI来实现的

此格式的SOAP消息可以可视化如下（封装为multipart/mime）：

这也是您使用时可能使用的格式，但不再推荐使用，除非您使用的是遗留代码。W3C注释后来在2004年被修订为“特性”级别（与SOAP 1.2一起），并由SOAP MTOM机制进行修改

SOAP消息传输优化机制（MTOM）的官方定义不是一种机制，而是一种协同工作以提供功能的机制：

描述一种抽象功能，用于通过选择性地对消息的部分进行编码来优化SOAP消息的传输和/或有线格式，同时仍向SOAP应用程序呈现XML信息集

描述以独立于绑定的方式实现抽象SOAP传输优化功能的SOAP消息的优化MIME多部分/相关序列化

描述SOAP 1.2 HTTP绑定的抽象传输优化功能的实现

如果阅读第二个文档，您会发现“附件”已替换为或XOP

XOP包是通过将XML信息集的序列化放在可扩展的打包格式（如MIME多部分/相关的，请参见[RFC 2387]）中创建的。然后，提取并重新编码（即，数据从base64解码）其内容中的base64编码二进制数据的选定部分，并将其放入包中。这些选定部分的位置在XML中用一个特殊元素标记，该元素使用URI链接到打包数据

简单来说，这意味着不再将数据封装为多部分/mime消息中的“附件”，而是通过“指针”或链接来引用数据。以下图表有助于理解：

现在我们有了背景，让我们回到你们的问题上来

该服务如何明确在请求/响应中接受/提供二进制数据作为MTOM附件？ 事实并非如此。MTOM中没有附件的概念，因此服务器不能声明它接受附件

客户端如何正确识别二进制数据可以通过使用给定服务的MTOM附件来发送/获取？ 正如我上面所说的，客户机无法做到这一点，因为不支持“附件”

话虽如此，还有另一个W3C规范说明：

属性信息项允许Web服务应用程序优化由二进制元素信息项定义的二进制数据的处理，并应将其视为元数据。xmime:contentType属性的存在不会更改元素内容的值

当您使用

xmime:contentType

和

xmime:expectedContentTypes=“application/octet stream

（）启用MTOM时，生成的WSDL将有如下条目：

这是服务器声明它可以接收XML二进制优化包（可以分解为多部分MIME消息）的方式

当客户机看到上述情况时，客户机知道服务器可以接受XML二进制优化包，并根据定义生成适当的HTTP请求：

在类似MIME的系统中使用XOP文档时，使用“application/XOP+xml”媒体类型标识，并使用所需的“type”参数传递原始xml序列化的关联内容类型

希望有帮助