[Bitrepository-devel] Forslag til BitRepository massprocessing

Fri Aug 31 11:40:33 CEST 2012

Kære Alle

På baggrund af vores diskussion i onsdags er Asser og jeg kommet frem til følgende forslag vedrørende massprocessing.
Dette forslag er baseret på de umiddelbare problemstillinger og behov, så det vil være rigtigt godt med noget input, især fra arkitekterne (Kåre, Eld og Bolette) og nogen fra SA.

Der vil være fordelagtigt at opdele massprocessing i to selvstændig faser. En fase til at deployere et det ProcessingJob, som skal afvikles, og en fase til at eksekvere jobbet.
Selve deployeringen af ProcessingJob vælger vi at udskyde i først omgang. Dette må derfor foregå manuelt, og så må vi på et senere tidspunkt analysere om, om der er brug for en automatisk deployering af ProcessingJobs, samt dertilhørende protokol udvidelser.

Hele processen med at få en pillar til at afvikle et ProcessingJob skal gøre så agnostisk som muligt i forhold til platform, infrastruktur og arkitektur af de pågældende pillars.
Alt vedrørende data-sikkerhed i forhold til et ProcessingJob må en pillar selv stå for (f.eks. at køre det pågældende ProcessingJob fra en sandkasse).

For at skelne mellem forskellige typer af processerings jobs, så vil der blive indført en 'ProcessingJobType'.
En ProcessingJobType skal referere til den måde at afvikle de dertilhørende ProcessingJobs (f.eks. om det er et Java-program, C#-program, et Perl-script, eller noget der skal afvikles på en Hadoop platform).
Det er dog vigtigt, at der til hver ProcessingJobType er et værktøj til at afvikle de dertilhørende ProcessingJobs manuelt (f.eks. via scripts af en pillar administrator(?) ).
Det vil være at foretrække, hvis et sådanne værktøj også kan bruges som et plugin til en pillar, så ProcessingJobs af den pågældende type kan afvikles automatisk, men det er ikke nær så vigtigt som at kunne afvikle ProcessingJobs manuelt.

I først omgang vil det kun blive tale om en enkel ProcessingJobType, hvilket vil være til at eksekvere Java-baserede ProcessingJobs i lighed med BatchJobs fra NetarchiveSuite.
Det skal laves som et selvstændigt modul. Det vil være bedst, hvis modulet er uafhængigt at reference koden (altså på niveau med 'CollectionSettings' og 'Message-XML' modulerne).

I forhold til protokolen skal de forskellige ProcessingJobTypes defineres i en enumerator. Der skal dog være ubetingede og ubegrænsede udvidelsesmuligheder, så det bliver gjort ligesom med checksums algoritmerne, hvor der laves en 'OTHERTYPE', som kan blive defineret ved en streng.

Oprindeligt blev der skelnet mellem SingleFileProcessing og MassProcessing. Dette kombineres til en 'ProcessingFiles' operation, hvor man skal specificere om et ProcessingJob skal afvikles på et specifikt fil id eller alle fil id'er (i form af vores FileIDs objekt).

Det skal der være muligt at kunne specificere afviklingen af et ProcessingJob via nogle parametre/argumenter.
Det kan være parametre i forbindelse med at bruge værktøjet til at afvikle det pågældende ProcessingJob, eller argumenter til selve ProcessingJobbet.

Resultatet fra et ProcessingJob bør kunne returnere direkte via beskeden eller oploades til en URL (på samme måde som f.eks. GetChecksums resultaterne).
Selve resultatet afhænger af det pågældende ProcessingJob og bør returneres som en klump rå data.
Hvis det returneres i beskeden vil det være en streng. Det kan dog være, at den evt. skal indkodes ligesom checksummer eller lignende, for at undgå XML fejl.

I forbindelse med at eksekvere et ProcessingJob er her et forslag til hvilke beskeder, som protokolen bør udvides med:

IdentifyPillarsForProcessingFilesRequest

-       Default IdentifyRequest.

-       Beskrive af processerings jobbet (type, name, other).

-       FileIDs

IdentifyPillarsForProcessingFilesResponse

-       Default IdentifyResponse.

ProcessingFilesRequest

-       Default Request

-       Beskrive af processerings jobbet (type, name, other).

-       FileIDs

-       Parametre til at køre processerings jobbet

-       En URL til aflevering af resultaterne (valgfri)

ProcessingFilesProgressResponse

-       Default ProgressResponse

ProcessingFilesFinalResponse

-       Default FinalResponse

-       Skal kunne indkapsle resultaterne(enten direkte i en tekst streng, eller indirekte ved at have en resultats URL)

En pillar skal selvfølge svare negativt på identifikationen, hvis den f.eks. ikke supportere den pågældende type ProcessingJob, ikke har fået deployeret et ProcessingJob med det givne navn, eller lignende.

Da massprocessing godt kan tage lang tid, især på store datamængder, så vil der være nogle problemstillinger vedrørende OperationTimeouts, som der skal kigges på (f.eks. at en pillar sender en 'ProgressResponse' med et givent interval indtil, at den er færdig med jobbet).

Med venlig hilsen
Asser og Jonas

[http://support.kb.dk/images/kb_logo.jpg]

Det Kongelige Bibliotek
Nationalbibliotek og Københavns Universitetsbibliotek

Jonas Lindberg Frellesen
Softwareudvikler | Software Developer

Det Kongelige Bibliotek | The Royal Library
Afdelingen for Digital Bevaring | Digital Preservation
P.O. Box 2149 | DK-1016 København K
tel +45 3347 4691 | Fax +45 3393 2218 | jolf at kb.dk<mailto:jolf at kb.dk> | www.kb.dk<http://www.kb.dk>

Besøgsadresse | Visiting address | Søren Kierkegaards Plads 1
Leveringsadresse | Delivery address | Christians Brygge 8 | 1219 København K

EAN 5798 000 79 52 97 | Bank 0216 4069032583 | CVR 28 98 88 42
IBAN DK2002164069032583 | Swiftcode DABADKKK

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://ml.sbforge.org/pipermail/bitrepository-devel/attachments/20120831/fdd6d90b/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.jpg
Type: image/jpeg
Size: 14433 bytes
Desc: image001.jpg
URL: <http://ml.sbforge.org/pipermail/bitrepository-devel/attachments/20120831/fdd6d90b/attachment-0001.jpg>