1 ecpr erstatnings CPR Design og arkitektur
Indhold ecpr erstatnings CPR... 1 Indhold... 2 Formål... 3 Overblik... 4 Snitflader... 4 Komponenter... 5 Webservice... 5 Statuskomponent... 5 Forretningslag... 5 Databasedesign... 6 Ikke funktionelle krav... 7 Sikkerhed... 7 SLA logning... 7 Audit logning... 7 Idempotens... 7 Ændringslog... 9 2
Formål Dette dokument giver et overblik over ecpr service med fokus på design og arkitektur. Dokumentet giver et overblik over løsningens snitflader samt den interne struktur. Desuden indeholder det en beskrivelse af håndtering af ikke funktionelle krav. 3
Overblik ecpr tilbyder services til - Trækning af erstatningscprnumre - Oprettelse af kobling mellem erstatningscprnummer og identitet - Fjernelse af kobling mellem erstatningscprnummer og identitet - Forespørgsel på erstatningscprnummer Forretningsdata persisteres i en relationel database. Snitflader Løsningen har en ekstern snitflade, der udstiller de ovenfor nævnte services som webservices. Der er ikke afhængigheder til andre services, men til komponenter til håndtering af autentifikation (SEAL) og SLA logning (NSPUtils). 4
Komponenter Løsningen er designet som en JEE applikation bestående af følgende komponenter: Webservice JaxWS webservice komponent, der udstiller de forretningsmæssige services. Denne komponent håndterer protokol og headers. Håndtering af headers WSSecurity IDCard læses fra SOAPHeader og sættes det på threadlocal. Kan kortet ikke læses, eller er signaturen ugyldig afvises brugeren. I svaret tilføjes en WSSecurity header med et timestamp. Medcom På vej ind gemmes Medcom header på Threadlocal. På vej ud tilføjes Medcom header baseret på den indkomne. Statuskomponent Monitorering En simpel servlet, der returnerer ok (http kode 200), hvis systemet er tilgængeligt. Desuden er det muligt at få detaljer om, hvilke komponenter, der er i live eller fejler. Versionsinfo En servlet, der fortælle hvilken version af løsningen, der er den aktuelle. Forretningslag Indeholder forretningslogikken samt sikkerhed. Autentifikation og autorisation IDCard fra Threadlocal og autentificerer kalderen ved at kontrollere, at kortet er gyldigt og ikke udløbet. Herefter autoriseres brugeren, idet det verificeres, at denne har det fornødne niveau (medarbejder eller virksomhed) og er at finde på en hvidliste. Forretningslogik En stateless ejb modtager kald fra webservicelaget og delegerer til andre services, der hver især håndterer hhv. dannelse af erstatningscprnumre samt håndtering af persistens. Domain Indeholder JPA klasser til persistering. 5
Afhængigheder mellem komponenter Databasedesign ErstatningsCPRnumrene gemmes i én tabel, hvor erstatningscprnummeret (unikt) gemmes med de data, der har dannet grundlag for dannelsen samt evt. tilknytning til et person ID. 6
Ikke funktionelle krav Sikkerhed Løsningen er sikret med IDCard, der enten kan repræsentere en person eller en myndighed. Når en kalder er autentificeret verificeres adgang med tjek mod en databasebaseret hvidliste. Listen er på baseret på CVR numre og enten skal kalderen være knyttet til myndigheden (hvis kalderen er en person) eller repræsentere myndigheden (hvis det er et system). Ved hver enkelt servicekald verificeres det, at kalderen har den fornødne rolle (myndighed eller medarbejder), og at det medfølgende IDCard overholder levetidskravet til det konkrete kald. Autentifikationen håndteres af en soap handler, der hvis autentifikationen er succesfuld binder IDCard til en threadlocal. Webservicen er omkranset af en interceptor, der forestår autorisationen ved at sammenholde IDCard med en hvidliste. SLA logning Der logges med brug af NSPUtils biblioteket: Et filter opretter en log entitet, der senere beriges med messageid fra Medcom headeren. SLAloggen gemmes i en tekstfil, og dens udseende kan konfigureres. Audit logning Ved alle kald registreres - Information om kalder (myndigheds CVR nummer; hvis kalderen er en person, repræsenterer CVR nummeret den myndighed, personen er tilknyttet. - Den kaldte metode. - De medsendte parametre i json format. På de metoder, der opretter erstatningscprnumre gemmes denne information dog ikke. Auditloggen gemmes i en tekstfil, og dens udseende kan konfigureres. Idempotens Den gode Webservice stiller krav til idempotens for at sikre, at en kalder kan gentage et kald uden risiko for sideeffekter. I indeværende løsning er dette krav implementeret ved: - Gentaget kald til oprettelse fører til en nyoprettelse. Da et nyoprettet erstatningscprnummer ikke har nogen betydning, er det for modtageren helt uden forskel, at der dannes et nyt. - Opslag. Ved opslag returneres altid nyeste data. 7
- Kobling. Ved oprettelse af kobling mellem erstatningscprnummer og identitet returneres OK, hvis koblingen forekommer ved afsendelse af svaret. Med andre ord vil et gentaget kald give samme svar som det første kald. - Afkobling. Ved fjernelse af kobling returneres OK, hvis koblingen ikke forekommer ved afsendelse af svaret. Et gentaget kald vil således give samme svar som det første kald. Overordnet sekvensdiagram. I dette tilfælde illustreret med en fiktiv metode ( create ecpr ). Flowet er på overordnet niveau det samme for alle kald. 8
Ændringslog Version Dato Ændring Ansvarlig 0.1 30.09.2013 Initielt dokument Openminds 9