How to create a complete custom store

This is a small introduction on what is necessary to create a full custom store from the implementation view. Naturally, this explanation is incomplete as this is a very complex task and highly depends on the physical store you want to interface Slide to.

Anyway, looking at your store this way you have to specify six interfaces - and an optional one - for a complete store definition. Additionally, you will need to implement an XAResource to let your store participate in a distributed transaction. This interface is specified by the JTA and is needed by Slide's internal transaction manager which also is more or less compliant to the JTA. Slide also requires the implementation of org.apache.slide.common.Service. I'd recommend to start from AbstractServiceBase as it sensibly implements many of the methods in Service interface.

Where to go from there highly depends on what you want to do. In any case you will have to implement all interfaces or supply implementation for all of them for a complete store definition. This means when you want to interface Slide to you proprietary store/CMS/whatever and you want all data to be stored there you will have to adapt all Slide stores to yours.

You may think I do not need security and I am not interested in Locking etc., but only in content, so I simply implement the ContentStore interface. This will not work, as you might not be interested in those features, but Slide needs them in any case. What you can do is implement the interface for content only and store the additional data to the file system or a relational databse. Note that in this case you will have half your data in your proprietary store and half of your data somewhere else. This is pretty ugly when you think of backups, recovery and the restoring of past states. Maybe this can make sense when your system uses a relational database and you combine it with the relational database store delivered with Slide, but I have never tried this.

Another possibility is to store the content natively to your system, but use the XML serialization feature also used by Slide's default store TxXMLFileDescriptorsStore. This way you will have two objects stored in your system, one for content and one for all descriptors set in NodeStore, LockStore, RevisionDescriptorsStore, RevisionDescriptorStore and SecurityStore. Recent versions allow you to reuse this feature. Have a look at XMLResourceDescriptor that inherits from AbstractXMLResourceDescriptor to store the XML into the transactional filesystem. Inherit from AbstractXMLResourceDescriptor yourself to store the data into your own system.

The Store Interfaces

RevisionDescriptorStore

ContentStore

RevisionDescriptorsStore

NodeStore

SecurityStore

LockStore

SequenceStore

Implementing a reasonable XAResource

For all store implementations it is mandatory to implement the JTA interface XAResource. This is necessary to take part in transaction spanned by every WebDAV request done to Slide. If this is a good idea or not is not the subject of this small paragraph. Anyway, implementing a reasonable XAResource from scratch is a very troublesome and tedious thing to do, even if you have already implemented one before. I'd rather propose to use the AbstractXAResource from the commons transaction component. This has been done in recent versions of the database stores. The great transactional memory stores do this indirectly by using the transactional maps from the same component. Those maps use the the AbstractXAResource as well.

(OZ)

IntroFullCustomStore (last edited 2009-09-20 22:02:39 by localhost)