Presentasjon av arbeidet med einnsyn Proof of Concept

Transkript

1 Presentasjon av arbeidet med einnsyn Proof of Concept Dette dokumentet beskriver resultatet av arbeidet med einnsyn Proof of Concept prosjektet med fokus både på leveransen og de utfordringene som er avdekket. Prosjektet startet den 4. februar og sluttet den 31. mars Leveransen i forhold til arkitekturforslaget Det opprinnelige forslaget Prosjektet startet med en arkitekturoverblikk som presenteres her: Det er et par viktige egenskapene med dette arkitekturforslaget som er verdt å legge merke til og som er blitt retningsgivende for prosjektet. En del upresise sammenhenger i dette forslaget er blitt rettet opp i løpet av utviklingen, noe vi skal tilbake til når vi presenterer leveransen. Men her ser vi først på retningsgivende egenskapene. En mikrotjenesteorientert arkitektur: De modulene presentert her som uavhengige komponenter som støtter en mikrotjenestearkitektur. Felles benevning: Et viktig særtrekk i en mikrotjenestearkitektur er å komme frem til en felles benevning av arbeidsprosessen. Begrepene som Mottak, Beriking, Indeksering, Logging og administrasjon, samt Formidling har etablert seg for å få en felles forståelse. Et klart skille mellom Mottak og Formidling som gjør det mulig å opprettholde brukergrensesnittet for søk og navigering, selv om mottak og prosessering er nede. Logging og administrasjon som et viktig arbeidsområde både for utvikling og produksjon og helt i tråd med en arkitektur som støtter mikrotjenester. En gjennomgang av den faktiske leveransen i dette prosjektet skal vise hvilke rettelser på Side 1

2 arkitekturforslaget vi har foretatt. Leveransen Vi har delt arbeidet mellom utviklingen av løsningen - den funksjonelle delen - og opprettelsen av an arkitektur for mikrotjenestene med hovedvekt på kontinuerlig leveranse. Her følger en oversikt over den funksjonelle delen av leveransen for dette PoC prosjektet. Utviklingsarbeidet i PoC bærer preg av et tidsbegrenset prosjekt med ett hovedmål: å dekke de mest kritiske områdene for å avdekke muligheter og problemer, noe som vi mener å ha oppnådd. Dermed har testing og kvalitetsikring av koden ikke fått den nødvendige fokus. Generelt er det viktig for den videreutviklingen å gjøre løsningen robust med en stabilisering av koden og støtte for utbredt testing på alle nivåer. Det siste er viktig for å støtte en sikker kontinuerlig leveranse. I den følgende tabellen skal vi fokusere på de kommende utfordringene. Komponent activemq rest NOARK5 rest NOARK54 Utfordringer og utestående ActiveMQ er etablert som integrasjonsplattform. Den eksisterende løsningen har to svakheter: Tekniske problemer med protokollen; og stivhet når man skal legge til nye tjenester uten å stoppe deler av løsningen. Mottakskomponenten er godt etablert og trenger bedre testing og en klarere definisjon av datastrukturen. Denne komponent er ansvarlig for å melde tilbake om innsendt data er godtatt eller avvist. Den burde derfor eksekvere en semantisk validering (se lengre ned) før man returnerer resultatet til innsenderen. Det er et enkelt REST grensesnitt som ikke trenger mer innsats. Det er et enkelt REST grensesnitt som ikke trenger mer innsats. Side 2

3 rest JSON-LD persistence noark4tonoark5 noarktordf splitt mysql noark5tordf validation data-type-enrichment stardog-client stardog es-client elasticsearch api api navigering api søk frontend ngnix Det er et enkelt REST grensesnitt som ikke trenger mer innsats. Denne mottaksmodulen burde flyttes ut til mysql komponenten. Grunnen er å være i stand til å bytte lagringen uten å endre koden i. Denne modulen trenger å merke avviste sendinger med en feilmelding eller eventuelt fjerne dem. Man bruker XSLT for konverteringen. Dette krever lengre prosesseringstid enn alle andre moduler i. Ved høye responstidskrav på datamottak kan den isoleres i en egen kompoenent for enkel oppskalering. XSLT definisjonen er blitt tilpasset den faktiske datamodellen vi har landet på. Denne modulen er en enkel klient som kaller noark5tordf for å få konverteringen utført. Denne modulen splitter ennå ikke. Denne komponenten er en standard mysql database i et docker image og er godt etablert. Persistence-modulen burde flyttes hitt. Denne komponenten bruker et python program levert av Difi. Det er blitt endret for å tilpasses en tjeneste og i forhold til den datamodellen vi har landet på. Denne komponenten burde flyttes inn i for å gi et entydig svar til dataleverandørene. Denne komponenten skal erstattes av en stabil datamodell. Denne komponenten eller en ny komponent som samler denne og es-client trenger støtte for transaksjoner hvis oppdatering/sletting feiler enten her eller i es-client. Det forventes behov for skalering av denne komponenten for å støtte de forventede datamengdene. Kommersiell lisens for stardog trenges utover en viss datamengde, eler for belastningsteter og produksjon. Denne komponenten eller en ny komponent som samler denne og stardog-client trenger støtte for transaksjoner hvis oppdatering/sletting feiler enten her eller i stardog-client. Det forventes behov for skalering av denne komponenten for å støtte de forventede datamengdene. Denne komponenten samler APIene for navigering og søk. Denne modulen trenger å forholde seg til en stabil datamodell. Denne modulen trenger å forholde seg til en stabil datamodell. Denne komponenten trenger å støtte ny funksjonalitet som stammer fra JSON-LD strukturen. Denne komponenten er stabil. Side 3

