Backport of DSpace 2 Storage Services API for DSpace 1.x
Student: Andrius Blažinskas
Mentor: Mark Diggory
Abstract
DSpace 2.0 storage mechanism provides convenient way to store DSpace contents in various storage solutions. It is based on set of interfaces for which various implementations are possible and some beta releases already exist (Jackrabbit, Fedora, etc). DSpace 2.0 is in its early stages of development and DSpace 1.x releases yet can not take advantage of this new mechanism. To fix this, it is necessary to port DSpace 2.0 storage interfaces to 1.x. I propose implementing this backport. – Andrius Blažinskas
Relevant modules/classes
Module/class name |
Description/Comments |
Source code |
|---|---|---|
dspace-api |
DSpace API |
|
dspace-xmlui |
XMLUI (Manakin) |
|
storage-api |
Constitute of DSpace 2 storage interfaces. Will be referenced from dspace-xmlui and other modules which will use new storage mechanism. |
http://scm.dspace.org/svn/repo/modules/dspace-storage/trunk/api/ |
storage-legacy |
Yet non existant module. Module will implement storage-api interfaces. Basically it will be the shim allowing modules to access DSpaceObjects (in dspace-api) using new storage-api. |
- |
dspace-services |
DSpace services module. DSpace services framework will be used to manage and gain access to storage-api implementations. |
|
ProvidedStorageService |
Class which acts as a mediator between caller and storage service implementations. However, its usage is questionable. |
Development plan
- Analysis part:
- Analysis of dspace-api module
- Analysis of dspace-services module
- Deeper review of spring usage in DSpace
- Analysis of dspace-database module
- Analysis of dspace-storage-db-2.0.x module
- Analysis of AIP prototype
- Better dspace-api adaptation to changing needs:
- Evaluation and incorporation of changes described at https://wiki.duraspace.org/display/DSPACE/GSoC+Collaboration+Scratchpad
- Implementation of changes decided during commiter/student meetings
- Implementation of storage-legacy module
- dspace-xmlui relation to storage-api
- Creation of java documentation
...
Backporting strategies
There are different ways to backport dspace-storage into DSpace 1.x, some of these are described here.
Since DSpace 1.x model data is mainly accessed through particular DSpace 1.x entities (Community, Collection, Item, Bundle, Bitstream, BitstreamFormat), new storage mechanism somehow will interact with them. There was a discussions (during IRC meetings) on whether DSpaceObjects should be backed by dspace-storage or is it something what should be "covered over" by dspace-storage.
- Backing DSpaceObjects by dspace-storage allows immediate effect since all current modules uses these entities. However, this approach also involves changing internals of these entities, which opens possibility to introduce bugs affecting everything. This way created storage-legacy module would probably have to overtake the most DSpaceObjects internals, which also quite is coupled with dspace-api.
- DSpaceObjects "cover over" by dspace-storage, if correctly implemented, is a cleaner choice, since changes in dspace-api can be avoided. storage-legacy module in this case would act only as a shim, providing access to dspace-api through storage-api. Conceptually, such solution probably is bad (storage logics should reside in storage-legacy), however it is a good "temporary" measure helping in moving DSpace 1.x to using new storage mechanism.
Proposed solution
Shim or "cover over" solution is chosen as backporting strategy. Diagram below describes it in more detail.
Elements in red are yet to be implemented.
Evolution of storage-api
Changes pending...
References
GSOC 2010 proposal: Backport of DSpace 2 Storage Services API for DSpace 1.x, http://ab.labt.lt/gsoc/2010/dspace/proposal1.html
