Удалить XOP Gunk из WS Response в Silverlight 3

Question

У меня есть клиент Silverlight, который мне нужен для вызова веб-службы. Веб-сервис построен на Java и использует кодирование XOP для присоединения двоичных сообщений к некоторым его вызовам. Однако служба Silverlight использует только вызовы, которые не включают в себя двоичное кодирование. Однако, поскольку я не контролирую веб-службу, я все равно должен иметь дело с сообщением из нескольких частей XOP (пример одного из них приведен ниже).

Пример ответа от веб-сервиса (данные удалены)

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

Наша текущая реализация вручную создает мыльное сообщение с использованием замены строки и использует класс WebClient для отправки запроса и загрузки ответа в виде строки. Затем мы застряли с ручным анализом данных как XML. Это нормально, но это немного сложно, и в любом случае у нас есть REST-сервисы; Мне бы очень хотелось, чтобы сервисный прокси отвечал объектами.

Что я действительно хотел бы сделать, так это реализовать собственное поведение, которое будет перехватывать сообщение, прежде чем стек WS попытается десериализовать SOAP и удалить ганк XOP, но до сих пор я не нашел ничего, что позволило бы мне сделать такую ​​вещь.

На мой взгляд, у меня есть несколько вариантов:

1. Создайте на сервере прокси-службу (которую я контролирую), которая повторно отправит запрос в службу Java и сможет фактически обработать XOP. Этот параметр влияет на производительность, чего я хотел бы избежать.

2. Реализуйте пользовательский MessageEncodingBindingElement, MessageEncoderFactory и MessageEncoder, который будет обрабатывать XOP. Этот вариант на первый взгляд кажется лучшим, но поскольку я не могу расширить TextMessageEncoderFactory или TextMessageEncoder (они являются внутренними классами), мне, по сути, потребуется переписать всю кодировку сообщений с нуля (большое спасибо Microsoft!).

3. Оставь вещь как есть.

Есть ли варианты, которые я не вижу?

Answer 1

Нет, других альтернатив нет.

Я решил реализовать сквозной прокси-сервер ashx, который будет использовать метод WebClient.DownloadString(), затем анализировать только SOAP и вставлять его в ответ. Он должен быть достаточно гибким, и, что лучше всего, я могу просто использовать автоматически сгенерированные прокси-классы от Silverlight, а затем просто заставить конечную точку использовать мой прокси-сервер ashx, что значительно упрощает обслуживание.