Refactoring the DSpace Domain Model

Introduction

To continue evolving towards DSpace 2.0 goals this year, @mire will continue to provide further refactorings of the DSpace legacy codebase. These refactoring efforts are focused now on resurrecting and completing the the DAO prototype work of past Hewlett Packard developer, James Rutherford. This work includes efforts to separate the legacy DSpace codebase into a separate Domain Model and Data Access Services. Once integrated into DSpace 1.8, new DSpace Services for legacy DSpace objects will provide a common API for both the DSpace Application tier and external addon modules.

Separating Domain Model from Data Access Services

Historically, application developers have struggled with presence of both state-full and stateless data access methods residing on the same concrete classes of the DSpace domain data model (Item, Bitstream, etc). Sepa- ration of the data access ORM implementation completely from the domain data model will allow applications to rely on those data models without being bound contractually to a specific implementation. With the application tier of DSpace no longer bound directly to the data access tier, DSpace application developers will gain an ability to provide their own customized implementation of business and data access services, reducing the need to di- rectly alter core DSpace data model classes or resort to the ugly practice of classpath overrides.

API Contracts for the DSpace Domain Model

Extraction of the DSpace Data Model as an API from the DSpace core libraries provides a contract for application developers to rely on when developing enduser applications for DSpace. Additional API on core DSpace busi- ness and data access services (workflow and data access) will assure that applications can rely on these serv- ices contractually while the underlying implementations are improved and alternate implementations begin to emerge. Past prototyping in the DSpace 2.0 and GSoC projects have verified that once properly restructured integration with alternative storage implementations including options such as Fedora, JCR Repositories, Dura- Cloud and Semantic Storage systems such as Tupelo will be greatly eased.  An initial Prototype of this API now resides in the dspace-model project and we will be providing JIRA tasks and patches to trunk that will reflect what are some relatively minor changes to the org.dspace.content and core packages to support it.

Preparing DSpace for Integration with Fedora

Given that these changes will open the door for DSpace to be capable of supporting multiple alternate underlying implementations, @mireʼs work in refactoring DSpace in this area will set the stage for integration with Fedora.

Based on recent work by Google Summer of Code students in prototyping integration with Fedora, the tractability of combining the applications has been shown. Initial implementations of data access services with Fedora will be capable of mapping between the DSpace and Fedora domain models, and where appropriate, this mapping will be customizable. Ultimately, it will be possible to persist DSpace Items within Fedora while making little to no changes to the features of DSpace end user applications.

Roadmap

Based on the strategies outlined above, a roadmap for the next two years of DSpace development can be charted. Continued refactorings to separate out the Data Model and Access Services will best be accomplished over two major revisions of DSpace. A first iteration (1.8) will establish the API and Services on existing DSpace core classes while leaving all implementation in place, deprecation will alert all projects that have altered these methods that they should prepare for significant changes on the way in the next version. A second iteration (1.9) will finally move those deprecated methods out of the core classes and pushing them into the data access serv- ice implementations.

Achieving DSpace 2.0

By continuing this path of development, we continue to show that the original funded DSpace 2.0 Initiative con- tinues to supply solutions and recommendations on the roadmap towards DSpace 2.0. With the Services frame- work and the first significant refactoring of DSpace core classes in place, the DSpace developer community can now begin to schedule changes that should happen as stepping stones to prepare the community for the release of a DSpace version 2.0.

Welcoming Collaboration

@mire realizes that such work on core DSpace libraries requires consensus and coordination into the community, as such we welcome feedback, critique and community participation on the initiative.