This blog has moved. Please update your bookmarks.

Nightmares on Serialization Street

Serialization is the process of taking an object, and streaming the contents of that object into a file, or communications channel, or any other form of media; and then rebuilding that object on the other side, so that it takes up the exact same representation as it did on the sender side. Think of it as a Star Trek teleportation device, but for data objects - the data objects being represenations of invoices, computer commands, telephone extensions or more complex forms of data.

Delphi has this for TComponent objects, but not for anything else. So I've had to build a complete serialization layer, using such fancy classes and interfaces such as ISerializable, TSerializeBuffer, TSerializeObjectHelperRTTI, TSerializeObjectHelperNoElements, TXmlInterfaceSerializer (which isn't complete), all available through functions like SerializeObject, UnserializeObject and PeekSerializedClassName, through heavy use of variants and run-time type information.

To further agonize over this, this is but one part of the problem. We're building server flashes into our system, meaning that a specific information-gathering part of our programs can run in three different ways: 1) through normal execution, 2) threaded execution to provide application responsiveness even though a task is executing, and 3) a server-based remote object call, placing the heavy burden on the server instead of the client.

I don't know how this happened, but somehow, I find myself building a complete client/server-based remoting layer into a language that doesn't have it; and interfacing that remoting layer with dynamic fail-over to local methods in case the link goes down.

Isn't this what the wizards at Sun or Microsoft are supposed to be doing?


At 5:56 PM, Anonymous Markus said...

MyObject o = new MyObject();
FileOutputStream fos = null;
ObjectOutputStream out = null;
fos = new FileOutputStream(objectOnDisk);
out = new ObjectOutputStream(fos);

Time passes...

fis = new FileInputStream(objectOnDisk);
in = new ObjectInputStream(fis);
o = (MyObject) in.readObject()

(Exceptions and declarations omitted for readability)

To be honest, I seldom use serialization directly. I have used it extensively with EJB:s.

Your objects have to implement Serializable. They can contain primitive types, or other objects also implementing Serializable. Non-serializable fields has to be marked as transient.

For remoteing we have RMI. Pretty powerful stuff.

At 7:21 PM, Blogger Mats Gefvert said...

For a typical example of how our components work, check out this page. :)

I must say I'm a little bit proud. Nevertheless, it probably already exists in some Delphi-Enterprise-Architect-CORBA version, but this one is mine. And I think it looks neat. :)


Post a Comment

<< Home


Blog contents copyright © 2005 Mats Gefvert. All rights reserved.