This page explains how to create a BERSERK storage object.
BERSERK ships with a XML and OJB based persistency.
If you need to store BERSERK's configuration in another way, you must
implement your own storage layer.
introduction
BERSERK's architecture is ready to be extended in many ways.
Storage is just one of the possibilities.
In BERSERK two storage object are used: one to read BERSERK's
filters, chains and services defitions, and another to handle application's
domain data. Obviously they can be instances of the same class, or even the
same instance (if following the Singleton design pattern).
BERSERK's has three logic-layer configuration objects. As stated
before, BERSERK follows a highly generic aproach, providing interfaces to it's
components, without exception, allowing users and developers to implement their
own version.
All that a storage object does is translating a persistent
configuration (from any support) to a logic-layer configuration object,
following the Data Access Object (DAO) design pattern. Thus, in order
to create a storage object, the following interfaces must be implemented:
public interface IPersistentFilterDefinition extends IStorageObject
{
public abstract IFilterDefinition readByName(String name) throws StorageException;
}
public interface IPersistentFilterChain extends IStorageObject
{
public abstract IFilterChain readByName(String name) throws StorageException;
}
public interface IPersistentServiceDefinition extends IStorageObject
{
public abstract IServiceDefinition readByName(String name) throws StorageException;
}
Those methods are responsible for reading each object by it's
name. The underlaying implementation is up to the developer. For an
example of two implemetations, please read BERSERK's code.
If you need to store BERSERK's configuration in another way, you must
implement your own storage layer.
the DAO
BERSERK's logic-layer access a DAO to obtain the needed
configurations. This DAO is specified in berserk.properties file.
Again, any DAO must implement the following interface in order to
be used by BERSERK:
public interface IStorageBroker
{
public IPersistentFilterDefinition getIPersistentFilterDefinition();
public IPersistentServiceDefinition getIPersistentServiceDefinition();
public IPersistentFilterChain getIPersistentFilterChain();
}
The return objects are the storage-layer definitions, described
above.
At this point, you can edit berserk.properties and use the
recently created DAO. BERSERK will callback the implemented methods and use the
desired storage.
Please remember that BERSERK does not obligate
the use of files to read it's configurations. Arbitrary data streams can be
used as long as there is a DAO that translates them to the definitions objects.