SoapHttpClientProtocol: получить ответ в виде потока вместо строки? - PullRequest
3 голосов
/ 16 февраля 2011

Я использую веб-сервис, который выплевывает очень большие объемы данных в один кусок.Строка ответа может быть примерно 8 МБ.Хотя это не проблема для настольного ПК, встроенное устройство сходит с ума, имея дело со строковым объектом 8 МБ.

Интересно, есть ли способ получить ответ в виде потока?В настоящее время я использую метод, как показано ниже.Вместо этого я попытался использовать запрос POST, но SOAP просто удобнее (ответом является XML, а с помощью POST мне нужно преобразовать ответ в виде простого текста обратно в действительный XML), и я хотел бы придерживаться его.Возможно ли использовать другой вид «Invoke», который не будет возвращать строки, а только потоки?Есть идеи?

[System.Web.Services.Protocols.SoapDocumentMethodAttribute("MyAPI/MyMethod", RequestNamespace="MyAPI", ResponseNamespace="MyAPI", ParameterStyle=System.Web.Services.Protocols.SoapParameterStyle.Wrapped, Use=System.Web.Services.Description.SoapBindingUse.Literal)]
    public string MyMethod(string sID)
    {
      object[] results = this.Invoke("MyMethod", new object[] { sID });
      return ((string)(results[0]));
    }

Ответы [ 4 ]

1 голос
/ 16 февраля 2011

ASMX ничего не может с этим поделать.BasicHttpBinding * WCF может вернуть поток вызывающей стороне.

http://msdn.microsoft.com/en-us/library/ms733742.aspx

1 голос
/ 16 февраля 2011

Я полагаю, что ответ отрицательный, нет концепции потока для SOAP.

Вероятно, самый простой ответ - использовать ваш метод:

  • Разобрать ваш ответ на сегментыВаше мобильное устройство может обрабатывать
  • Кэшировать ваш ответ в переменной приложения, так как словарь этих сегментов
  • возвращает массив GUID.

Затем клиент может запросить каждый из этих сегментов по отдельности через их GUID, а затем повторно собрать исходный ответ и обработать его, когда все веб-сервисы вернутся.

1 голос
/ 16 февраля 2011

Если вы используете старую клиентскую инфраструктуру веб-службы ASMX, то вы застряли с ее ограничениями. Одним из ограничений является то, что нет простого способа получить ответ, кроме как десериализованных данных.

Если бы это было необходимо, то вы могли бы использовать частичный класс для переопределения метода GetWebResponse, чтобы вернуть свой собственный WebResponse. Последний, в свою очередь, переопределяет метод GetResponseStream для вызова базовой версии, использования потока, а затем для возврата потока, содержащего «пустой» веб-запрос (в противном случае .NET захлебнется потоком без содержание).

Вы также можете попробовать нечто подобное, переопределив метод GetReaderForMessage. Ему передается экземпляр SoapClientMessage, который имеет свойство Stream, которое вы можете использовать. Опять же, вам придется настроить поток на то, что может потреблять инфраструктура веб-службы.

Лучший способ сделать это с клиентом WCF. WCF имеет гораздо более мощные и простые в использовании механизмы расширяемости.

На самом деле вам даже не нужно расширять клиент WCF. Вы можете просто настроить его так, чтобы вообще не было этой проблемы с буферизацией.

1 голос
/ 16 февраля 2011

Любой вызов веб-службы вернет SOAP, не так ли?Я не думаю, что поток может быть сериализован в мыльный пакет, который будет возвращен из вашего сервиса.И даже если бы это было так, разве сериализованный поток не был бы таким же большим, как сама строка?

...