Demo for første sprint

Transkript

1 Demo for første sprint Første sprint for einnsyn PoC Dette dokumentet beskriver det som er utviklet og testet i den første sprinten fra 8. til 19.februar (to uker). Leveransen i forhold til arkitekturforslaget Gjennom sprint 1 har vi fokusert på de to sentrale elementer. Sentraliteten ble vurdert etter risiko for ytelse med store datamengder. Vi fant ut at mottak av testdata samt indeksering og lagring og enkle tester på responstider var de to sentrale komponenter. Mottak, validering og metadatalagring Mpttaksdelen er utviklet som en enhetlig Java applikasjon som mottar data gjennom et REST grensesnitt. Data som godtas er NOARK5 (versjon?) levert av Difi som eksempelfil. Mottatt data konvereres så til RDF og sendes til en Stardog database samt til en Elastic Search database i parallell. Implementasjonen av mottaksdelen foretar kun en syntaktisk validering. Mottatt data lagres ennå ikke ved mottaket. Indeksering RDF data sendes direkte til en Stardog database ghennom Sesame. RDF data går gjennom en enkel konvertering til JSON-LD. Kun Journalpost og dens tittel er konvertert og sendt til en Elastic Search database. Leveransen i forhold til planleggingen Under oppstartsmøte for denne sprinten planla man følgende leveranse:

2 Fokus var på utvikling av basislogikk for å motta data og indeksere den i en Elastic Search database, samt etablering av en loggingsplattform. Vi fant ut at belastningstest av en grafdatabase hadde en høyere risiko og bestemte oss for endre vårt fokus. Følgende er det overordnede diagrammet for denne leveransen.

3 Komponentisering med Docker Arbeid med komponentisering var ikke planlagt. Vi fant fort ut at vi kunne spare arbeid ved å starte tidlig med å isolere noen komponenter i sine egne Docker images slik at testing og oppsetting av den komplette applikasjonen kunne utføres med mindre manuelt arbeid. En viktig faktor var at vi ikke fikk SSH tilgang til serverne fra våre kontorer. XML pakke Vi bruker NOARK5 eksempelfiler levert av Difi. NOARK5 til RDF konvertering Vi bruker Python skriptet for denne konverteringen levert av Difi. Skriptet er endret for I/O piping og er komponentisert med en REST/HTTP tjeneste. Elastic Search Denne er en standard Docker image som hentes fra offentlig registry. Stardog Denne komponenten er en Docker konfigurasjon som pakker inn en 60 dagers lisensiert Stardog database. Java-applikasjon Denne er en Java applikasjon utviklet med uavhengige moduler (Maven artifacts) som enkelt kan splittes senere. Modul REST grensesnitt HTTP klient Sesame med RDF RDF til JSON-LD SparQL Beskrivelse Mottar NOARK5 XML filer via HTTP Sender NOARK5 XML til konverteringskomponenten og mottar RDF-svaret. Protokollen er REST/HTTP. RDF dokumentet blir sendt videre til de to indekseringsmoduler Sender RDF direkte til Satrdog Konverterer Journalpost med sin tittel til JSON-LD og sender dem videre til en indekseringmodul Sender JSON-LD direkte til Elastic Search Java CLI Testapplikasjon skrevet i Java som genererer tilfeldig NOARK5 data og lagrer det i Stardog. Eksekveres fra kommandolinjen på en utvikler-laptop. Laptopen for import bruker en 2.8 GHz Quadcore CPU, har 16GB RAM og SSD disk og kjører Windows 8. Laptopen for spørring bruker 2.8 GHz Quadcore, har 16GB RAM og bruker høyhastighets SSD disk. Den kjører Mac OSX. Vi ser (ikke overraskende) stor forskjell mellom SATA og SSD disker under opplasting og spørringer på databasene når det kommer til lese- og skrivehastighet. For mengden tripler vi skal generere trenger vi ca GB lagringskapasitet for én database med i overkant av 200 millioner tripler. Med SSD er opplastingshastigheten her ca. 33 minutter, mens for SATA er den ukjent. Spørringer på opplastet Stardog database tar 27 til 43 ms for å hente en sak med sine journalposter. Emn komplett telling av alle lagrede forekomster tar mindre enn ett sekund.

4 Leveransen i forhold til en Continuous Delivery pipeline Følgende er den komplette leveranse pipeline for einnsyn. Dette er et målbilde som går utover det som inkluderes i PoCen. Det er dog viktig for å presentere hvor lang vi er kommet i etableringen av en pipeline. og følgende er den leveranse pipeline som er levert i sprint 1: I denne sprinten har vi definert en Jenkins oppgave for hver av de fire Docker komponentene. Hver oppgave henter sin egen gren fra et felles Github repo, kompilerer, eksekverer de eksisterende testene, bygger en Docker Image og leverer det til Docker Registry. Deretter kopieres det en Docker applikasjonsbeskrivelse til Test-serveren app01. Til slutt eksekverer Jenkins en fjernkommando på app01 for å starte testen basert på applikasjonsbeskrivelsen. Belastningstesten kjøres i dag direkte på en utvikler laptop. Vi har allokert 4GB RAM for Stardogs JVM og 12GB for off-heap caching. Etterlevelse av grunnprinsippene I det følgende Oppsummeres det i hvilken grad vi har dekket grunnprisippene for einnsyn i denne leveransen. Vi refererer leseren til kontraktsbilaget for løsningen for en nærmere beskrivelse av hvert grunnprinsipp. Etterlevelsen er et subjektiv vurdering av hvor langt vi er kommet i arbeidet for å dekke hvert grunnprinsipp. Noter at dekningsgraden av hvert grunnprinsipp ikke alltid er komplett.

5 Grunnprinsipp Sprint 1 Kommentar Funksjoner som åpner seg med denne løsningen Støtte for eksisterende grensesnitt mot dataleverandører Løs kobling mellom komponentene 10% Enklere forvaltning. 100% Det forutsettes at det eksisterende grensesnittet mot dataleverandør er en nærmest uavhengig "staging" modul hvor dataleverandør kan teste sine leveranser før de sendes inn til OEP.no. Dermed kan dette grensesnittet enkelt kobles til det nye einnsyn 30% Selv med en Java-applikasjon med flere moduler har vi allerede en god del komponentisering Kontinuerlig leveranse 30% Grunnmaskineriet er på plass.selv med ad-hoc SCP/SSH. Gjenoppbygging av løsningen Endring/sletting av eksisterende poster 0% 0% Dataformater 30% Vi støtter NOARK5, men mangler en god del JSON-LD konvertering Enkle og kompliserte søk 10% Vi gå raskt opp med mer komplett JSON-LD. Søk i Navigering i innhold og struktur Visualisering av tekst og kart Forvaltning og videreutvikling 10% 30% 100% Bruk av åpen kildekode -- Åpen kildekode brukes for alle komponenter bortsett fra Stardog Kontinuerlig og automatisk overføring fra dataleverandørene Indeksering av metadata og innhold 30% 20% Grunnlogikk er på plass.