Problem

When you have an object graph that consists of objects that were created by different bundles, serializing and deserializing such a graph becomes a problem, since there is no single bundle that can "see" all (implementation) objects in the graph.

The problem manifests itself for example in Apache Wicket, but also in other applications. The serialization framework is a solution to this problem.

Design discussion sketch

Made at ApacheCon EU 2009, Robert, Martijn, Felix and Marcel produced the following design on the flipover:

Service design

Basically, we need two services:

1. The serialization service, that can serialize and deserialize an object graph to an output or input stream.
2. Helpers that are used to (de)serialize specific objects.

Serialization Service

interface SerializationService {
    void serialize(Object o, OutputStream s) throws IOException, UnknownObjectException;
    Object deserialize(InputStream s) throws IOException, UnknownObjectException;
}

The actual implementation of this service determines how objects are serialized.

Serialization Helper

interface SerializationHelper {
    // TODO
}

We also discussed adding a special manifest header to a bundle to create a sort of declarative serialization helper. That way the bundle does not need to implement and register the service (if all of them use the same helper anyway).

Helpers in some way need to be linked to a specific serialization service (using an XML serialization with a JSON helper will probably not be what you want).