Analysis of Task Summa integration
First thoughts on choice of integration with Summa
There are three ways in which Summa can receive content for indexing (and presentation)
- By the DOMS side calling an ssh-script to deliver a zip file of contents to Summa
- By the Summa side requesting latest changed objects via OAI-PMH
- By the DOMS side implementing the Summa API, through which Summa can request latest changes
The last option appears to be the most convenient for our use. Reason: The first would require more development on our part than the last. And the second is less convenient for Summa than the last. So, the last it is.
Overview of the work needed for Summa integration
The following is an overview of what work needs to be done by the different groups.
There will be two kinds of interaction between DOMS and Summa:
- DOMS contents provided through Summa Storage API for indexing+display
- Summa search provided for DOMS-GUI
As DOMS-GUI users will need to search for non-published objects, we need separate Summa Storage APIs, and separate Summa Searchers.
So what should be done, and who should do it:
Summa Searcher for normal web search
- DOMS-todo: create a representative set of sample objects (in Fedora) which will enable Summa people to write XSLTs. (Both indexing and display)
- Estimate: TODO (2-3 weeks?)
- Summa-todo: create XSLTs for indexing and display for every new collection in DOMS.
- Estimate: about 2-6 weeks the first time, thereafter about 1-3 weeks each time
Summa Storage API for normal web search
- DOMS/Summa-todo: Setup, make the API run.
- Estimate: about 2 weeks ping-pong with 1-2 people from DOMS and 1-2 people from Summa
- DOMS-todo: underlying functionality behind Summa Storage API.
- See sequence diagrams for indexing and display Estimate: TODO
- ITservice-todo: A service that translates IPs to roles.
- (Used by search, see sequence diagrams) Estimate: TODO
Summa Searcher for DOMS-GUI search
- DOMS-todo: create a representative set of sample objects (in Fedora) which will enable Summa people to write XSLTs.
- (Only for indexing - not for display) Estimate: TODO (2 days?) - can be re-used from normal web search
- Summa-todo: create XSLTs for indexing (not for display) for every new collection in DOMS
- Estimate: about 1-3 weeks each time
Summa Storage API for DOMS-GUI search
- DOMS/Summa-todo: Setup, make the API run.
- Estimate: about 2 weeks ping-pong with 1-2 people from DOMS and 1-2 people from Summa
- DOMS-todo: underlying functionality behind Summa Storage API.
- Maybe via a special Summa-role (so that each of the two Summas has a role for itself) (No display handled here, as it is done via a Summa-webservice call) Estimate: TODO
Summa Webservice call from DOMS-GUI
- DOMS-todo: SOAP or RMI call and handling of returned data.
- Estimate: TODO (1 week?)
Methods needed in Summa integration component, as an implementation of the Summa storage API
We need an implementation of Summa's ReadableStorage interface, that is, the following methods
- getModificationTime(String base)
getRecord(String id, QueryOptions options)
getRecords(List of Strings id, QueryOptions options)
getRecordsModifiedAfter(long time, String base, QueryOptions options)
- next(long iteratorKey)
- next(long iteratorKey, int maxRecords)
See Summa Storage API javadoc at (where?)
Sequence diagrams showing the surroundings of the Summa Integration component:
Prerequisites and Assumptions