Удалить XOP Gunk из WS Response в Silverlight 3 - PullRequest
Новая
       39

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

0 голосов
/ 28 января 2011

У меня есть клиент 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="<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--

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

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

Как я вижу, у меня есть несколько вариантов:

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

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

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

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

1 Ответ

0 голосов
/ 04 февраля 2011

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

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

...