The Object-Oriented Thought Process Chapter 12 Persistent Objects: Serialization, Marshaling & Relational Databases

Persistent Objects The concept of saving the state of an object so that it can be used later is called persistence. Thus, we used the term persistent object to define an object that can be restored and used independently of a single application perhaps a database. Because the object is in persistent storage, other applications can access it.

Saving an Object to a Flat File One of the issues you might have considered is that an object cannot be saved to a file like a simple variable. The problem with an object is that it is not simply a collection of primitive variables. An object can be thought of as an indivisible unit that is composed of a number of parts. Thus, the object must be decomposed into a unit that can be written to a storage medium such as a flat file.

Decomposed & Reconstituted An object must be decomposed into a unit that can be written to a storage medium such as a flat file. After the object is decomposed and written to a flat file, there is one major issue left to consider - reconstituting the object, basically putting it back together.

Flat Files Many people are not totally comfortable with the term flat file. The word flat implies that the object is literally flattened, and in a way it is. You almost can think of this flattening process as necessary to store and transport an object, regardless of its complexity.

Serializing a File Modern languages have built-in mechanisms for object persistence. For example, like other C-based languages, Java often uses the concept of a stream to deal with I/O. To save an object to a file, Java writes it to the file via a Stream. To write to a Stream, objects must implement either the Serializable or Externalizable interface.

Implementation and Interface Revisited Serializing a file is yet another great example of the difference between the interface and the implementation. All you care about is the following: That you can write the object as an indivisible unit. That you can restore the object exactly as you stored it.

What About the Methods? In the case of the Java serialization example, the methods are not explicitly stored. Remember that we indicated that Java had to be at both ends of the “pipe.” In actuality, the class definitions that you are using have to be on both ends of the “pipe” as well.

Using XML in the Serialization Process Although using a proprietary serialization technique may be efficient and compact, it is not portable. XML is the standard for defining data, so we can create an XML model of our serialization example that can, at least theoretically, be used across various platforms and languages.

Writing to a Relational Database Although relational databases are a wonderful technology, they provide a bit of a problem when it comes to interfacing with objects. Just as with the issue of writing to a flat file, taking an object that may be composed of other objects and writing it to relational databases, which are not designed in an object-oriented manner, can be problematic.

Legacy Data Legacy data may be decades of data that are stored in various storage devices. We consider legacy data to be the historical data stored in relational databases. Many people don’t like the term “legacy” because they think it implies obsolete. In fact, important legacy data is not obsolete but an important part of the system.

Object-to-Relational Mapping A piece of software that resides between object-oriented applications and relational databases is often called middleware. As an example, let’s use Java to communicate to a Microsoft Access database, which is a relational database. Java uses JDBC (Java Database Connectivity) to communicate with database servers.