Suggested Architecture, a work in progres

...

• Presentationinterface for pages (Prototype from Toke)
• Early Ingest-platform
• Platform for validation of metadata in DOMS
• Extraction of Files/metadata for manual QA

Autonomous Components

Overall Description

An autonomous component is watching the system, and discovers work to be done

Suggested solution:

• The Component performs a query to discover tasks to do
• The query is to a Summa index of the DOMS
• If there are tasks to do, a task is started
• The component is responsible for making sure that it does not start a task it has already started. This can safely be done in memory.
• The result of the task is written back to the Batch object in DOMS as metadata
• Information about the execution of the taks is written back to DOMS as preservation metadata. Probably as a Premis Event.
• Event data and the like is harvested frequently by Summa for indexing, and thus form the input for other autonomous components 

...

• jpylizer køres i map-skridt af map/reduce-job. Resultatet lægges i DOMS (som datastream) i reduce-skridt.
• Udtræk af histogram køres i map-skridt af map/reduce-job. Resultatet lægges i DOMS i reduce-skridt.
• Generering af formidlingskopi køres i map-skridt af map/reduce-job. Filen skrives direkte til formidlingsstorage. Eventuelle fejl skrives tilbage til DOMS i reduce-skridt.
• Der laves ingen validering i map/reduce-job. Dette foretages som efterbehandling af metadata.

Automatic QA should be runnable by Ninestars

Vi skal afklare hvad Ninestars forventer/hvad vi har lovet.

• Vi forventer at en del komponenter skal findes i 2 udgaver, idet vi i Ninestars udgaven skal skrive til og læse fra fil-system i stedet for DOMS (det er ABR ved at se på en pæn løsning af)
• Vi forventer at i Ninestars udgaven køres QA på et enkelt batch. Altså ikke autonome komponenter og ingen overvågning.

Vi skal under alle omstændigheder afklare nogle af de samme drift-spørgsmål, som vi afklarer med vores egen drift-afdeling

• Hvilket operativ-system skal systemet deployes på?
• Hvor meget temporary storage har systemet brug for?
• Hvordan deployes systemet og hvordan overvåges det?

Vi anbefaler at Ninestars-udgaven af komponenterne ikke benytter Hadoop. Hvis vi alligevel vælger at bruge Hadoop, rejser det nogle Hadoop-specifikke spørgsmål

• Leverer vi en guide eller et script til at sætte Hadoop op, før vores "system" deployes?
• Eller integrerer vi opsætning af Hadoop i vores "system"?
• Eller leverer vi en virtuel maskine, hvor Hadoop og vores "system" er sat op på?

Vi kan forhåbentlig afklare en række af de spørgsmål i løbet af de næste par uger. 

Validering af metadata (i DOMS)

...