The purpose of the event persistency service is the delivery of transient event data objects which originally reside as their persistent representation in the persistent data store and the storage of transient data objects in their persistent representation. This requires the following basic functionality for the creation of the transient representation of objects:
- given an identifier, the service locate the object in the persistent world,
- find the proper converter being able to create the transient representation from the identifier,
- invoke the object conversion using this converter and finally
- deliver the requested object to the client.
The object identifier needs only to be interpreted by the converter. There is no need to use this identifier anywhere outside the converter. If it is known in advance that not single objects are needed, but instead complete (sub) trees or parts of (sub) trees of data the service can be configured:
- trees or list of objects existing in every event may be specified to the persistency service.
These identifiers are independent of the database impementation.- on request the persistency data service can restore a transient representation corresponding to the objects specified. The client then receives multiple objects in one step.
The population of the persistent data store requires slightly different functionality:
- the service is given transient objects,
- find the proper converter being able to create the persistent representation of the received object,
- invoke the object conversion using this converter,
- the persistency service must be able to accept commands:
- which transient objects need conversion to a persistent representation
- converters being able to create persistent representations must be assigned to the service either one by one or in form of a factory.
Converters are given to the Persistency service at run-time and hence have to provide a common interface in order to be useful to the persistency service. The converters know about the mechanism to retrieve persistent objects (e.g. from ZEBRA, Objy, …) and pass abstract instances of the converted objects, hence shielding the service from all details. The choice which converter is able to convert a specific instance is achieved by interrogating availible converters using unique run-time independent class identifiers.
Initialisation:
A priori concrete converters are not known to the Persistency service. The must be given to the service either by a converter factory for collections of converters or by passing individual converters.The event data persistency provides two interfaces: