Question

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="<[e-mail]>"; 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: <[e-mail]>

<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:

1. 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.

2. 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!).

3. Leave the thing as it is.

Are there any options that I’m not seeing?

Answer 1

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.