Exploring the Serialization Options in WCF
Serialization is nothing but the process of converting the state of an object into a format that can be either persisted to disk or transmitted over the wire. On the flip side, deserialization is the process of converting an incoming stream, which is either read from disk or read over the wire to an object in memory. Collectively, this allows data to be stored and transmitted with relative ease.
This is all good, but why serialize in the first place? Serialization is a key aspect of any distributed technology, and .NET is no different. For example, in an ASP.NET application, you can use serialization to save the session state to the configured medium (that is, memory, state server, or database). One of the main problems that serialization solves for you is interoperability with other systems and platforms. Serialization is not a new concept, but it is an important one because without serialization, it would be difficult to support interoperability between various platforms. Since XML serialization converts the object or data structure at hand to an architecture-independent format, you do not encounter issues with different programming languages, operating systems, and hardware such as memory layout, byte ordering, or even that different platforms represent data structures differently.
The .NET Framework features two options for serializing objects—binary and XML serialization. The primary difference between the two is that binary serialization allows you to maintain type fidelity, whereas XML serialization does not. In other words, type fidelity allows for preserving the "complete state" of an object including any private members of the object. However, by default, XML serialization will serialize only the public fields and properties of the object. If, for example, you need to pass an object "by value" across either machine or domain boundaries, then you would need to use binary serialization. You can use binary serialization only when both the runtimes and platforms on either end of the stream are the same; this is because the platforms know how the type is represented internally in memory. If this is not the case, then the object would not be able to deserialize on the other end. XML serialization, as the name suggests, uses XML and as a result is a better choice for sharing data across different platforms or the Internet.
In .NET by default only primitive types (such as integers) are serializable, and there is no need for any additional steps to serialize these primitive types. Since the .NET runtime has no knowledge of complex types, these are not serialized by default, and the .NET runtime needs more information about how these types should be serialized. Because each operation in a WCF service needs to either consume or generate data, which is transmitted over the wire, in WCF it is important that every type is correctly serialized.
NOTE
The ability to serialize an object can be enabled only when writing the code; in other words, serialization is a design-time feature. If this was not enabled at design time for an object, then that object cannot support serialization at runtime. The ability to serialize an object cannot be switched on at runtime in an ad hoc manner. Also note that serializing and deserializing are sometimes also known as hydrating and dehydrating.
WCF (being part of .NET 3.0) not only supports the serialization options available in .NET but also adds a few new ones. A data contract is the default option among all the following available options:
Serializable attribute/ISerializable interface
Data contracts
XML serialization
Message contracts
Message class