email article printer friendly get the code more resources

Implement a File Transfer Web Service
Create a Web service that performs a binary file transfer using Web Service Enhancements 3.0 and MTOM.
by Martin Kulov

April 24, 2006

Technology Toolbox: C#, XML, ASP.NET Web Services, SOAP

The Web Service Enhancements (WSE) standard provides a robust infrastructure for securing Web services by using client and/or server X509 certificates, Kerberos, or username tokens.

It does more than this, of course. All messages that WSE transmits conform to WS-Star (WS-*) specifications, a set of standards created by standardization bodies like W3C () and OASIS (). This enables you to call Web services independently from the client’s operating system and provide integrated best practices in standard specifications. Microsoft’s upcoming Windows Communication Framework (WCF) promises to replace WSE in the near future and provide even more capabilities, while preserving interoperability with WSE 3.0.

One of WSE’s key features—apart from its security benefits—is the Message Transmission Optimization Mechanism (MTOM), which helps you deliver binary files to the client and back to the server.

These are nice features, but many developers become frustrated or intimidated when they start a WSE project for the first time, finding it difficult to look past a lot of scary XML tags with unknown configuration options (see the sidebar, “HOLs Provide Strong Start”). I’ll show you how to take get past these potentially intimidating initial steps by explaining how to leverage and improve on a Web service by relying on the infrastructure provided by WSE 3.0. This improved Web service will be more secure, more scalable, and better optimized, while also conforming to existing standards for security and interoperability.

Combining XML with Web services makes using them far easier and more intuitive. You can read wire message content in plain text, store that content in a file, and even index that content using SQL Server 2005’s new XML column type. This looks wonderful until you have to do a seemingly trivial task: download a binary file.

You have two choices at this point. You can either encode the binary file inside the XML message, or you can stream it as a regular file just as you always have. Both approaches have their pros and cons.

The first option is relatively trivial and much easier to implement. You can put the binary file on an IIS Web server and let the IIS handle all the problems such as scalability, chunking, and security. The drawback to this approach is that you cannot integrate it with WS-* specifications. For many circumstances, especially circumstances where performance and scalability are critical, this can be an acceptable trade-off.

Your other option is to encode the file in the XML message. Doing so requires that you adhere to one simple rule: You cannot use special characters in the XML message. When you try to place a byte array in an XML file, the .NET Framework automatically base64 encodes the array, so no special characters remain. Base64 encodes the binary stream with safe-to-use characters only. You can find more information on how the base64 algorithm works at .