## Please put instances of this page in the appropriate task folder, e.g. Tasks/X/Y/AnalysisDocumentation
## Headline such as "Analysis of X.Y Backup Requirements"
= Analysis of Task Summa integration =

## Add detailed explanation/analysis of the task.

=== 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:

{{attachment:SummaIntegrationIndexing.png}}


{{attachment:SummaIntegrationDisplay.png}}


## This may include use-case diagrams etc. attached like this:
## Link to original: [http://merkur.statsbiblioteket.dk/svn/doms/trunk/MODULE/docs/MyUseCase.dia]
## png on the wiki page: http://merkur.statsbiblioteket.dk/svn/doms/trunk/MODULE/docs/MyUseCase.png

== Prerequisites and Assumptions ==

## Describe any prerequisites and assumptions that are important for this analysis, e.g.:
## What can we rely on?
## Which assumptions must hold in order to solve the problem described in this document?

## Risks and Stakeholders are of course important to the analysis, but we have dedicated pages for these, and they should only be included here if this task poses additional risks or new problems...

== Resources ==

## List links to documents, wiki pages etc. that are relevant to this analysis.
## * [:LinkToMyRessource:Use case diagram xx]
## * [:LinkToMyVersionControlledDocument:Link to document on user studies e.g. stored in SVN]