4 logstash elasticsearchlogs kibana Denne komponenten betjener loggdata på kun én server. Den skal samle data fra flere servere når einnsyn splittes for utrulling til flere servere. Denne komponenten er stabil. Denne komponenten kan eventuelt utvides for å dekke nye overvåkingsbehov. Arkitektur Her presenteres det noen hovedelementer i en mikrotjenestearkitektur. Domenedrevet design einnsyn kan deles i kontekster som tilsvarer de begrepene som allerede er i bruk i prosjektet som vist i dette diagrammet. Hver kontekst har sitt eget ansvarsområdet og dermed sin datamodell. Konteksten Mottak trenger et stabilt grensesnitt mott dataleverandørene med de tre støttede formater. Den har ansvar for validering og tilbakemelding til innsenderen. Datamodellen trenger derfor å være stabil og veldefinert. Denne konteksten leverer innover data i JSON-LD format og det trengs en ontologi som definerer en omforent format for NOARK4 journalpost, NOARK5 arkiv og Bouvets JSON-LD modell eller eventuelt andre. Konteksten Beriking har som hovedansvar å levere data til endrede eller nye funksjonalitetskrav. Det er her man endrer eller beriker data for å dekke nye behov. Datamodellen som passer best her er en fleksibel utvidelse av Mottaks datamodell med tolerante tjenester som leser kun de elementene som trenges og leverer nye elementer etter behov. Konteksten Indeksering har som hovedansvar å fore neste kontekst med data. Lagring av beriket data inn i Stardog trenger ikke stor innsats for å dekke nye berikinger eller endringer. Lagring i Elasticsearch derimot trenger å støtte avansert søk av nye berikinger. Målet er å begrense innsatsen for å dekke disse endringene med en fleksibel indeksering og begrense kravene på avansert søk. Konteksten Formidling har som hovedansvar å presentere data for brukeren på en intuitiv måte som støtter fleksibel navigering i en kompleks struktur med økende beriking. Det kan ikke unngås at komponenter i denne konteksten må oppdateres for å presentere nye berikinger eller endringer i data. Leveransen i forhold til en Continuous Delivery (CD) Side 4

5 Arbeidet i prosjektet har brukt en god del v sin arbeidstid for å sette opp en plattform for CD. Dette er en forutsetning for en vellykket mikrotjenestearkitektur. Vi har klart å automatisere noen trinn i cd som PoC prosjektet har etablert grunnlaget for en pipeline for kontinuerlig leveranse som vist i dette diagrammet. Vi har utvikler en struktur med uavhengige komponenter som alle er en del av et github r epo. Java logikken i noen av komponentene bruker en felles Maven archetype og er ellers uavhengige av hverandre. Det er viktig å beholde full uavhengighet mellom komponentene, da kan man utvikle komponenter på forskjellig språk og komponenter som bruker foskjellige metoder for å dekek spesialiserte behov. Byggerutinene som tar form i Difis Jenkins server er ryggraden i CD. Vi kompilerer, kjører enhetstester, pakker dokker-komponenter og sender dem til en integrasjonstest og til en demoserver. I tillegg har vi allerede datageneratorer som lser datafiler, JSON-LD databaser eller genererer NOARK5 data og som kan brukes i nye integrasjons- og belastningstester. En god del av det kommende arkitekturarbeidet vil sentrere seg i vedlikehold og videreutvikling av disse byggerutinene. Komponentisering Docker er innført som eneste plattform for komponentisering. Dette gir stor fleksibilitet som ennå ikke er tatt i bruk i sin full bredde. Det gjenstår å splitte dagens enhetlige applikasjonen i mindre deler som følger behov for skalering og effektiv lagring. Logging og administrasjon Side 5

