Bitmagasinet som arkiv for Netarkivet

Dette er en analyse af Netarkivet og Bitmagasinet med henblik for at finde ud af, hvad der skal til, for at Netarkivet kan bruge Bitmagasinet som sit arkiv. Dette vil også involvere, at Bitmagasinet skal stå for sikringen af data, bl.a. ved integritets check, genoprettelse af manglende/korrupte filer, m.v..
Dette involverer en analyse af, hvilke krav Netarkivet har til sit arkiv, og for hvert af disse krav skal det fastslås enten, hvordan Bitmagasinet allerede opfylder kravet, eller hvad der skal til for, at Bitmagasinet opfylder kravet.
Derudover skal der også kigges på performance af Bitmagasinet som arkiv i forhold til den nuværende bitarkiv løsning i NAS.

Ordforklaring:

Netarkivet er samarbejdsprojektet mellem Statsbiblioteket og Det Kongelige Bibliotek for at indsamle og bevare den danske del af internettet.
NetarchiveSuite (aka. NAS) er softwaren, som Netarkivet bruger, og som udvikles i et internationalt samarbejde.
Bitmagasinet er et fælles projekt mellem Statens Arkiver, Statsbiblioteket og Det Kongelige Bibliotek for at udvikle et system, hvor man forsvarligt kan bevare digitale objekter.
Pillar og Replica er navnene for bevaringsbenene i arkivet for henholdsvis Bitmagasinet og NAS.

Funktionaliteter for Netarkivets arkiv

Det er på nuværende tidspunkt følgende krav til Netarkivets arkiv:

• putte filer til arkivet
• skaffe alle filnavne
• skaffe alle checksummer
• skaffe checksum for en enkelt fil
• hente filer ud fra arkivet
• hente del-filer ud fra arkivet i form af ARC/WARC records
• gendanne en ødelagt fil i arkivet
• eksekvere batch-jobs

Putte filer til arkivet

Det at putte filer til arkivet omfatter i NAS sammenhæng både at få filerne overført til alle replicas og sikre sig, at det er den rigtige fil, som alle replicas har. Det betyder, at det er NAS bliver sørget for, at filen bliver overført til et sted, hvor den er tilgængelig for alle replicas. I NAS kan filerne enten overføres via http, HTTPS eller FTP, hvoraf Netarkivet pt. bruger sidstnævnte.
Bitmagasinet putter filer til alle pillars via PutFileClient, som sørger for at det er den rigtige fil, som de henter. Det forventes dog af PutFileClient, at filerne allerede er placeret et sted, der er tilgængeligt for alle pillars. Derudover er der lagt op til, at der skal bruges HTTPS til overførsel.
Det betyder, at der skal besluttes hvorvidt, at Netarkivet med Bitmagasinet skal blive ved med at bruge FTP, hvilket vil kræve en tilpasning i Bitmagasinet, eller hvorvidt Netarkivet skal ændres til at bruge HTTPS, hvilket burde give mere sikkerhed.
Derudover vil det være nødvendigt for Netarkivet at få indført et trin, hvor filerne overføres til den pågældende filserver, før at Bitmagasinets PutFileClient bruges. Der kan her optimeres ved at lægge filserveren lokalt, så denne overførsel foretages internt på maskinen eller evt. helt overflødiggøres.

Skaffe alle filnavne

Det at skaffe alle fil-id'er bruges i NetarchiveSuite kun i forbindelse med integritetscheck'et for at finde manglende filer. Da Bitmagasinet skal overtage ansvaret for integritets check, bliver denne funktionalitet overflødig for Netarkivet.
Hvis funktionaliteten ønskes bevaret (f.eks. i en fremtidig udvidelse af NAS), så kan den direkte overtages af GetFileIDsClient i Bitmagasinet.

Skaffe alle checksummer

Det at skaffe alle checksummer bruges i NetarchiveSuite kun i forbindelse med integritetscheck'et for at finde inkonsistens i mellem filerne på tværs af alle replicas. Denne funktionalitet bliver også overflødig for Netarkivet, da ansvaret for integritets check overtages af Bitmagasinet.
I tilfælde af at funktionalitet ønskes bevaret i NAS, så kan den overtages direkte af GetChecksumClient i Bitmagasinet.

Skaffe checksum for en enkelt fil

I NAS bruges dette i to tilfælde:

• i forbindelse med ingest for at sikre sig, at det er den samme fil, som man har puttet til alle replicas
• i forbindelse med genoprettelse af filer med integritets problemer.

