java - WCF MTOM/XOP 客户端反序列化错误

Question

这是我已经回答过的那些“问题”之一，但是根据一周的谷歌搜索，我发布的信息似乎几乎为零。

TL;DR:WCF MTOM 编码的 BasicHttpBinding 客户端到外部/第三部分，非 .NET Web 服务在 MTOM 响应的 XOP 处理上阻塞 - 基本上 MTOM 编码器似乎期望二进制元素中的 base64 有效负载，但运行到... 指令并且无法将 SOAP/XML 反序列化为运行时对象，从而在该问题的标题中引发错误。

错误:命名空间“http://mynamespace”中的结束元素“MyBinaryData” ' 预期的。从命名空间“http://www.w3.org/2004/08/xop/”找到元素“xop:Include” '

如前所述，关于这个主题的内容并不多，我猜 b/c MS 的大部分 WCF 文档都是基于服务开发编写的，而不是客户端(虽然有一些，公平地说) .

我不会深入讨论初始设置的细节，因为我要回答我自己的问题，但我会在答案前说这更类似于默认设置WCF MTOM 的配置比没有。

另外，我知道 WCF 很旧、很无聊，并且 MS 不再积极开发它，但它仍然受到支持，并且有很多用途。事实上我没有太多选择，必须找到一种方法来完成这项工作。这就是为什么我要与其他必须处理这种头痛问题的人分享我的发现。

Answer 1

TL;DR:检查http header 以查看服务响应是否为“Transfer-Encoding:分块”(流式传输)给您，如果是，请在绑定(bind)配置中使用transferMode =“StreamedResponse”。

因此，在谷歌搜索几天没有帮助后，我启动了 Fiddler 来捕获 http 流量 - 这需要您的 WCF 基本 http 绑定(bind)配置来代理到 Fiddler (我认为默认情况下为 http://localhost:8888 )，具体取决于您的目标位置服务驻留时，您可能需要也可能不需要配置 Fiddler 的网关设置(公司代理等)。

这使我能够看到我的客户与他们的服务之间发送的原始文本；所有有效负载都很好，这意味着，就我而言，来自服务的 MTOM/XOP 响应已完全传输，并且 WCF 运行时无法正确解释响应。我看到的另一个关键问题是 Transfer-Encoding http header 被“分块”并且没有 Content-Length header ...这意味着该服务正在流式传输响应，而不是缓冲响应。现在有一点旁注:MS 的 WCF MTOM 文档有一个标注说您应该始终在绑定(bind)配置中使用“Buffered”作为传输模式...但没有提到这实际上只适用于服务，不一定适用于客户端!

很自然地，我简单地进入我的配置文件，找到system.serviceModel >>绑定(bind)>> basicHttpBinding集合，找到我的特定绑定(bind)配置并设置transferMode =“StreamedResponse”(因为第3方服务正在将我的响应流式传输回来给我的客户)。