What is the best way to transmit Java objects over a network

Question

I am trying to transmit objects of a particular class from one server to another.

The options I'm looking at are:

• Serialize the data as JSON and send it over the wire using HTTP, and de-serialize at the other end.
• Serialize the data into some binary form and transmit using TCP sockets.

What are the best practices in this area? What are the gotchas?

Ideally I would like the interface to be versioned, so the sender and receiver can be upgraded independently.

I'm considering the JSON approach as I already have code that will serialize/deserialize the objects into JSON.

Answer 1

If both ends are written in Java, just use Java's own serialization.

On the other hand, using JSON, XML or YAML will make it easier to debug as what gets transmitted will be readable.

Answer 2

Whenever I needed to transmit Java objects, assuming similar JVM versions, I always used plain Java serialization (Sun official tutorial): it's simpler and you don't have to care about transmit chains of items or aggregates because serialization already cares about it (if you implement it correctly).

So if you want to transmit a complex object made by many sub-objects you don't have to split it, send it and recompose it: you just send the object and it already contains everything that was already included.

EDIT

About RMI: I used it together with serialization and it worked like a charm! I used to develop remote swing (sending JPanels over TCP)..

1. RMI can help you in calling remote methods and obtaining objects from a master server
2. Clients can use serialization (over a different socket) to send back objects or pass them as parameters to RMI invocation, this should be personal preference

Of course I don't know what exactly you want to do but both tools work great and can also be used orthogonally.

Answer 3

Why JSON? That is typically used for web applications.

It would make more sense to make a web service which can return the Java object required. Then you don't need to worry about serializing/deserializing it.

Answer 4

Terracotta (depending on why you're doing it!)

Answer 5

What about Java RMI? JAVA RMI

Answer 6

Some options:

• If you need to do this over public networks, use the json http approach, as you will not run into firewall issues - you can go over port 80
• If your on an intranet the fastest way to do this (from a setup & maintainability point of view) is probably old fashioned Java rmi, which just requires you to define your remote interfaces and connect to an rmi server, you can be up and running in a few minutes and make ongoing changes to your remote objects/services without much fuss. Under the hood this just uses java serialisation
• If your needs are performance sensitive (low latency, high throughput) you could use something like google protocol buffers
• Also check out the Externalizable interface for custom serialisation

Answer 7

You choices are divided between data only solutions and data plus behavior solutions.

For data, you can use JSON or you can use Java's serialization. JSON is simple but you'll have to roll your own class wrappers. Using Java's serialization can work well because the marshalling issues are well-known and handled in a consistent manner. A variation of this would be providing the Java class on both the local and remote systems but if you're doing that you might as well go on and do RMI. RMI is nice because you don't have to write a separate class for the remote end, but you do have watch out for some gotcha's when distributing objects, like making sure you set the Serial ID of the class or having to distribute the exact binary class file to the remote system. You could do it with RPC but if you're going that far, you might as well create a web service and use SOAP.

Answer 8

I'd recommend using Avro with the JSON encoding; you'll get the versioning support you need while still using HTTP and JSON, and you won't have to write the serialization/de-serialization code yourself. See http://hadoop.apache.org/avro/docs/current/spec.html for a concise description of the features of Avro, and drop a note to the mailing list or join the #avro channel on Freenode if you have any troubles getting started.