Giovanni Azua wrote:
I have this lite Client-Server framework based on Blocking IO using classic
java.net.* Sockets (must develop it myself for a grad course project). The
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 would
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 their
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 hard
numbers to judge though. I remember JBoss Middleware implementation having
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 structures to restore, so all knowledge has to reside in the serialization format.
Circular dependencies, inheritance chains, the whole megillah has to be encoded 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 *data* you wish to transfer. This assumes knowledge on both ends of the structures used to hold the data, unlike object serialization, hence much less information must flow between the participants.
Use JAXB to generate the classes used to process that schema and incorporate 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 structures 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.
on format etc. - can be less verbose. See http://json.org/example.html