Re: Low-latency alternative to Java Object Serialization
Giovanni Azua wrote:
I have this lite Client-Server framework based on Blocking IO using class=
ic
java.net.* Sockets (must develop it myself for a grad course project). Th=
e
way I am using to pass data over the Sockets is via Serialization i.e.
ObjectOutputStream#writeObject(...) and ObjectInputStream#readObject(...)=
I
was wondering if anyone can recommend a Serialization framework that woul=
d
outperform the vanilla Java default Serialization?
Three years ago I worked for a "high frequency trading" company and they
avoided default Java Serialization like "the devil to the cross" this is =
a
Spanish idiom btw ... :) due to its latency. However, I must say that the=
ir
remoting framework dated back to the Java stone age and my guess is that =
the
default Serialization must have improved over the years; I don't have har=
d
numbers to judge though. I remember JBoss Middleware implementation havin=
g
some Serialization framework for this very same reason ... have to check
that too.
Can anyone advice what would be best than Java Serialization without
requiring an unreasonably heavy dependency footprint?
Side bar: What exactly do you mean by "latency" here?
Serialization assumes no knowledge on the restoring end about the structure=
s to restore, so all knowledge has to reside in the serialization format.
Circular dependencies, inheritance chains, the whole megillah has to be enc=
oded into the serialized stream.
Serialization is designed to store and restore object graphs, not the data =
in them.
Take a page from web services and create an XML schema to represent the *da=
ta* you wish to transfer. This assumes knowledge on both ends of the struc=
tures used to hold the data, unlike object serialization, hence much less i=
nformation must flow between the participants.
Use JAXB to generate the classes used to process that schema and incorporat=
e those classes into the protocol at both ends.
Fast, standard and fairly low effort and low maintenance, assuming you have=
version control and continuous integration (CI).
By "fast" I mean both to develop and to operate.
You will write custom code to jam the data into your JAXB-generated structu=
res and retrieve them therefrom.
But you will be transmitting data via a format that omits the object graph =
overhead and focuses on just the data to share. The object-graph knowledge=
is coded into the application and need not be transferred.
XML is awesome for this kind of task.
--
Lew