Da begge tilfælde er i forbindelse med andre funktionaliteter, som overtages af Bitmagasinet, så vil også dette være overflødigt.
Dette er – ligesom at skaffe alle checksummer – en opgave, der kan direkte overføres til GetChecksumClient i Bitmagasinet, hvis funktionaliteten på forunderlig vis ønskes bevaret.

Hente filer ud fra arkivet

Netarkivets GetFile funktionalitet stemmer – ligesom for PutFile – ikke fuldstændig overens med funktionaliteten i Bitmagasinets GetFileClient.
Bitmagasinets GetFileClient sørger blot for, at en pillar lægger en fil på en ønsket destination, f.eks. en filserver. Hvorimod det i NAS sørges for, at filen overføres hele vejen til den, der forespurgte filen.
Dette betyder, at der skal indføres et trin efter, at Bitmagasinet har fået filen oploadet til en filserver, hvorfra filen hentes, så den kan afleveres på samme måde, som i NAS.
Der vil i et senere afsnit blive kigget på, hvordan access til arkivet kan forbedres.

Hente del-filer ud fra arkivet i form af ARC/WARC records

I NAS hentes Arc/Warc records på baggrund af et fil-id, samt offsettet på starten af den ønskede record.
I Bitmagasinet hentes dele af filer på samme måde som en hel fil, hvor der blot specificeres et start offset og et slutoffset på den ønskede del af filen.
Her er en markant forskel på, hvordan man henter delmængder af filer ud, da der i Netarkivet kun bruges et enkelt offset, hvor Bitmagasinet kræver to offset. Dette problem er ikke lige til, så der vil i et senere afsnit blive gennemgået mulige løsninger på denne problematik.

Gendanne ødelagte filer i arkivet

I NAS kan man gendanne korrupte filer på baggrund af integritetscheck, men da integritetscheck, m.v. skal overtages af Bitmagasinet, så bliver denne funktionalitet overflødig for Netarkivet.
Pt. er det i Bitmagasinet kun muligt at gøre manuelt ved at først bruge at GetFileClient til at hente en rigtig udgave af file og derefter ReplaceFileClient til at rette den ødelagte fil. Det er dog lagt på tegnebrættet, at der skal udvikles en IntegrityClient, som bl.a. skal stå for gendannelsen af ødelagte filer på baggrund af integritetscheck.
Her er der dog en forskel i sikkerheden mellem, hvordan det gøres i NAS og i Bitmagasinet. I NAS bruges et konfigureret kodeord, hvor der i Bitmagasinet er lagt op til at blive brugt certifikater.

Eksekvere batch-jobs

Det er en kritisk funktionalitet i Netarkivet, at der kan foretages processering af data i arkiverne, da det bl.a. er en forudsætning for indekseringen.
I NAS foregår det ved, at et Java Batchjob sendes til et replica sammen med nogle afviklingsspecifikke oplysninger, hvorved replica'et afviklet dette Batchjob på de ønskede filer i arkivet.
I Bitmagasinet er det lagt på tegnebrættet, at der skal være mulighed for at afvikle masse processerings job på data på en pillar. En af hovedudfordringerne i forhold til massprocessing i Bitmagasinet er, at det på protokol niveau skal være agnostisk i forhold til programmeringssprog, bevaringsplatform og systemopsætning.
I det næste afsnit præsenteres et udkast til hvordan, at dette kan implementeres i Bitmagasinets protokol, samt et oplæg til en proof-of-concept løsning baseret på Batchjobs fra NAS.

ProcessingJob i Bitmagasinet

Oplæg til implementeringen på protokol niveau

