UPDATED: Something like Hessian – http://hessian.caucho.com/ – would have been exactly what I was looking for to send binary data over HTTP.
I recently had the need to send an object model from an applet back to the server. The model was rather complex and what might have been normal in the office, would have been to marshal the data into an XML document and send it to a SOAP interface.
But that’s rather excessive and would take quite some time to develop (think generating XML definitions, JAXB, generating a web service and some WSDL, then the web service clients, yawn, yawn).
So I had a quick think about what I wanted to achieve.
- I wanted some data to be sent from the client to the server.
- I wanted to develop it quickly too (so no time for research and the trials of software selection).
- It had to be HTTP friendly as well, since I am paranoid about opening ports on my public servers.
So I wondered about serialising the model and sending it to a simple servlet where it could be stored into a database as a BLOB. If necessary (which was later to become the case) I would also be able to deserialise the model server side and extract some data from it.
The only problem I faced was whether I could send binary data (the serialised data) over an HTTP request? To be on the safe side, and to avoid worrying about things like MIME types, I took the serialised data as a byte array and transcoded it into a delimited string of numbers. Each byte has a value from 0 to 255. The delimiter I chose was an arbitrarily chosen pipe character, |
UPDATE: I could have used some kind of UUEncoding to convert from 8 bit to 7 bit to ensure it would go across HTTP. Didn’t think of that at the time though!
Two quick encode/decode methods later, implemented in a handy helper class and I was up and running.
What I had not thought of, was the fact on the client side any number of Java Virtual Machines (JVM) could be serialising the data. What I mean here is that any version of a JVM (above 1.3, which I specified as the minimum requirement for the applet to ensure the largest number of users would not require a JRE install / upgrade) could be in action client side. Server side I don’t even have the latest version of Java, so I was suddenly reliant on serialisation being both forward and backward compatible between Java versions. However, having tested with 1.3, 1.4, 1.5 and 1.6 it all seems to work. The clients serialise the model, send it to the server where its deserialised and later request other models which are serialised server side and deserialised client side. It all seems to work error free so far!
What I have basically implemented is a very quick REST server. Instead of using something like JSON or XML to send the data I just used an HTTP friendly version of a serialised model, otherwise known as a string.
One advantage I have over things like XML and JSON is that I don’t require any libraries to handle the data (which reduces the applet download / start time). Another advantage is that the data is verified against its data structure, which is not the case in JSON (where there is no schema definition) and which is not guaranteed in XML (where the data does not have to be checked against data type / schema definitions during binding/unmarshalling).
What’s the disadvantage? Well its huge. The data is not platform independent! I am limited to having both a Java client and server. Luckily Java is platform independent, but that doesn’t really solve the problem, does it.
The lesson here is the same lesson being taught with other REST paradigms, namely that you don’t need to go the whole hog and implement an XML / SOAP stack in order to implement an RPC Service. KISS – "Keep it Simple Stupid".
Leave a Reply