The following code sample shows how to implement this approach.
public class ProgressTest : IXmlSerializable
{
public void WriteXml(System.Xml.XmlWriter writer)
{
int progress=0;
while(progress <= 100)
{
writer.WriteElementString("Progress",
"http://progresstest.com",
progress.ToString());
writer.Flush();
progress += 10;
// Pretend to do something that takes 0.5 second
System.Threading.Thread.Sleep(500);
}
writer.WriteElementString("TheData",
"http://progresstest.com","Some data
goes here");
}
}
The Web method must disable response buffering and return an instance of the ProgressTest type, as shown below.
[WebMethod]
public ProgressTest DoLongOperation2()
{
HttpContext.Current.Response.BufferOutput=false;
return new ProgressTest();
}
More Information
For more information about bulk data transfer, see:
- Microsoft Knowledge Base article 318425, "HOW TO: Send and Receive Binary Documents by Using an ASP.NET Web Service and Visual C# .NET," at http://support.microsoft.com/default.aspx?scid=kb;en-us;318425.
- MSDN article, "Large Data Strategies," at http://msdn.microsoft.com/library/en-us/dnservice/html/service11072001.asp.
- MSDN article, "XML,SOAP, and Binary Data," at http://msdn.microsoft.com/library/en-us/dnwebsrv/html/infoset_whitepaper.asp.
Attachments
You have various options when handling attachments with Web services. When choosing your option, consider the following:
- WS-Attachments. WSE versions 1.0 and 2.0 provide support for WS-Attachments, which uses Direct Internet Message Encapsulation (DIME) as an encoding format. Although DIME is a supported part of WSE, Microsoft is not investing in this approach long term. DIME is limited because the attachments are outside the SOAP envelope.
- Base 64 encoding. Use Base 64 encoding. At this time, you should use Base 64 encoding rather than WS-Attachments when you have advanced Web service requirements, such as security. Base 64 encoding results in a larger message payload (up to two times that of WS-Attachments). You can implement a WSE filter to compress the message with tools such as GZIP before sending it over the network for large amounts of binary data. If you cannot afford the message size that Base 64 introduces and you can rely on the transport for security (for example, you rely on SSL or IPSec), then consider the WSE WS-Attachments implementation. Securing the message is preferable to securing the transport so that messages can be routed securely, whereas transport only addresses point-to-point communication.
- SOAP Message Transmission Optimization Mechanism (MTOM). MTOM, which is a derivative work of SOAP messages with attachments (SwA), is likely to be the future interop technology. MTOM is being standardized by the World Wide Web Consortium (W3C) and is much more composition-friendly than SwA.
SOAP Messages with Attachments (SwA)
SwA (also known as WS-I Attachments Profile 1.0) is not supported. This is because you cannot model a MIME message as an XML Infoset, which introduces a non-SOAP processing model and makes it difficult to compose SwA with the rest of the WS-* protocols, including WS-Security. The W3C MTOM work was specifically chartered to fix this problem with SwA, and Microsoft is planning to support MTOM in WSE 3.0.
COM Interop
Calling single-threaded apartment (STA) objects from Web services is neither tested nor supported. The ASPCOMPAT attribute that you would normally use in ASP.NET pages when calling Apartment threaded objects is not supported in Web services.
