DDSUG 2009 Back-porting DSpace 2.0 Services to DSpace 1.6.0
by Mark Diggory on Oct 17, 2009
- 1,148 views
The release of "DSpace Services" represents the first offering of the DSpace 2.0 technology developed with funding from JISC, and staffing support from the DSpace Foundation, CARET, MIT, @mire, Open Re...
The release of "DSpace Services" represents the first offering of the DSpace 2.0 technology developed with funding from JISC, and staffing support from the DSpace Foundation, CARET, MIT, @mire, Open Repository, and HP.
This is a presentation on what DSpace services are and how they integrate into DSpace 1.6.0
Thanks to the efforts on this initiative by Mark Diggory from @mire, Aaron Zeckoski from CARET, Ben Bosman from @mire, Graham Triggs from Open Repository and Bradley McLean from DuraSpace Foundation. top
Accessibility
Categories
Tags
More...Upload Details
Uploaded via SlideShare as Apple Keynote
Usage Rights
© All Rights Reserved
Statistics
- Favorites
- 0
- Downloads
- 35
- Comments
- 0
- Embed Views
- Views on SlideShare
- 1,090
- Total Views
- 1,148
Community Developers need to maintain and improve DSpace.
End User Developers need to Customize installations.
Developers manipulating same code.
Results in Developers butting heads over merging contributions and new versions.
repeated changes to adapt DSpace to new customizations.
No, its not their fault?
Need to innovate,
Need to change code,
Need to solve immediate issues first.
No, its not their fault?
Need to innovate,
Need to change code,
Need to solve immediate issues first.
No, its not their fault?
Need to innovate,
Need to change code,
Need to solve immediate issues first.
No, its not their fault?
Need to innovate,
Need to change code,
Need to solve immediate issues first.
And static methods do not make an API, Application Programming Interface)
static methods are not extensible. Static methods cannot be overridden or re-implemented
And we have a lot of these in DSpace
Examples: PluginManager, ConfigurationManager, DatabaseManager, BitstreamStorageManager
They are even present in DSpaceObject Model
Static method even reference into other static Manager methods hardcoded in implementation.
Users forced to customize static methods directly
Repackaging modules: same Class, different behavior.
Everyone (Users and Developers) are changing the implementation directly.
I can identify a few in both DSpace and how we use/customize it...
[click] Hardcoding the Initialization of Configuration
Hardcoding Database Access into Data Model.
[click] God Objects,
ConfigurationManager (config, but also templates and logging)
Context (db, events, cache, authen)
DSpaceObject (data model and storage)
[click] JAR Hell, users have to alter source and override implementation to change behavior
Continuing practice with Maven and Overlays... leads to “jar hell” and “classloader hell” where users change behavior by readding same class with changes in front of original ont he classpath.
Not in criticism of all the hard work that went into DSpace initially.
But an analysis of the codebase given best practices that evolved since its creation.
I can identify a few in both DSpace and how we use/customize it...
[click] Hardcoding the Initialization of Configuration
Hardcoding Database Access into Data Model.
[click] God Objects,
ConfigurationManager (config, but also templates and logging)
Context (db, events, cache, authen)
DSpaceObject (data model and storage)
[click] JAR Hell, users have to alter source and override implementation to change behavior
Continuing practice with Maven and Overlays... leads to “jar hell” and “classloader hell” where users change behavior by readding same class with changes in front of original ont he classpath.
Not in criticism of all the hard work that went into DSpace initially.
But an analysis of the codebase given best practices that evolved since its creation.
I can identify a few in both DSpace and how we use/customize it...
[click] Hardcoding the Initialization of Configuration
Hardcoding Database Access into Data Model.
[click] God Objects,
ConfigurationManager (config, but also templates and logging)
Context (db, events, cache, authen)
DSpaceObject (data model and storage)
[click] JAR Hell, users have to alter source and override implementation to change behavior
Continuing practice with Maven and Overlays... leads to “jar hell” and “classloader hell” where users change behavior by readding same class with changes in front of original ont he classpath.
Not in criticism of all the hard work that went into DSpace initially.
But an analysis of the codebase given best practices that evolved since its creation.
[click] All Products dependent on DSpace, in some cases we have some cases, we too overlay existing dspace-api classes and are subject to these problems during upgrading.
[click] But, as a commercial company, we NEED to guarantee upgrade path for our clients.
[click] Thus we really need stable and clearly defined API in DSpace. Both for reliability and for our own customiations.
[click] All Products dependent on DSpace, in some cases we have some cases, we too overlay existing dspace-api classes and are subject to these problems during upgrading.
[click] But, as a commercial company, we NEED to guarantee upgrade path for our clients.
[click] Thus we really need stable and clearly defined API in DSpace. Both for reliability and for our own customiations.
[click] All Products dependent on DSpace, in some cases we have some cases, we too overlay existing dspace-api classes and are subject to these problems during upgrading.
[click] But, as a commercial company, we NEED to guarantee upgrade path for our clients.
[click] Thus we really need stable and clearly defined API in DSpace. Both for reliability and for our own customiations.
[click] All Products dependent on DSpace, in some cases we have some cases, we too overlay existing dspace-api classes and are subject to these problems during upgrading.
[click] But, as a commercial company, we NEED to guarantee upgrade path for our clients.
[click] Thus we really need stable and clearly defined API in DSpace. Both for reliability and for our own customiations.
We work to separate the libraries into Functionally separate units.
Use dependency relationships to clarify inter-dependencies.
But... Have to be cautious that we don’t increase complexity that we are seeking to reduce.
We do need modularity. But, modularity is not a complete solution on its own. We need something else...
[click] and most importantly, we need to identify key important interfaces as contracts within the application.
Removes Hardcode: Data Models are anemic, Services implemented separate from interfaces used by applications.
Lessens JAR Hell: API contracts, default implementations off limits.Want to change behavior, write changes separately.
Removes God Objects: Services separate functional areas, separate Data Models without interdependency assure separation.
Removes Hardcode: Data Models are anemic, Services implemented separate from interfaces used by applications.
Lessens JAR Hell: API contracts, default implementations off limits.Want to change behavior, write changes separately.
Removes God Objects: Services separate functional areas, separate Data Models without interdependency assure separation.
Removes Hardcode: Data Models are anemic, Services implemented separate from interfaces used by applications.
Lessens JAR Hell: API contracts, default implementations off limits.Want to change behavior, write changes separately.
Removes God Objects: Services separate functional areas, separate Data Models without interdependency assure separation.
More like a 3rd party dependency
Released separately under its own revision path
Dividied into 3 projects
API ....
Event Service: Register Event Listeners. Generate Events.
Request Service: Transactional window for completing tasks.
Provides hooks for Request Interceptors to
allow other services to participate in the transaction.
Session Service: Provides a state across requests.
Caching Service: Holds onto references to objects for later use.
Contains configuration User defined Asynchronous DSpace Services.
exists in both XMLUI and JSPUI
Note that more files can be added here,
Which is a more appropriate use of overlays that replacing files wholesale.
But there are other ways as well. Google Guice, annotations, etc.
User can get it from Request service
Not passed around
Retained in Thread Local
Database Connection no longer transactional window (not present in 1.6)
Code must register Request-Interceptors to close database transactions.
Rather than Hardcoded Initialization forcing DSpace Users to accept DSpace existing Configuration. Or altering that implmentation directly.
Decide what implementations should be isolated from API directly used by users customizing DSpace.
Rather than Hardcoded Initialization forcing DSpace Users to accept DSpace existing Configuration. Or altering that implmentation directly.
Decide what implementations should be isolated from API directly used by users customizing DSpace.
Rather than Hardcoded Initialization forcing DSpace Users to accept DSpace existing Configuration. Or altering that implmentation directly.
Decide what implementations should be isolated from API directly used by users customizing DSpace.
[click] Will take multiple version releases introducing new functionality as we go
[click] Work is incremental, projects need to remain tractable and adopted quickly
[click] Work needs to be kept close to the trunk where it can be integrated.
[click] Services are here as the first step towards that integration.
[click] All Developers need to plan together to for these migrations
My ultimate hope is to emphasize to the community the immense need for you to come forward and contribute within the DSpace developers group, not only working on 2.0, but also on the neccessary effort that will be needed to bring these needed improvements to mainstream usage within the DSpace community.
In doing this integration of dspace-services into DSpace 1.6.0 my interest is in assuring the preservation of this effort by spearheading its adoption onto the community.
[click] Will take multiple version releases introducing new functionality as we go
[click] Work is incremental, projects need to remain tractable and adopted quickly
[click] Work needs to be kept close to the trunk where it can be integrated.
[click] Services are here as the first step towards that integration.
[click] All Developers need to plan together to for these migrations
My ultimate hope is to emphasize to the community the immense need for you to come forward and contribute within the DSpace developers group, not only working on 2.0, but also on the neccessary effort that will be needed to bring these needed improvements to mainstream usage within the DSpace community.
In doing this integration of dspace-services into DSpace 1.6.0 my interest is in assuring the preservation of this effort by spearheading its adoption onto the community.
[click] Will take multiple version releases introducing new functionality as we go
[click] Work is incremental, projects need to remain tractable and adopted quickly
[click] Work needs to be kept close to the trunk where it can be integrated.
[click] Services are here as the first step towards that integration.
[click] All Developers need to plan together to for these migrations
My ultimate hope is to emphasize to the community the immense need for you to come forward and contribute within the DSpace developers group, not only working on 2.0, but also on the neccessary effort that will be needed to bring these needed improvements to mainstream usage within the DSpace community.
In doing this integration of dspace-services into DSpace 1.6.0 my interest is in assuring the preservation of this effort by spearheading its adoption onto the community.
[click] Will take multiple version releases introducing new functionality as we go
[click] Work is incremental, projects need to remain tractable and adopted quickly
[click] Work needs to be kept close to the trunk where it can be integrated.
[click] Services are here as the first step towards that integration.
[click] All Developers need to plan together to for these migrations
My ultimate hope is to emphasize to the community the immense need for you to come forward and contribute within the DSpace developers group, not only working on 2.0, but also on the neccessary effort that will be needed to bring these needed improvements to mainstream usage within the DSpace community.
In doing this integration of dspace-services into DSpace 1.6.0 my interest is in assuring the preservation of this effort by spearheading its adoption onto the community.
[click] Will take multiple version releases introducing new functionality as we go
[click] Work is incremental, projects need to remain tractable and adopted quickly
[click] Work needs to be kept close to the trunk where it can be integrated.
[click] Services are here as the first step towards that integration.
[click] All Developers need to plan together to for these migrations
My ultimate hope is to emphasize to the community the immense need for you to come forward and contribute within the DSpace developers group, not only working on 2.0, but also on the neccessary effort that will be needed to bring these needed improvements to mainstream usage within the DSpace community.
In doing this integration of dspace-services into DSpace 1.6.0 my interest is in assuring the preservation of this effort by spearheading its adoption onto the community.
[click] Will take multiple version releases introducing new functionality as we go
[click] Work is incremental, projects need to remain tractable and adopted quickly
[click] Work needs to be kept close to the trunk where it can be integrated.
[click] Services are here as the first step towards that integration.
[click] All Developers need to plan together to for these migrations
My ultimate hope is to emphasize to the community the immense need for you to come forward and contribute within the DSpace developers group, not only working on 2.0, but also on the neccessary effort that will be needed to bring these needed improvements to mainstream usage within the DSpace community.
In doing this integration of dspace-services into DSpace 1.6.0 my interest is in assuring the preservation of this effort by spearheading its adoption onto the community.
[click] Will take multiple version releases introducing new functionality as we go
[click] Work is incremental, projects need to remain tractable and adopted quickly
[click] Work needs to be kept close to the trunk where it can be integrated.
[click] Services are here as the first step towards that integration.
[click] All Developers need to plan together to for these migrations
My ultimate hope is to emphasize to the community the immense need for you to come forward and contribute within the DSpace developers group, not only working on 2.0, but also on the neccessary effort that will be needed to bring these needed improvements to mainstream usage within the DSpace community.
In doing this integration of dspace-services into DSpace 1.6.0 my interest is in assuring the preservation of this effort by spearheading its adoption onto the community.
We would not have this solution if it were not for his initiative and the contribution of his time by CARET and funding by JISC.
We would not have this solution if it were not for his initiative and the contribution of his time by CARET and JISC.