The StorageManager encapsulates the access to persistent data objects and uses a realisation of the StorageEngine interface to interact with the data source. As shown in Figure 7 , the StorageEngine interface requests the four basic functions to create, read, update and delete data objects (CRUD).
In contrast, the storage manager provides an extended version of the CRUD methods and would also allow to cache data to prevent continuous updates while using data sources which cannot store data on object level.
Persistent objects have to implement the DataObject interface shown in Figure 8 . It demands for an universally unique identifier which is used for the identification of persistent objects as for example in XML documents. Not all persistent storage engines need such an identifier but anyway it simplifies the use of different storage engines.
We decided to use db4objects as the primary storage container which is an object oriented database and among others available under the GPL license. The class db4oStorageEngine implements the StorageEngine interface and realises the access to db4objects.
The second storage engine is implemented in the class XMLStorageEngine and serialises the data objects into an XML document. For the serialisation process we use the open source library x-stream which is able to serialise/deserialise arbitrary Java objects and therefore enormously simplifies the implementation.
To support the transformation of different persistent data sources we can instantiate two instances of the storage manager with different storage engines and copy data from one to the other data source.