Eliminar Xop Gunk de la respuesta WS en Silverlight 3

Question

Tengo un cliente de Silverlight al que necesito llamar a un servicio web. El servicio web está integrado en Java y utiliza la codificación de XOP para adjuntar mensajes binarios a algunas de sus llamadas. Sin embargo, el servicio Silverlight solo usa llamadas que no incluyen ninguna codificación binaria. Sin embargo, dado que no tengo control sobre el servicio web, aún debo tratar con el mensaje XOP Multi -Part (un ejemplo de uno a continuación).

Respuesta de ejemplo del servicio web (datos despojados)

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="<root.message@cxf.apache.org>"; 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: <root.message@cxf.apache.org>

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

Nuestra implementación actual construye manualmente un mensaje SOAP utilizando el reemplazo de cadenas y utiliza la clase WebClient para publicar la solicitud y descargar la respuesta como una cadena. Luego nos quedamos atrapados con analizar manualmente los datos como XML. Esto está bien, pero es un poco difícil, y tenemos servicios de descanso disponibles para eso de todos modos; Realmente me gustaría el proxy del servicio para responder con objetos.

Lo que realmente me gustaría hacer es implementar un comportamiento personalizado que interceptará el mensaje antes de que la pila de WS intente deserializar el jabón y eliminar la mierda XOP, pero hasta ahora no he encontrado nada que me permita hacer tal cosa.

Como lo veo, tengo algunas opciones:

1. Cree un servicio proxy en el servidor (que controlo) que volverá a enviar la solicitud al servicio Java y puede manejar el XOP. Esta opción tiene implicaciones de rendimiento que me gustaría evitar.

2. Implemente un MessageCodingBindingElement personalizado, MessageEncoderFactory y MessageEncoder que manejará el XOP. Esta opción parece ser la mejor al principio, pero dado que no puedo extender el TextMessageEncoderFactory o TextMessageEncoder (son clases internas), básicamente necesitaría reescribir todo el mensaje que codifica desde cero (¡muchas gracias Microsoft!).

3. Deja la cosa como es.

¿Hay alguna opción que no esté viendo?

Answer 1

No, no hay otras alternativas.

Decidí implementar un proxy Ashx de aprobación que usará el método WebClient.downloadString () y luego analice solo el jabón y enchufe eso en la respuesta. Debería ser lo suficientemente flexible y, lo mejor de todo, puedo usar las clases de proxy autogenadas de Silverlight, luego simplemente hacer que el punto final use mi proxy ashx, lo que hace que el mantenimiento sea mucho más simple.