Page History
...
- idsas-registration: Den primære service som håndterer "Slørring". Her findes operationen operationerne "CreateBlurring" . Under udvikling: Herinde finder man også det kommende "afdelingssløringog "CreateOrgBlurring".
- idsas-lookup: En service der kun håndterer "Opslag", dvs. operationen "GetBlurredOrganisations".
- idsas-salt: En service der håndterer hentning af salt, dvs. operationen "GetCurrentSalt".
- idsas-operations: En service der kun benyttes af driften til automatiske jobs.
De fire services er ret ens opbygget, har en del fælles kode som de deles om via et maven-modul, har samme programstruktur og bruger samme database-modul.
| Gliffy Diagram | ||||||||
|---|---|---|---|---|---|---|---|---|
|
De fire services har tilsammen følgende moduler i maven:
| Modulnavn | Beskrivelse |
|---|---|
| idsas-api | Selve API'en, for de tre eksterne services, defineres i dette modul som WSDL-filer. Modules primære formål er at generere Java-kode ud fra WSDL'erne, som kan bruges i de andre moduler. |
| idsas-common | Fælles kode for de to moduler, primært utility-funktioner og DAO-klasser. |
| idsas-integration-tests | En modul som indeholder alle integrationstests for begge services. |
| idsas-integrations | Et modul som indeholder integrationer, pt. kun "personinformation". Anvendes af "idsas-services". |
| idsas-services | Forretningslogik til alle services findes i dette modul, samt forretningslogik til de to batchjobs i "idsas-operations-web". |
| idsas-lookup-web | Web-modulet til Opslag, som håndterer opstart af service og producerer den war-fil, der skal deployes. |
| idsas-registration-web | Web-modulet til Slørring, som håndterer opstart af service og producerer den war-fil, der skal deployes. |
| idsas-salt-web | Web-modulet til hentning af salt, som håndterer opstart af service og producerer den war-fil, der skal deployes. |
| idsas-operations-web | Web-modulet med endpoints til automatiske jobs: Fornyelse af salt, sletning af inaktive sløringer. |
Driftsarkitektur
...
Denne del er under udvikling
...
I praksis er de forskellige services fordelt på BackOffice og en eller flere Frontend-miljøer. Registration, Lookup og Salt kører alle på et NSP Frontend-miljø, og via en Kafka-kø, bliver alle ændringer sendt igennem MirrorMaker til Operations-servicen på NSP BackOffice. Det er her alle ændringer bliver persisteret til databasen.
Dog vil der i en overgangsperiode også være en Registration-service kørende på NSP BackOffice, som skriver direkte til databasen, når den bliver kaldt. Dette er for er være bagudkompatibel med de anvendere, som tog IDSAS i brug, før der blev omlagt til at sende alle ændringer igennem en Kafka-kø.
| Gliffy Diagram | ||||||
|---|---|---|---|---|---|---|
|
...
Sikkerhed
Brugertyper
De enkelte brugertyper bestemmes ud fra modellen, der udstilles i Security API. Disse regler er opsummeret i skemaerne herunder. Sikkerhedsmodellen tager udgangspunkt i Security API - Guide til anvendere.
...