SoapHttpClientProtocol: get response as a stream instead of a string?

I'm using a webservice which spits out very large amounts of data in one piece. The response string can be something like 8MB. While not an issue on a desktop PC, an embedded device goes nuts dealing with an 8MB string object.

I wonder if there is a way to 开发者_如何学Cget the response as a stream? Currently I'm using the method like below. I tried using a POST request instead, but SOAP is just more convenient (the response is XML and with the POST I have to convert the plain text reply back to valid XML) and I'd like to stick with it. Is it possible to use a different kind of "Invoke" which won't return strings but streams? Any ideas?

[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]));
    }

If you use the old ASMX web service client infrastructure, then you're stuck with its limitations. One limitation is that there's no simple way to get the response except as deserialized data.

If it were necessary, then you could use a partial class to override the GetWebResponse method to return your own custom WebResponse. This latter would in turn override the GetResponseStream method to call the base version, consume the stream, then to return a stream containing an "empty" web request (otherwise .NET will choke on a stream with no contents).

You might also try something similar by overriding the GetReaderForMessage method. This is passed a SoapClientMessage instance which has a Stream property that you might be able to use. Again, you'll have to set the stream to something that the web service infrastructure can consume.

The better way to do this is with a WCF client. WCF has much more powerful and easy to use extensibility mechanisms.

In fact, you might not even need to extend a WCF client. You might simply be able to configure it to not have this buffering problem at all.

Any web service call is going to return SOAP, isn't it? I don't think a stream could be serialized into a soap packet to be returned from your service. And even if it could, wouldn't the serialized stream be at least as big as the string itself?

I believe the answer is no, there is no concept of a stream for SOAP.

Probably the simplest answer is to have your method:

• Parse your response into segments your mobile device can handle
• Cache your response in a application variable as a dictionary of these segments
• return an arraylist of GUIDs.

You can then have your client request each of these segments separately via their GUIDs, then reassemble the original response when and handle it all the web services return.

ASMX can't do much about this. WCF's BasicHttpBinding can return a Stream to the caller.

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