6 Et viktig element i en mikrotjenestearkitektur er bruken av logging og administrasjon. I PoC har vi att logging i bruk på et tidlig tidspunkt: Det er den enkleste måten å følge gangen prosesseringen når den går gjennom mange uavhengige komponenter. Det som ikke ennå ikke er dekket er administrasjonsdelen med støtte for å løse problemer med data som stopper opp under prosesseringen eller ikke vises riktig. Kvaliteten til et system er tross alt avhengig av hvordan det takler uventede hendelser, stort sett med manuelle rutiner. Teamarbeid Arbeidet i teamet har utviklet seg i en positiv retning. Kunden er sterkt til stedet med klare avgrensninger og føringer. Utviklerne har vist dyktighet og stor kunnskap i de verktøyene og den arkitekturen vi har valgt, med frihet under ansvar. Det er et høyt kompetent team med sterk engasjement for å utvikle et godt einnsyn. Det er all grunn til å videreutvikle dette teamet i denne retningen. Etterlevelse av grunnprinsippene I det følgende kommenteres det i hvordan man muliggjør grunnprisippene for einnsyn i denne leveransen. Vi refererer leseren til demodokumentet for Sprint 4 for en forklaring på dekningsgraden i prosent. Grunnprinsipp Sprint-4 Kommentar Funksjoner som åpner seg med denne løsningen Støtte for eksisterende grensesnitt mot dataleverandører Løs kobling mellom komponentene Kontinuerlig leveranse Gjenoppbygging av løsningen 40% Bruken av JSON-LD og de muligheter den gir åpner for rikere og enklere navigasjon i data og ny funksjonalitet. Splitting i enkeltstående komponenter fleksibiliserer bruk av infrastruktur for å tilpasses endrede behov. Den samme splittingen forenkler forvaltning slik at man kan fokusere på funksjonalitetsområder for endring eller forbedring uten å påvirke resten av løsningen. -- Bruk av en REST tjeneste for mottak av NOAKR4 data og behandlingen av dette formatet støtter det eksisterende grensesnittet for dataleverandørene. 70% Bruk av enkeltstående komponenter i en mikrotjenestearkitektur åpner for en teknisk løs kobling som langt overgår monolittiske applikasjoner og SOA integrasjoner. Det er do fortsatt behov for en fleksibel datamodell som disse komponentene enkelt kan forholde seg til. 70% PoC har stått på to ben: utvikling av funksjonalitet og opprettelse av en plattform for kontinuerlig leveranse som er godt på vei. 20% Mottatt data lagres og merkes slik at gjenoppbyggingen av data som løsningen bruker er en enkel oppgave. Løsningen selv kan i dag gjenopprettes ved enkel utrulling av en eksisterende versjon. En komplett automatisert Kontinuerlig leveranse vil være i stand til å rulle ut enkeltkomponenter uten å påvirke resten av løsningen utover den logiske avhengigheten av bestemte versjoner. Side 6

7 Endring/sletting av eksisterende poster 30% Endring av journalposter, korrespondansepart og saksmapper er på plass. Sletting er kun en spesialisering av endring. Dataformater 60% einnsyn støtter i dag mottak av NOARK4 (journalpost.xsd), NOARK5 (arkiv.xsd) og Bouvet-versjonen av JSON-LD. Data i disse formatene konverteres ved mottak slik at beriking, indeksering og formidling kan forenkles. En stabil dataformat er nødvendig for full støtte av alle innkommende dataformater. Enkle og kompliserte søk Navigering i innhold og struktur Støtte for visualisering av tekst og kart Forvaltning og videreutvikling Bruk av åpen kildekode Kontinuerlig og automatisk overføring fra dataleverandørene Indeksering av metadata og innhold 40% Søkefunksjonaliteten støtter enkel søk på tvers av alle felt i JSON-LD, filtrering og søk på noen av feltene. 40% Navigering mellom saksmappe til journalpost støttes. Det bør utvides til å dekke hele strukturen. 20% Beriking med geografisk plassering er levert. Det trengs kun visualisering. 100% Alt arbeid så langt er under Difis premisser, på Difis anlegg og danner grunnlag for effektiv forvaltning -- Åpen kildekode brukes for alle komponenter bortsett fra Stardog. 100% Opplasting av data gjennom de tre REST tjenestene kan brukes både for kontinuerlig og automatisk overføring. 60% Indeksering av metadata trenger en stabil definisjon av datamodellen fro å fullføres. Side 7