Community,
I just want to alert everyone that I've updated the patch for the DSpace
Domain Model to reflect the latest status of the work
https://jira.duraspace.org/browse/DS-845
<https://jira.duraspace.org/browse/DS-845>To assist others in understanding
what this Domain Model Does or is for, please review the following wiki
page(s).
https://wiki.duraspace.org/display/DSPACE/Refactoring+the+DSpace+Domain+Model
<https://wiki.duraspace.org/display/DSPACE/Refactoring+the+DSpace+Domain+Model>To
give an overview of what this work intends to accomplish:
Problem: Addon Modules that depend on DSpace artifacts such as dspace-api
cannot be released asyncronously to DSpace releases because of dependency
cycles created by all the projects residing under trunk and being released
at the exact same time. This was observed with the dspace-stats,
dspace-discovery and now the recent dspace-replicate work being done by Tim
Donohue, Richard Rodgers and the dspace-sync work @mire completed for the
Duracloud AV pilot.
Solution: To enable Addons to stop relying directly on dependencies on
dspace-api, a DSpace domain model project is proposed as dspace-core-api.
This "core api" is a standalone DSpace project that enforces a specific API
contract for interacting with DSpace Objects without being "bound" to a
specific version of dspace-api. Addon modules can then write application
code that interacts with this api (Icollection, IITem, IBitstream, IEPerson,
etc) rather than depending on Concrete dspace-api implementation.
Benefits:
1.) Measuring Compatability across releases: Separate releases of the
dspace-core-api would happen on a different schedule than the regular DSpace
release. Each DSpace release can then be "graded" based on use of this API
to determine backwards/forwards compatability of the core DSpace
implementation your custom code is using.
http://scm.dspace.org/svn/repo/modules/dspace-core/trunk/api/src/main/java/org/dspace/content/
2.) Contract lead to "boundaries" that cleanly separate application code in
dspace from the core Domain Model. dspace-api "app" packages will be able to
be broken out into separate projects and managed as addons, improving the
ability of application developers to replace these areas of functionality in
DSpace without the use of classpath overriding.
3.) The ability to write MockObject test suites more easily for DSpace to
provide Unit testing for your addon.
4.) Finally, the ability for third party addons to release there addons
prior to the official DSpace release, allowing the DSpace release process to
assemble these third party addon modules as optional addons for DSpace
without having to move them all under dspace/trunk as source. This will aid
in defining a formal "space" for addons to DSpace and best practices for how
they are authored and wired into DSpace without impacting the behavior and
contract of the core libraries.
An initial "bridge" implementation of this API is being authored that will
allow users of the DSpace Spring Service Manager to be able complete
"Repository" calls against DSpaceObject "Services".
http://scm.dspace.org/svn/repo/modules/dspace-core/trunk/impl/src/main/java/org/dspace/content/
This Implemenation provides simple CRUD Repositories that are exemplified
currently in the static methods provided in the DSpaceObjects themselves.
Thus the following style methods:
https://github.com/DSpace/DSpace/blob/master/dspace-api/src/main/java/org/dspace/content/Item.java#L140
public static Item find(Context context, int id) throws SQLException
are provided via a LegacyItemDAO interface and implemented as:
http://scm.dspace.org/svn/repo/modules/dspace-core/trunk/impl/src/main/java/org/dspace/content/LegacyItemDAO.java
Thus Item.find(....) is replaced by the following when a reference is needed
outside the Spring Application Context:
Item item = dspace.getSingletonService(LegacyItemDAO.class).find(....)
Whereas, when used within the Spring Application Context, Dependency
Injection eliminates any lookup (this is the ideal usage).
private ItemDAO itemDAO;
public void setItemDAO(ItemDAO idao)....
public void yourMethod() {
Item item = itemDAO.find(...)
}
This allows for much of the implementation of the method to be extensible
and to be abstracted away from the client application code calling it.
This implementation not the final solution for porting DSpaceObject static
methods to DAO but it is provided as a means for DSpace Addons to "Bridge"
the gap as we work to move the implementations of these static methods to
more formal DAO classes. Thus, Addons will jumpstart a migration of the
DSpace "Core" codebase out of the dspace-api library. I propose that such
an implementation, once stable, would be moved from dspace-core-impl into
dspace-impl and represent a legacy implementation of the DSpace Domain Model
against the relational postgres and oracle databases. Finally, I hope other
can see how achiving such a solution will assist us in producing what will
be a "swappable" implementation of the core DSpace API. Such a "swappable"
implementation is an ideal architecture upon which to base a DSpace "With
Fedora Inside" implementation, where such DAO would be replaced with
interations with Fedora rather than a relational datastore.
I hope to have what we consider to be very modest changes added to the
dspace-api for release with DSpace 1.8.0 and invite other developers to
begin working with and testing the proposed solution. I consider this a
serious step towards a true separation of concerns (Application, Domain
Model, Persistence) for DSpace. There will be examples of how to use this
API in an addon by porting the DSpace Discovery and Statistics Addons to
utilize it.
To attain this a decision needs to be made within the community to adopt the
signature changes in dspace-api, release and depend on dspace-core-api (just
like dspace-services is today). This decision needs to be made rather
quickly to get into the 1.8.0 release as a feature.
Your thoughts and comments are welcome.
Cheers,
Mark
p.s. I also want to clarify one point that came up in the last DSpace
Commiter IRC Meeting, the patch to provide the Interfaces in the method
signatures of dspace-api does not require the removal of any code from
dspace-api to be placed into dspace-core-api, but does include some
additional enhancements to the DCValue and MetadataVlaue objects to
consolidate their implementations onto one "Interface" with Getters and
Setters for DCValue properties. Thus the body of work continues to attempt
to improve the DSpace Metadata API.
--
Mark R. Diggory
@mire - www.atmire.com
2888 Loker Avenue East - Suite 305 - Carlsbad - CA - 92010
Esperantolaan 4 - Heverlee 3001 - Belgium
------------------------------------------------------------------------------
Got Input? Slashdot Needs You.
Take our quick survey online. Come on, we don't ask for help often.
Plus, you'll get a chance to win $100 to spend on ThinkGeek.
http://p.sf.net/sfu/slashdot-survey
_______________________________________________
Dspace-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/dspace-devel
