Export (0) Print
Expand All

Azure Web Applications and Serialization

Updated: June 19, 2014

When writing applications for Azure, data serialization becomes increasingly important when compared to writing on-premises applications. Azure applications get charged for database use, general storage, data transfers and caching. For more information on pricing see, Azure Pricing Overview. Additionally Azure applications may be used from mobile devices like phones, tablets, etc. and this can introduce latency because of their partially connected nature. All of these factors mean it is very important to think about how your application will send and receive data. Smaller payloads will reduce your costs for bandwidth and storage and may help minimize latency.

Serialization in WCF

WCF ships with 4 different serializers: DataContractSerializer, XmlSerializer, NetDataContractSerializer, and DataContractJsonSerializer. The serializer determines how .NET object are converted into XML. Once serialized, the XML data is then written to the wire as a series of bytes. The process of taking the XML and converting it into a stream of bytes is called encoding. WCF supports the following encoding: Text, Binary, and MTOM. Serialization is controlled by attributes on the service contract. By default the DataContractSerializer is used, this is specified by the ServiceContractAttribute. To use the XmlSerializer, apply the XmlSerializerFormatAttribute to the service contract. The DataContractJsonSerializer is used when the WebGetAttribute or the WebInvokeAttribute is applied to a service operation. Both of these attributes allow you to specify the RequestFormat and ResponseFormat. To use JSON for requests and responses set both of these to WebMessageFormat.Json. In order to use JSON you must use the WebHttpBinding which automatically configures the WebHttpBehavior. For more information about WCF serialization, see: Serialization and Deserialization, Serialization in Windows Communication Foundation. For more information about JSON and WCF see An Introduction to RESTfull Services with WCF, , and Overview of REST in WCF.

Using JSON requires use of WebHttpBinding and WebHttpBehavior which do not support SOAP communication. Services that communicate with the WebHttpBinding do not support exposing service metadata so you will not be able to use Visual Studio’s Add Service Reference functionality or the svcutil command-line tool to generate a client-side proxy. For more information how you can programmatically call services that use WebHttpBinding , see How to Consume REST Services with WCF

Serialization and OData Services

The Open Data Protocol currently supports the following two serialization formats:

  • Atom Syndication Format (Atom): an XML-based exchange format used for Web feeds.

  • JavaScript Object Notation (JSON): a lightweight, human readable data exchange format.

In OData, clients can request the desired serialization format of the response by setting the Accept message header. OData also provides the $format system query option that can be used by clients that are not able to set requests headers. WCF Data Services supports both Atom and JSON serialization formats, but it does not support the $format query option. To support JSON serialization for all possible clients, you should enable support for the $format query option in your WCF Data Services implementation. For more information, see Guidance for OData in Azure.

Serialization Sizes

It usually helps to demonstrate the important differences in serialization sizes by showing the serializations of the same type serialized differentlyThe following is the definition of an example Person type:

    public class Person
        public Person() { }
        public Person(string last, string first, string email)
            lastName = last;
            firstName = first;
            emailAddress = email;

        public string firstName { get; set; }

        public string lastName { get; set; }

        public string emailAddress { get; set; }


The DataContractSerializer serialized an instance of Person as follows:

<?xml version="1.0"?>
    <Person xmlns:i="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://example.org/person">


The XmlSerializer serialized an instance of Person as follows:

<?xml version="1.0"?>
<Person xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">


The DataContractJsonSerializer serialized an instance of Person as follows:



Another area to consider is the message encoder. Encoders take XML and convert it to a series of bytes that can be sent across the wire. This can reduce the size of the payload considerably. Encoders are configured on the binding. For more information about encoders see Choosing a Message Encoder. Microsoft binary encoders will provide the smallest representation of your data, however, it can only be used in scenarios where both the client and the service are running under the .NET Framework. If your application requires interoperability with other platforms, use the text encoder. You can also implement your own custom encoder and perform some sort of compression, for more information see, Custom Message Encoder


The best serializer and encoder to use will depend upon your application and its interoperability needs. For scenarios where the service and client are both running under the .NET Framework consider using the binary encoder and the DataContractSerializer. For scenarios where interoperability is required, use the text encoder. In these types of scenarios the DataContractJsonSerializer will provide the smallest representation, but this requires use of a non-SOAP service. If you need to use SOAP, consider using the DataContractSerializer.

Community Additions

© 2014 Microsoft