USING XML FOR OBJECT PERSISTENCE
Application development often involves the creation of many objects. 
These objects represent various pieces of data for a particular 
application. A common problem that developers face when using objects 
is how to persist the information an object contains when the object is 
not in use. One option is to simply keep the object stored in RAM and 
use it when needed, but that's an inefficient method that won't work 
for very large systems. A better approach is to store the object 
somewhere else, such as a database, until it's needed again--at which 
point it can be pulled from storage and used.

SERIALIZATION
The process of taking a binary object, for example an Enterprise Java 
Bean (EJB) or a COM object, and storing it is sometimes called 
serialization. The reason is that serialization involves examining the 
data stored by an object and converts it into a series of smaller 
chunks that identify where they belong in the object.

There are a number of ways to accomplish serialization. One option is 
to store the data in database tables and records. In this case, the 
object converts into a series of fields and records that are stored in 
the database system. This option can be useful if you need to access 
the fields directly from the database. The downside is that any changes 
to the structure of the object must also be reflected in the database 
tables. If you decide to split the Address member into StreetNumber and 
StreetName in the object, then you must do the same in the table that 
stores these values. Of course, you could store StreetNumber and 
StreetName in the Address field in the database, but when you retrieve 
the object from the database, you won't know which part of the Address 
field to put into StreetNumber and which part to put in StreetName.
Structure complications

Another complication with using direct tables and fields in a database 
is that object structures can sometimes be very complex. Take, for 
example, a customer object. This object may contain other objects such 
as an address object, an account object, or an orders object. The 
orders object may contain a set of order objects, which in turn contain 
a set of item objects. It would be very difficult to have a system that 
understands all of these intricacies and have it reliably store each 
piece of data in the correct field. Further, it might also be a slow 
performer because each piece of data needs to be stored separately.
State and persistence

An important thing to remember about object persistence is state. State 
is the value of the data stored in an object at a particular instance 
in time. Right now, the customer may live at a particular address. 
Tomorrow, they may move to a new address. This represents two different 
states for the customer object. Both can be persisted, but only one of 
them is the current state. By keeping a history of the persistence of 
an object, you can observe how the object has moved from state to state 
and audit the changes.

XML TO DB
A better approach than putting the data directly into the database 
fields as separate pieces of data is to use XML. The reason is that XML 
provides a robust and extensible architecture for describing data. In 
your database, rather than creating multiple tables and myriad fields, 
create a single table for your objects. In that table, you'll have only 
a handful of fields. You'll need a key field that uniquely identifies 
each object you want to persist. You'll also need a timestamp that 
tells you not only when an object was persisted, but also which is the 
most current version (or state) of the object. Finally, you'll need a 
field to store an XML string representation of the object.

SERIALIZING XML
Once you've created your database, storing and retrieving your objects 
is a matter of serializing them to XML strings and un-serializing them 
back to objects. A common approach is to use a persistence object for 
storing and retrieving the objects. The persistence object is 
responsible for understanding how to break apart the object's data into 
XML data and for knowing how to store and retrieve the XML to and from 
the database. Your application then uses the persistence object to 
store application objects or to reanimate them from the persistence 
repository.

Brian Schaffner is a senior consultant for DMR Consulting, a Fujitsu 
company. He provides architecture, design, and development support for 
DMR's Telcom360 group.

------------------------------------------