Editing Serialization (section)

==Uses==
Uses of serialization include:
* serializing data for transfer across wires and networks ([[messaging]]).
* storing data (in [[database]]s, on [[hard disk drive]]s).
* [[remote procedure call]]s, e.g., as in [[SOAP]].
* distributing objects, especially in [[component-based software engineering]] such as [[Component Object Model|COM]], [[CORBA]], etc.
* detecting changes in time-varying data.

For some of these features to be useful, architecture independence must be maintained. For example, for maximal use of distribution, a computer running on a different [[hardware architecture]] should be able to reliably reconstruct a serialized data stream, regardless of [[endianness]]. This means that the simpler and faster procedure of directly copying the memory layout of the data structure cannot work reliably for all architectures. Serializing the data structure in an architecture-independent format means preventing the problems of [[byte ordering]], memory layout, or simply different ways of representing data structures in different [[programming language]]s.

Inherent to any serialization scheme is that, because the encoding of the data is by definition serial, extracting one part of the serialized data structure requires that the entire object be read from start to end, and reconstructed. In many applications, this linearity is an asset, because it enables simple, common I/O interfaces to be utilized to hold and pass on the state of an object. In applications where higher performance is an issue, it can make sense to expend more effort to deal with a more complex, non-linear storage organization.

Even on a single machine, primitive [[pointer (computer programming)|pointer]] objects are too fragile to save because the objects to which they point may be reloaded to a different location in memory. To deal with this, the serialization process includes a step called ''[[unswizzling]]'' or ''pointer unswizzling'', where direct pointer references are converted to references based on name or position. The deserialization process includes an inverse step called ''[[pointer swizzling]]''.

Since both serializing and deserializing can be driven from common code (for example, the ''Serialize'' function in [[Microsoft Foundation Classes]]), it is possible for the common code to do both at the same time, and thus, 1) detect differences between the objects being serialized and their prior copies, and 2) provide the input for the next such detection.  It is not necessary to actually build the prior copy because differences can be detected on the fly, a technique called differential execution. This is useful in the programming of user interfaces whose contents are time-varying&nbsp;— graphical objects can be created, removed, altered, or made to handle input events without necessarily having to write separate code to do those things.