从 Silverlight 3 中的 WS 响应中删除 XOP 垃圾
我有一个 Silverlight 客户端，需要调用 Web 服务。 Web 服务是用 Java 构建的，并使用 XOP 编码将二进制消息附加到其某些调用。但是，Silverlight 服务仅使用不包含任何二进制编码的调用。但是，由于我无法控制 Web 服务，因此我仍然必须处理 XOP 多部分消息 - （下面是一个示例）。
来自 Web 服务的示例响应（数据被删除）
HTTP/1.1 200 OK
Server: Apache-Coyote/1.1
X-Powered-By: Servlet 2.5; JBoss-5.0/JBossWeb-2.1
Content-Type: multipart/related; type="application/xop+xml"; boundary="uuid:890535d9-d11f-4dfb-8393-789e20ea8064"; start="<[email protected]>"; start-info="text/xml"
Date: Thu, 27 Jan 2011 22:03:09 GMT
Content-Length: 47247
--uuid:890535d9-d11f-4dfb-8393-789e20ea8064
Content-Type: application/xop+xml; charset=UTF-8; type="text/xml";
Content-Transfer-Encoding: binary
Content-ID: <[email protected]>
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
<soap:Body>
<ns2:Response xmlns:ns2="http://tempuri.com/"></ns2:Response>
</soap:Body>
</soap:Envelope>
--uuid:890535d9-d11f-4dfb-8393-789e20ea8064--
我们当前的实现使用字符串替换手动构造肥皂消息，并使用 WebClient 类发布请求并将响应下载为字符串。然后我们不得不手动将数据解析为 XML。这没问题，但是有点困难，无论如何我们都有可用的 REST 服务；我真的希望服务代理能够用对象进行响应。
我真正想做的是实现一个自定义行为，该行为将在 WS 堆栈尝试反序列化 SOAP 并删除 XOP 垃圾之前拦截消息，但到目前为止，我还没有发现任何可以让我做这样的事情的东西。
在我看来，我有几个选择：
在服务器（我控制的）上创建一个代理服务，该服务将重新向 Java 服务提交请求，并且可以实际处理 XOP。我希望避免此选项对性能的影响。
实现将处理 XOP 的自定义 MessageEncodingBindingElement、MessageEncoderFactory 和 MessageEncoder。这个选项乍一看似乎是最好的，但由于我无法扩展 TextMessageEncoderFactory 或 TextMessageEncoder（它们是内部类），我基本上需要从头开始重写整个消息编码（非常感谢 Microsoft！）。
让事情保持原样。
有没有我没有看到的选项？
I have a Silverlight client that I need to call a web service. The web service is built in Java and uses XOP encoding to attach binary messages to some of its calls. However, the Silverlight service only uses calls that do not include any binary encoding. However, since I have no control over the web service, I must still deal with the XOP multi-part message - (an example of one is below).
Example response from web service (data stripped out)
HTTP/1.1 200 OK
Server: Apache-Coyote/1.1
X-Powered-By: Servlet 2.5; JBoss-5.0/JBossWeb-2.1
Content-Type: multipart/related; type="application/xop+xml"; boundary="uuid:890535d9-d11f-4dfb-8393-789e20ea8064"; start="<[email protected]>"; start-info="text/xml"
Date: Thu, 27 Jan 2011 22:03:09 GMT
Content-Length: 47247
--uuid:890535d9-d11f-4dfb-8393-789e20ea8064
Content-Type: application/xop+xml; charset=UTF-8; type="text/xml";
Content-Transfer-Encoding: binary
Content-ID: <[email protected]>
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
<soap:Body>
<ns2:Response xmlns:ns2="http://tempuri.com/"></ns2:Response>
</soap:Body>
</soap:Envelope>
--uuid:890535d9-d11f-4dfb-8393-789e20ea8064--
Our current implementation manually constructs a soap message using string replacement and uses the WebClient class to post the request and download the response as a string. We're then stuck with manually parsing the data as XML. This is ok, but it's a bit difficult, and we have REST services available for that anyway; I'd really like the service proxy to respond with objects.
What I'd really like to do is implement a custom behavior that will intercept the message before the WS stack tries to deserialize the SOAP and remove the XOP gunk, but so far I have found nothing that will allow me to do such a thing.
The way I see it, I have a few options:
Create a proxy service on the server (that I control) that will resubmit the request to the Java service and can actually handle the XOP. This option has performance implications that I'd like to avoid.
Implement a custom MessageEncodingBindingElement, MessageEncoderFactory, and MessageEncoder that will handle the XOP. This option seems like the best at first, but since I cannot extend the TextMessageEncoderFactory or TextMessageEncoder (they are internal classes) I basically would need to rewrite the entire message encoding from scratch (Thank you very much Microsoft!).
Leave the thing as it is.
Are there any options that I'm not seeing?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
不，没有其他选择。
我决定实现一个传递 ashx 代理，该代理将使用 WebClient.DownloadString() 方法，然后仅解析 SOAP 并将其插入到响应中。它应该足够灵活，最重要的是，我可以使用 Silverlight 自动生成的代理类，然后让端点使用我的 ashx 代理 - 这使得维护更加简单。
Nope, there's no other alternatives.
I've decided to implement a pass-through ashx proxy that will use the WebClient.DownloadString() method then parse out just the SOAP and plug that into the response. It should be flexible enough, and best of all, I can just use the autogenerated proxy classes from Silverlight, then just make the endpoint use my ashx proxy - which makes maintenance much simpler.