views:

65

answers:

2

I'm considering message serialization support for spring-integration. This would be useful for various wire level transports to implement guaranteed delivery, but also to allow interoperability with other messaging systems (e.g. through AMQP).

The fundamental problem that arises is that a message containing Java object in it's payload and headers should be converted to a byte[] and/or written to a stream. Java's own serialization is clearly not going to cut it because that is not interoperable. My preference would be to create an interface that allows the user to implement the needed logic for all Objects that take part in serialization.

This means I don't want to require the client developer to generate his domain code, but rather define a serializer for objects that need it. The interfaces would be something like:

public interface PayloadSerializer<T> {
    byte[] bytesForObject(T source);
    T objectFromBytes(byte[]);
    //similar methods for streaming potentially
}

//add HeaderSerializer, MessageSerializer

Is this a sensible idea and what would the perfect interface look like? Is there a standard interoperable way to serialize Objects that would make sense in this context?

A: 

I would try to serialize the java objects into a XML representation and convert this into a byte array for stream I/O.

stacker
Users might resort to that in the end, but I don't want to force them, so if there are other options I want them to work with the interface too... The main consideration is API design, although working use cases are an essential part of it.
iwein
+2  A: 

There is a whole set of frameworks in java which generate XML, like JaxB, ... Now some of these formats might just as well be binary blobs and are difficult to use from other platforms, so it pays to try before you buy. There are also very easy to use XML serializers.

JSON is very popular nowadays because it gives easy interop with the browser and it is readable ad less verbose than XML.

Protocol Buffers and Thrift are popular when performance is important. These are binary formats but well specified and well supported on multiple platforms.

Peter Tillemans
I've looked into Thrift, but I didn't find the thing I was looking for nicely isolated, so that it would make sense to depend on that from the framework. Protocol Buffer also looks nice, but it seems to suffer from the same old RPC virus. I want to expose an interface that converts an object to a byte[], not a code generator. OXM is a different beast I think, it's very interoperable, but less useful for storage.
iwein
JSon is getting to be very popular these with direct support from the new batch of NoSQL databases for efficient storage, like MongoDB and CouchDB. GSon, FlexJson and Jackson come recommnded here : http://stackoverflow.com/questions/338586/a-better-java-json-library
Peter Tillemans
Lot's of useful info, thanks! I'm not buying the answer yet b/c I am convinced that even though JSon or XML are viable options, the contract should be on byte[] and/or a *Stream.
iwein