Serialization

: See serial for the term in publishing. In an older computer science context serialization means to force one-at-a-time access for the purposes of concurrency control. For example, a single-threaded Active X server can process only one request at a time; thus requests are queued and executed in the order made.

In a more modern computer science context serialization is the process of saving an object onto a storage medium (such as a file, or a memory buffer) either as a series of bytes or in some other human-readable format. It is also known as deflating an object or marshalling an object. Later the series of bytes or the format can be used to re-create an object that is identical to the original object (its clone, if you will). This type of serialization is used mostly to transport objects (remoting), to persist objects to a file or database, or to distribute objects.

The opposite operation, extracting a data structure from a series of bytes, is deserialization (which is also referred to as unmarshalling or inflating).

Serialization involves taking a data structure or object (computer science) and encoding it into a regular and usually architecture-independent form, suitable for archiving to a file, pipes and filters to another application, or, by extension, transmission across a network. Usually the encoding takes the form of a byte stream (a sequence of bytes). When receiving a serialized stream, the encoding process is reversed to get a copy of the original data structure.

= Uses =

Serialization has a number of advantages. Serialization provides:

a simple and robust way to make objects persistence

a method of issuing remote procedure calls, as in e.g. SOAP

a method for distributing objects, especially in software componentry such as Component Object Model, CORBA etc.

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 that we do not suffer from the problems of byte ordering, memory layout, or simply different ways of representing data structures in different programming languages.

Serialization however, in some forms, has the disadvantage that since the encoding of the data is serial, merely extracting one part of the data structure that is serialized means that the entire object must be reconstructed or read before this can be done. The serialization capabilities in the Cocoa (API) framework, NSKeyedArchiver, alleviate the problem somewhat, by allowing an object to be archived with each instance variable of the object accessible by using a key.

Even on a single machine, primitive 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 and the deserialization process includes a step called pointer swizzling .

= Consequences =

Serialization, however, breaks the opacity of an abstract data type by potentially exposing private implementation details. To discourage competitors from making compatible products, publishers of proprietary software often keep the details of their programs serialization formats a trade secret. Some deliberately obfuscation or even encrypt the serialized data.

Yet, interoperability requires that applications be able to understand the serialization of each other. Therefore remote method call architectures such as CORBA define their serialization formats in detail and often provide methods of checking the consistency of any serialized stream when converting it back into an object.

= Human-readable serialization =

In the late 1990s, a push to redefine, or provide an alternative to the standard serialization protocol that uses XML and produces a human readable encoding started. Such an encoding could be useful for persistent objects that may be read and understood by humans, or communicated to other systems regardless of programming language, but this has the disadvantage of losing the more compact, byte stream based encoding, which is generally more practical.

= Programming language support =

Several object-oriented programming languages directly support object serialization (or object archival ), either by syntactic sugar elements or providing a standard interface (computing) for doing so.

Some of these programming languages are Smalltalk, Python programming language, Objective-C, Java programming language, and the Microsoft .NET family of languages.

== Objective-C ==

In the Objective-C programming language, serialization (most commonly known as archival ) is achieved by overriding the write: and read: methods in the Object root class. (NB This is in the GNU runtime variant of Objective-C. In the NeXT-style runtime, the implementation is very similar.)

=== Example ===

The following example demonstrates two independent programs, a sender , who takes the current time (as per [http://www.opengroup.org/onlinepubs/007908799/xsh/time.html time] in the C standard library), archives it and prints the archived form to the standard output, and a receiver which decodes the archived form, reconstructs the time and prints it out.

When compiled, we get a sender program and a receiver program. If we just execute the sender program, we will get out a serialization that looks like: GNU TypedStream 1D@îC¡ (with a NULL character after the 1). If we pipe the two programs together, as sender | receiver, we get received 1089356705 showing the object was serialized, sent, and reconstructed properly.

In essence, the sender and receiver programs could be distributed across a network connection, providing distributed object capabilities.

==== Sender.h ====

#import #import #import @interface Sender : Object { time_t current_time; } - (id) setTime; - (time_t) time; - (id) send; - (id) read: (TypedStream *) s; - (id) write: (TypedStream *) s; @end

==== Sender.m ====

#import Sender.h @implementation Sender - (id) setTime { //Set the time current_time = time(NULL); return self; } - (time_t) time; { return current_time; } - (id) write: (TypedStream *) stream { /*

Write the superclass to the stream.

We do this so we have the complete object hierachy,

not just the object itself.

*/ [super write:stream]; /*

Write the current_time out to the stream.

time_t is typedef for an integer.

The second argument, the string i , specifies the types to write

as per the @encode directive.

*/ objc_write_types(stream, i , ¤t_time); return self; } - (id) read: (TypedStream *) stream { /*

Do the reverse to write: - reconstruct the superclass...

*/ [super read:stream]; /*

And reconstruct the instance variables from the stream...

*/ objc_read_types(stream, i , ¤t_time); return self; } - (id) send { //Convenience method to do the writing. We open stdout as our byte stream TypedStream *s = objc_open_typed_stream(stdout, OBJC_WRITEONLY); //Write the object to the stream [self write:s]; //Finish up - close the stream. objc_close_typed_stream(s); } @end

==== Sender.c ====

#import Sender.h int main(void) { Sender *s = [Sender new]; [s setTime]; [s send]; return 0; }

==== Receiver.h ====

#import #import Sender.h @interface Receiver : Object { Sender *t; } - (id) receive; - (id) print; @end;

==== Receiver.m ====

#import Receiver.h @implementation Receiver - (id) receive { //Open stdin as our stream for reading. TypedStream *s = objc_open_typed_stream(stdin, OBJC_READONLY); //Allocate memory for, and instantiate the object from reading the stream. t = [[Sender alloc] read:s]; objc_close_typed_stream(s); } - (id) print { fprintf(stderr, received %d , [t time]); } @end

==== Receiver.c ====

#import Receiver.h int main(void) { Receiver *r = [Receiver new]; [r receive]; [r print]; return 0; }

== Java ==

Java provides automatic serialization which requires only that the object be marked by implementing the java.io.Serializable interface. For reasons that are not clear, this interface functions in an idiosyncratic way. Implementing the interface just marks the class as okay to serialize, and Java then handles serialization internally. There are no serialization methods defined on the Serializable interface, but the class can optionally define methods with certain special names and signatures, and they will be called as part of the serialization/deserialization process if defined. The language also allows the developer to override the serialization process more thoroughly by implementing another interface, the Externalizable interface, which includes two special methods that are used to save and restore the object s state.

The standard encoding method uses a simple translation of the fields into a byte stream. Primitives as well as non-transient, non-static referenced objects are encoded into the stream. Each object that is referenced by the serialized object and not marked as transient must also be serialized; and if any object in the complete graph of object references is not serializable, then serialization will fail. The developer can influence this behavior by marking objects as transient, or by redefining the serialization for an object so that the some portion of the reference graph is truncated and not serialized.

== ColdFusion ==

ColdFusion allows data stuctures to be serialized to WDDX with the [http://livedocs.macromedia.com/coldfusion/6.1/htmldocs/tags-c20.htm ] tag.

= External Links =

For Java: *[http://java.sun.com/j2se/1.4.2/docs/guide/serialization/spec/serialTOC.html Java Object Serialization Specification] *[http://www.macchiato.com/columns/Durable4.html Durable Java: Serialization] *[http://rpbourret.com/xml/XMLDataBinding.htm XML Data Binding Resources]