Dette er blot en opsummering af oplægget til ProcessingJobs på protokol niveau. Det fulde oplæg fra Asser og Jonas er at finde i bilag med dertilhørende kommentarer fra Kåre, Eld og Mikis.
Der er to faser i håndteringen af et ProcessingJob; en deployeringsfase og en afviklingsfase. Der vil her kun blive kigget på afviklingsfasen, hvorved deployeringen af ProcessingJobs i først omgang må foregå manuelt.
Fra protokol niveau skal afviklingen af et ProcessingJob gøres så agnostisk som muligt i forhold til platform, infrastruktur og arkitektur af de pågældende pillars. Datasikkerhed i forhold til afviklingen af et ProcessingJob må være pillar'ernes eget ansvar.
 For at skelne mellem forskellige typer af processerings jobs, så vil der blive indført begrebet 'ProcessingJobType', som skal referere til den måde at afvikle de dertilhørende ProcessingJobs (f.eks. om det er et Java-program, C#-program, noget til en Hadoop-platform, eller lignende). Det er dog vigtigt, at der til hver ProcessingJobType er et værktøj til at afvikle de dertilhørende ProcessingJobs manuelt, samt eventuelt som et plugin til en pillar, så det kan afvikles automatisk.
For at identificere det specifikke ProcessingJob, som ønskes afviklet, skal der både angives ProcessingJobType og et ProcessingJobID (f.eks. bestående af navn og version for det pågældende ProcessingJob).
I protokollen skal det være muligt at definere parametre eller argumenter til afviklingen af et ProcessingJob, enten til værktøjet eller direkte til det pågældende ProcessingJob (f.eks. et ProcessingJob for at finde URL'er på WARC-records kan have et regulært udtryk for URL'en som argument).
Resultatet fra et ProcessingJob bør kunne returneres direkte via beskeden eller oploades til en URL afhængig af forespørgslen og resultatets størrelse.

Hvordan BatchJobs virker i NetarchiveSuite

Et BatchJob bliver både distribueret og afviklet via en BatchMessage, der indeholder selve batchjobbet (f.eks. i form af en java-class fil direkte, eller en jar fil med navnet på en indlejret java-class fil for BatchJobbet), og et regulært udtryk for at begrænse hvilke filer, batchjobbet skal afvikles på (default alle filer). Derudover kan det indeholde parametre, som batchjobbet skal bruge til afviklingen.
Denne BatchMessage sendes til BitarchiveMonitor'en for det pågældende replica, hvor det skal afvikles, hvorfra det bliver distribueret til alle de dertilhørende bitarchive instanser, som står for at afvikle BatchJobbet på dataene i arkivet.
Når batchjobbet afvikles på hver enkelt bitarchive instans, starter det med en pre-processering for batchjobbet (der dog ofte ikke gør noget), dernæst foretages processeringen af alle filerne enkeltvis (dog kun de filer, der matcher det regulære udtryk), og det afsluttes med en post-processering (igen, ofte uden at gøre noget). Resultaterne bliver samlet i en fil, som sendes tilbage til BitarchiveMonitor'en.
BitarchiveMonitor'en samler svarerne fra alle Bitarchive instanserne sammen, og når alle har svaret, så sammensættes filerne til en enkelt resultat fil, som bruges til det endelige svar på selve BatchJobbet.
Umiddelbart bliver svar-filerne fra alle Bitarchive instanserne sammensat direkte ved, at de bliver skrevet lige efter hinanden til slut-filen, men det er muligt for et batchjob at definere en alternativ måde at sammensætte besvarelserne på (f.eks. sortere resultaterne, lave statistik, etc.).
I forhold til datasikkerhed skal siges, at bitarkiverne kun giver read-only adgang til filerne, og at der bruges java security properties til at sikre, at det ikke er muligt for et batchjob at udføre skadelige handlinger på fil-systemet eller operativ-systemet.

Oplæg til et Proof-Of-Concept på baggrund af NAS BatchJobs.

Batchjobs i Netarkivet afvikles via Java på Linux og/eller Windows platforme. Vores Proof-Of-Concept (POC) vil derfor være et modul til at afvikle Java baserede ProcessingJobs, som kan afvikles på en fil ad gangen. Dertil skal der – i lighed med BatchJobs i NAS – være mulighed for pre- og post-processering, samt mulighed for at definere hvordan flere resultat-filer af processeringen kan sammensættes.
Det skal laves som et selvstændigt modul, der kan bruges direkte som plugin i Java-pillars. Det vil være bedst, hvis modulet bliver implementeret uafhængigt at reference koden (altså placeres på niveau med 'CollectionSettings' og 'Message-XML' modulerne).
Da et ProcessingJob af denne type har de sammen metoder som BatchJobs i NAS (altså, pre-processering, fil-processering, post-processering, samt resultat-fil sammensætning), vil det betyde, at der kan udvikles ProcessingJobs, der er præcis tilsvarende de nødvendige BatchJobs fra Netarkivet. Ydermere vil det endda være muligt at udvikle et ProcessingJob, som direkte kan indlejre batchjobs fra NAS.

Andre problemstillinger

Beregning af checksummer til integritets check

Der er stor forskel på, hvordan og hvornår checksummerne bliver beregnet til integritetscheck.
I NAS starter et integritets check af checksummerne med, at alle replica'er genberegner checksummer på alle filer. Dette kan tage meget lang tid (i Netarkivet: 9-15 timer på KB, og 15-20 dage på SB). Samtidig er det en meget stor I/O belastning for maskinerne at genberegne checksummerne, som kan påvirke performance af andre operationer, f.eks. indeksering.
I Bitmagasinet forventes det ikke, at en pillar genberegner alle checksummerne ved hver forespørgsel. Her er der nemlig i en konfiguration og/eller SLA defineret, hvor gamle checksummer fra den givne pillar maksimalt må være. Det forventes derimod, at en pillar har en cache med alle checksummerne, og at den løbende sørger for at genberegne checksummerne, så de ikke bliver for gamle.
Det betyder, at en pillar er klar til at levere alle checksummer med det samme, i stedet for at være nødt til at beregne dem først. Derved er der ikke en kæmpe I/O belastning for en pillar at levere alle checksummerne til et integritets check.
Når en pillar leverer checksummer, så er der et tidsstempel tilknyttet hver checksum for hvornår, at denne er blevet beregnet. Dette betyder, at integritetschecket kan verificere, hvorvidt nogen checksummer er for gamle, hvilket er en problemstilling, som ikke er relevant for checksummerne i NAS.

Overvågning via JMX

I NAS kan alle komponenterne blive overvåget via SystemOverview, som benytter sig af JMX.
Bitmagasinet har derimod en MonitoringService, som står for at holde styr på status på de forskellige komponenter. Denne MonitoringService har en web-brugergrænseflade.
Det vil være muligt for Netarkivet at overvåge Bitmagasinet, hvis MonitoringService knyttes op til JMX, så SystemOverview i NAS kan få Bitmagasinets status derfra.

Hente del-filer ud fra Bitmagasinet Netarkivet

Der er en markant forskel på, hvordan man henter delmængder af filer ud fra de forskellige systemer. I NAS kræver det kun et enkelt offset, hvor i Bitmagasinet kræver det to offset. Dvs. at hvis Netarkivet skal bruge Bitmagasinet til at hente arc/warc-records, så skal det have begge offsets for recorden.
Den umiddelbare løsning er, at der et eller andet sted i Netarkivet skal være adgang til det andet offset for, at det bliver muligt at integrere NAS med Bitmagasinet.
Det indeks, som udtrækkes for alle data i Netarkivet, er et CDX indeks, hvilket bl.a. indeholder både filnavn, et offset og en længde for hver arc/warc-record. Derfor vil det være muligt at beregne det manglende offset, så der kan laves den tilsvarende forespørgsel i Bitmagasinet (altså, slut-offset = start-offset + længde).
I Netarkivet bruges dette CDX indeks som basis for access af data, f.eks. til deduplikering eller i Wayback til at fremvise de høstede hjemmesider. Lige nu bruges kun filenavn og offset, men f.eks. Wayback har allerede mulighed for også at indeholde et slut-offset på arc/warc-records.
En alternativ løsning kunne være, at man henter arc/warc-records ud ved at bruge et ProcessingJob, som tager fil-id og start-offset som argumenter. Dernæst afvikles den kun på den pågældende fil, som indlæses som en ARC/WARC fil, hvorfra den ønskede record kan findes ud fra start-offsettet. Dette kræver dog, at hele ProcessingJob mekanismen er på plads, samt at et sådanne ProcessingJob udvikles.

Optimering af access fra arkivet

Som der er lige nu, så foregår al acces til data i Netarkivet via JMS beskeder og eventuelt FTP servere. Det betyder, at der er et kæmpe stort overhead i resurseforbruget for at hente data ud fra arkivet. Da infrastrukturen i Bitmagasinet mht. access minder meget om Netarkivets, så forventes det, at der vil være samme overhead i resurseforbruget.
Det vil være muligt at lave en pillar i Bitmagasinet, hvor f.eks. Wayback har direkte læse-adgang (read-only) til arkivet. Dette kan f.eks. gøres ved at bruge en filsystem-pillar (ReferencePillar, SBDiskPillar, eller KBPillar), hvor Wayback laver et read-only mount af de diske, som den pågælden pillar bruger til sit arkiv.
Det vil betyde, at Wayback har direkte adgang til filerne, hvilket vil være en kæmpe forbedring af performance i forhold til brugerne. Samtidig vil den pågældende pillar stadigvæk have kontrollen over filerne, således at den kan foretage de nødvendige operationer i forhold integritetscheck, mv.
Det må være en politisk beslutning, hvorvidt data er sikret tilstrækkeligt ved et read-only mount.
Appendix

Forslag til Processing procedure

På mailing har der været følgende forslag og diskussion om hvordan, at Processing skal implementeres.

Første mail (Asser og Jonas)

Fra: bitrepository-devel-bounces@ml.sbforge.org [bitrepository-devel-bounces@ml.sbforge.org] på vegne af Jonas Lindberg Frellesen [jolf@kb.dk] Sendt: 31. august 2012 11:40 Til: List for the Bitrepositorys developers Emne: [Bitrepository-devel] Forslag til BitRepository massprocessing

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
 

Anden mail (Eld)

Hej
Jeg er sikker på I vil kunne få en del ud af at læse Bolettes og min artikel fra VLDL sidste år (vedhæftet - husk den er under copyright).
Det er vigtigt at skelne mellem 

• hvad der er det er på protokolniveau - det skal nemlig passe for alle pillars generelt - og parametrene er diskuteret i artiklen
• Hvad der er implementering op mod protokollen
• Hvad der er implementering på den enkelte pillar

Heri ligger også hvordan protokollen kan understøtte mere manuelle trin, såsom QA.
Mvh. Eld

Tredje mail (Kåre)

Hej alle,
Jeg synes det er et fremragende forslag.
Jeg har faktisk i længere tid været skeptisk overfor at det gav mening at lave mass processing som en generisk service på bitmagasinet, men "guldægget" i denne løsnning som jeg ser det er at afkoble deployment, og henvise til det pr. id. Med den løsning synes jeg faktisk det giver værdi. Det er muligt det er en gammel indsigt, jeg har ikke fulgt udviklingen på Bitmagasinet et stykke tid 
Et ekstra input er at prøve at sætte løsningen op overfor helt konkrete use cases – jeg tror der kan trækkes nogen ud af det oprindelige strategiprojekt.
Her er et par eksempler man kunne tage udgangspunkt i:

• Man har et arkiv af videofiler. Man ønsker at levere en videofil i et andet format (det er det prototypiske eksempel på single file processing)
• Man har et arkiv af html-filer. Man ønsker at lave frekvensanalyse af ord i html-filerne.
• Man har et arkiv af TIFF-filer. Man ønsker at lave et JPG-preview af alle filer
• Man har et arkiv af WordPerfect 5.1-filer. Man ønsker at migrere dem til PDF.

Single vs. mass-processing har primært været beskrevet separate fordi der er nogle karakteristika ved hver, som er nemmest at se hvis man adskiller dem. I mit single file processing-eksempel ovenfor kan det f.eks. være svært at se hvordan det samme job skulle fungere på en enkelt og mange filer. Ved en enkelt fil skal den transformerede fil leveres til resultat-URL'en. Hvad skal der ske hvis jeg angiver to filer? Skal jeg blot konkatenere dem efter hinanden? Skal jeg lave en TAR eller ZIP fil? Skal jeg bare generere en fejl?
Jeg tror jeres forslag fint kan dække de fleste use-cases ovenfor. Det nederste er dog et interessant tilfælde, hvor resultatet faktisk skal gemmes i bitmagasinet. Det kan overvejes om man ønsker at lave understøttelse for det direkte i protokollen.
Hilsen
  Kåre

Fjerde mail (Mikis)

Tak for inputtet, det er noget lettere at forholde sig til processing på baggrund af konkrete use cases.
Mht. til skelning om et givet ProcessingJob giver mening på  en eller flere filer, mener jeg ikke at vi på protokol xsd basis kan sikre at der ikke bliver sendt argumenter der kan være indbyrdes  inkonsistente. Vi har allerede i andre typer meddelelser accepteret at kan ligge forretningsregler som ikke kan verificeres vha. xsd'en. Det samme vil gøre sig gældende her, der er brug for noget ekstra beskrivelse/definition af gyldigheden af parameter, evt. defineret i den executable der definere Jobbet. Så hvis der ikke er defineret håndtering af flere filer vil Jobbet fejle med InconsistentRequest, hvis der gives flere filer med (eller der gives en forkert fil type med etc.). 
Mvh
Mikis 

Femte mail (Eld)

Hej
 
Nåh ja, jeg glemte også lige at kommentere på singleprocessing
De use-cases der er skrevet er

• Streaming
• Checksum på del af fil

Altså noget som kun er ment for en fil ad gangen, hvor cheksumseksemplet, især giver mening for store filer som man ikke har lyst til at overføre for at lave beregningen.
 
Mvh. Eld