D-8) IMEA Katern Service Gerichte Architectuur

Document D-8
Ministerie van Infrastructuur en Milieu
IMEA - Katern - Service Gerichte Architectuur
Versie 1.0
Datum
Status
15 juli 2014
Definitief
Definitief | IMEA - Katern - Service Gerichte Architectuur | Versie 1.0
Colofon
Versie
1.0
Contactpersoon
Paul Leunissen
M 06 - 5250 6691
[email protected]
Ministerie van Infrastructuur en Milieu
Hoofddirectie Financiën, Management en Bedrijfsvoering
Directie Concern Informatievoorziening
Afdeling Architectuur en Informatie Management
Team Architectuur
Koningskade 4
Postbus 20906
2500 EX Den Haag
Auteurs
Peter Visser
Stephen Oostenbrink
Pagina 2 van 38
Definitief | IMEA - Katern - Service Gerichte Architectuur | Versie 1.0
Inhoud
1
Inleiding ........................................................................................................... 5
1.1
Identificatie .................................................................................................................. 5
1.2
Leeswijzer .................................................................................................................... 5
1.3
Doel van dit document .................................................................................................... 5
1.4
Referenties ................................................................................................................... 5
1.5
Afkortingen en begrippen ................................................................................................ 5
2
Service Gerichte Architectuur .............................................................................. 6
2.1
Inleiding ...................................................................................................................... 6
2.1.1
Architectuurkeuze Service Gerichte Architectuur .................................................................. 7
2.2
Servicecontract ............................................................................................................. 7
2.3
Performance ................................................................................................................. 8
2.4
Onderscheid externe en interne informatie-uitwisseling......................................................... 9
2.4.1
Externe informatie-uitwisseling ........................................................................................ 9
2.4.2
Interne informatie uitwisseling ......................................................................................... 9
2.4.3
Architectuurkeuze onderscheid interne en externe informatie-uitwisseling .............................. 10
2.5
Stelsel van ESB’s met het Centraal Aansluitpunt ................................................................ 10
2.6
Centraal Aansluitpunt ................................................................................................... 11
2.6.1
Architectuurkeuze stelsel van ESB’s met een Centraal Aansluitpunt ....................................... 12
2.7
Domein specifieke koppelingen....................................................................................... 13
2.8
Beveiliging ................................................................................................................. 13
2.9
Versies ...................................................................................................................... 14
2.9.1
Architectuurkeuze ondersteuning versies.......................................................................... 14
3
Service gerichte architectuur: verdieping ............................................................ 15
3.1
Servicelagenmodel ....................................................................................................... 15
3.1.1
Interactiekanalen ......................................................................................................... 17
3.1.2
Processervices ............................................................................................................ 17
3.1.3
Business services ......................................................................................................... 17
3.1.4
Technische services...................................................................................................... 18
3.1.5
Backend ..................................................................................................................... 18
3.2
Service principes ......................................................................................................... 19
3.3
Communicatieprincipes ................................................................................................. 19
3.4
Ontwerpprincipes ......................................................................................................... 20
3.5
Proces en compositie .................................................................................................... 21
3.5.1
Orkestratie ................................................................................................................. 21
3.5.2
Taken service.............................................................................................................. 21
3.5.3
BPEL4People ............................................................................................................... 21
4
Informatie-uitwisseling ..................................................................................... 22
4.1
Inleiding .................................................................................................................... 22
4.2
Informatie-uitwisseling lagenmodel ................................................................................. 22
4.3
Elektronisch berichtmodel ............................................................................................. 24
5
Informatie-uitwisseling: verdieping .................................................................... 26
5.1
Enterprise service bus .................................................................................................. 26
5.2
Koppelvlak ................................................................................................................. 28
5.3
Endpoints ................................................................................................................... 28
5.4
Beveiliging ................................................................................................................. 29
5.5
Herleidbaarheid ........................................................................................................... 30
Pagina 3 van 38
Definitief | IMEA - Katern - Service Gerichte Architectuur | Versie 1.0
6
Informatie-uitwisseling: standaard uitwisselingsformaat ....................................... 31
6.1
Inleiding .................................................................................................................... 31
6.2
StUF berichtenstandaard ............................................................................................... 31
6.3
StUF protocolbindingen ................................................................................................. 32
6.4
StUF horizontale sectormodellen ..................................................................................... 32
6.5
StUF verticale sectormodellen ........................................................................................ 32
6.5.1
Architectuurkeuze standaard informatie-uitwisseling .......................................................... 32
7
Informatie-uitwisseling: e-Overheid bouwstenen ................................................. 33
7.1
Beschikbare bouwstenen ............................................................................................... 33
7.2
Diginetwerk ................................................................................................................ 33
7.3
Digikoppeling .............................................................................................................. 33
7.4
Digipoort .................................................................................................................... 34
7.4.1
Architectuurkeuze generieke bouwstenen voor informatie-uitwisseling ................................... 34
8
Bijlage A: Informatie-uitwisselingsmodel uitgebreid ............................................. 35
9
Bijlage B: PKIoverheid certificaten ..................................................................... 36
Pagina 4 van 38
Definitief | IMEA - Katern - Service Gerichte Architectuur | Versie 1.0
1
Inleiding
1.1
Identificatie
Dit document beschrijft de eisen die het Ministerie van Infrastructuur en Milieu
(IenM) stelt aan de Service Gerichte Architectuur (SGA). Een systeem dat hieraan
voldoet mag uitgerold worden naar het IenM domein.
1.2
Leeswijzer
Om dit document te begrijpen wordt geadviseerd het document geheel door te
nemen.
1.3
Doel van dit document
Het doel van dit document is om leveranciers te informeren over de eisen waaraan
een systeem opgezet op basis van SGA principes moeten voldoen.
1.4
Referenties
De volgende documenten zijn relevant om dit document goed te begrijpen.
#
1
2
3
1.5
Referentie
Afkortingen en
begrippen
SP
Aansluitvoorwaarden
Document
IenM - Standaard Platform - Afkortingen en begrippen –
v1.0.docx
IMEA - Katern - Standaard Platform - v1.0.docx
IenM - SP Koppelingen - Eisen - v1.0.docx
Afkortingen en begrippen
Zie voor een toelichting op de gehanteerde afkortingen en begrippen het document
[Afkortingen en begrippen].
Pagina 5 van 38
Definitief | IMEA - Katern - Service Gerichte Architectuur | Versie 1.0
2
Service Gerichte Architectuur
2.1
Inleiding
In een Service Gerichte Architectuur (SGA) wordt gedacht in en gewerkt met
services en is het denken in aparte, alles omvattende systemen losgelaten. Een
systeem wordt niet langer gezien als een op zichzelf staand geheel dat zelfstandig
en los van andere systemen functioneert, maar als een samenstel van services.
Een service is een zelfstandig stuk functionaliteit en bijbehorende data, met een
goed gedefinieerd en gestandaardiseerd koppelvlak, dat onafhankelijk werkt van de
front- en backend systemen die gebruik maken van die functionaliteit. Een service is
technologie, leverancier en productneutraal, waardoor systemen met verschillende
onderliggende technieken kunnen samenwerken. Door die onafhankelijkheid kan in
een afnemend systeem een service eenvoudig vervangen worden door een nieuwe
versie van dezelfde service of door een andere service. Daarnaast kan de service
implementatie of achterliggend systeem gewijzigd worden zonder het koppelvlak te
wijzigen. Dit geeft flexibiliteit bij het inrichten en aanpassen van systemen.
Een afnemend systeem ‘roept’ een service aan door een bericht naar een service te
sturen, waarna de service de gevraagde actie uitvoert en het resultaat via één of
meerdere berichten ‘teruggeeft’. De service kan, zo nodig, via services weer gebruik
maken van functionaliteit van andere systemen, en zelfs van functionaliteit van
systemen van andere organisaties.
Een SGA zorgt voor ontkoppeling van proces en functionaliteit. Het proces dat
gevoelig is voor verandering, en de functionaliteit en data die minder gevoelig zijn
voor verandering. Hierdoor is het proces eenvoudig aan te passen zonder dat
aanpassing van functionaliteit nodig is. En het is eenvoudiger om dezelfde
functionaliteit te delen met anderen en via andere kanalen beschikbaar te stellen
zoals via mobiele toepassingen met een eigen interface (tablets en apps).
Binnen de Service Gerichte Architectuur is de enterprise service bus (ESB) een
belangrijk onderdeel. De informatie-uitwisseling - het ‘aanroepen’ - verloopt via een
ESB. Een ESB is een infrastructuur component en vormt de technische backbone van
een Service Gerichte Architectuur.
Eindgebruikers maken via een gebruikersinterface, ofwel interactie kanaal, gebruik
van een applicatie. De gebruikersinterface zorgt voor de interactie met de gebruiker.
Voor bedrijven en overheidsorganisaties die de ‘eigen’ applicaties niet direct willen of
kunnen koppelen met services, wordt een portaal aangeboden. Het portaal maakt
gebruik van dezelfde services als bedrijven en overheidsorganisaties die hun
systemen direct koppelen. Hierdoor is alle functionaliteit zowel via een webbrowser
als via ‘eigen’ applicaties toegankelijk. Op deze wijze wordt gegarandeerd dat het
resultaat hetzelfde is ongeacht of een actie wordt geïnitieerd vanuit het webportaal
of vanuit een afnemend systeem.
De toegang tot de webgebaseerde gebruikersinterface, het webportaal, loopt via
internet. Om communicatie tussen de webbrowser en het portaal af te schermen
wordt gebruik gemaakt van een beveiligde verbinding.
Pagina 6 van 38
Definitief | IMEA - Katern - Service Gerichte Architectuur | Versie 1.0
Figuur 1. Voorbeeld van een systeem bestaande uit een samenstel van services
In een SGA is het noodzakelijk om nieuwe systemen volledig servicegericht te
ontwerpen. Daarbij wordt zoveel mogelijk gebruik gemaakt van bestaande services
(hergebruik). De functionaliteiten van het systeem moeten zo ontwikkeld worden,
dat deze eenvoudig als services te ontsluiten zijn.
2.1.1
Architectuurkeuze Service Gerichte Architectuur
Bij het ontwikkelen van systemen worden Service Gerichte Architectuur principes
toegepast.
Motivering
Een systeem kan eenvoudig aangepast worden aan veranderende
behoeften.
SGA principes zorgen voor flexibiliteit en maakt het systeem beter
onderhoudbaar, aanpasbaar en herbruikbaar.
De modulaire servicegerichte opzet (componenten) biedt de mogelijkheid
om de ontwikkeling op te delen in overzichtelijke releases.
Componenten kunnen onafhankelijk van elkaar (door)ontwikkeld en in
productie genomen worden.
Wijzigingen kunnen eenvoudig, met minimale impact en tegen relatief lage
kosten doorgevoerd worden.
Het gebruik van Service Gerichte Architectuur wordt gestimuleerd vanuit
NORA.
2.2
Servicecontract
Een belangrijk aspect van een service is dat de afspraken die de afnemer en
aanbieder maken, worden vastgelegd in een overeenkomst, een contract. Het
contract is in begrijpelijke taal en beschrijft de service in termen van: wat de service
doet, input, output, mogelijke foutmeldingen, semantiek van uitgewisselde
informatie, service level agreement (SLA) en quality of service (QoS). Een contract
kan elementen bevatten die specifiek zijn voor een bepaalde afnemer. Er staan ook
niet functionele eisen in zoals maximale responsetijd, beschikbaarheid,
betrouwbaarheid, hoe de service omgaat met transacties en de intensiteit waarmee
Pagina 7 van 38
Definitief | IMEA - Katern - Service Gerichte Architectuur | Versie 1.0
de service bevraagd mag worden. Vanuit het perspectief van een service afnemer
beschrijft een contract alles wat de afnemer moet weten om de service te kunnen
gebruiken.
2.3
Performance
Services zijn geschikt voor real time verwerking. Dit stelt hoge eisen aan de
beschikbaarheid, verwerkingstijd, doorlooptijd en responsetijd van services. Bij het
meten van de performance van services zijn drie aspecten van belang: de
verwerkingstijd, de doorlooptijd en de responsetijd. Deze zijn in de volgende figuur
weergegeven.
Figuur 2. Verwerkingstijd, doorlooptijd en responsetijd
Definities
Verwerkingstijd: de tijd die een koppeling op de ESB intern nodig heeft om
een vraagbericht te verwerken. Hierbij worden de verwerkingstijden van
vraag- en antwoordbericht bij elkaar opgeteld.
Doorlooptijd: de tijd die een koppeling nodig heeft om een vraagbericht te
verwerken en het antwoordbericht samen te stellen. Hierin zit dus ook de
tijd die de service aanbieder nodig heeft om te antwoorden.
Responsetijd: de tijd vanaf het moment dat een service afnemer (client) een
koppeling op de ESB aanroept tot het moment dat het antwoordbericht door
de service afnemer ontvangen wordt. Hierin zit ook de tijd die de ESB en de
aanbieder nodig hebben om te antwoorden en de netwerk latency
(netwerkvertraging).
Het is belangrijk om de tijd voor eindgebruikers zo kort mogelijk te houden. Vanuit
oogpunt van usability wordt een responsetijd van 6-8 seconden acceptabel geacht.
Het gaat hierbij om de tijd die de eindgebruiker ervaart achter het scherm. Dit
betekent dat de tijd die een services aanbiedend systeem heeft om een synchrone
vraagbericht te verwerken, rekening houdend met latency (vertraging door
tussenliggende schakels en netwerk), maximaal 1 seconde mag zijn. Heeft een
service meer verwerkingstijd nodig dan dient er gebruik gemaakt te worden van
asynchrone communicatie.
Voor het in productie nemen van services dienen deze altijd een performancetest te
ondergaan om zeker te stellen dat er voldaan wordt aan de gestelde prestatie-eisen.
Hierbij dient rekening gehouden te worden met effecten van het verwachte aantal
gelijktijdige acties, aanroepen van gecombineerde services, etc.
Pagina 8 van 38
Definitief | IMEA - Katern - Service Gerichte Architectuur | Versie 1.0
2.4
Onderscheid externe en interne informatie-uitwisseling
Bij de informatie-uitwisseling wordt onderscheid gemaakt tussen uitwisselen met
interne en externe systemen.
2.4.1
Externe informatie-uitwisseling
Voor externe informatie-uitwisseling wordt gebruik gemaakt van overheidsbrede
bouwstenen en standaarden zoals Digikoppeling, Diginetwerk, PKIoverheid
certificaten, StUF, etc.
Figuur 3. Koppelvlak met externe systemen
Definities
Een informatiemodel beschrijft de objecttypen en hun definities en
eigenschappen binnen een bepaald domein. Dit vereenvoudigt de
uitwisseling van informatie.
Een berichtmodel beschrijft de berichten waarmee gegevens van het
informatiemodel worden uitgewisseld.
Een berichtdefinitie beschrijft de daadwerkelijke inhoud van de berichten die
uitgewisseld worden.
2.4.2
Interne informatie uitwisseling
Interne systemen worden afgeschermd van de complexiteit van externe informatieuitwisseling. Bij interne informatie-uitwisseling zijn overheidsbrede standaarden niet
van toepassing en wordt informatie uitgewisseld op basis van ‘lichtgewicht’ services
en IenM specifieke standaarden.
Pagina 9 van 38
Definitief | IMEA - Katern - Service Gerichte Architectuur | Versie 1.0
Figuur 4. Interne en externe systemen ontkoppelen door gebruik te maken van intern en extern koppelvlak
2.4.3
Architectuurkeuze onderscheid interne en externe informatie-uitwisseling
Er is gekozen voor een onderscheid tussen interne en externe informatieuitwisseling waardoor interne systemen worden afgeschermd van de complexiteit
van externe informatie-uitwisseling.
Motivering
De interne informatie-uitwisseling wordt eenvoudiger.
De overhead van de interne informatie-uitwisseling wordt beperkt
(lichtgewicht).
Voor de interne informatie-uitwisseling kan een eigen modellering worden
gehanteerd met eigen informatiemodellen en bijbehorende
berichtenmodellen (intern koppelvlak versus extern koppelvlak).
Interne systemen worden afgeschermd van wijzigingen in de externe
informatie-uitwisseling.
2.5
Stelsel van ESB’s met het Centraal Aansluitpunt
IenM maakt gebruik van verschillende infrastructuren voor het hosten van
systemen. Elke infrastructuur beschikt over een eigen ESB. Samen vormen deze
ESB’s een stelsel dat de interne informatie-uitwisseling verzorgt met behulp van
lichtgewicht berichten.
Interne systemen en ESB’s worden afgeschermd van de complexiteit van het
koppelen met externe services door middel van het Centraal Aansluitpunt. Het
Centraal Aansluitpunt faciliteert de informatie-uitwisseling met externe services. Het
betreft zowel informatie-uitwisseling van binnen naar buiten als van buiten naar
binnen.
In de volgende figuur is de basisopzet van het stelsel van ESB’s met het Centraal
Aansluitpunt weergegeven.
Pagina 10 van 38
Definitief | IMEA - Katern - Service Gerichte Architectuur | Versie 1.0
Figuur 5. Stelsel van ESB’s met het Centraal Aansluitpunt
2.6
Centraal Aansluitpunt
Vanuit het Centraal Aansluitpunt wordt de koppeling met een externe service
eenmalig geconfigureerd, bijvoorbeeld met een basisregistratie. Interne systemen
koppelen via het stelsel van ESB’s met het Centraal Aansluitpunt. De services
waarmee interne systemen basisregistraties bevragen stellen afnemers in staat om
een eenvoudige vraag te stellen, bijvoorbeeld “Geef mij de gegevens behorende bij
postcode huisnummer”. Dit vraagbericht gaat via het stelsel naar het Centraal
Aansluitpunt. Het Centraal Aansluitpunt vertaalt dit intern vraagbericht naar een
extern vraagbericht. Het ontvangen extern antwoordbericht wordt door het Centraal
Aansluitpunt vertaald naar een eenvoudig intern antwoordbericht. Intern wordt
gebruik gemaakt van een eigen informatiemodel met bijbehorend berichtenmodel.
Vertaling gebeurt door het Centraal Aansluitpunt. Hiermee worden de IenM
systemen en de externe systemen ontkoppeld en worden wijzigingen in externe
koppelvlakken zoveel mogelijk opgevangen in het Centraal Aansluitpunt.
Het Centraal Aansluitpunt beschikt over verschillende adapters. Deze adapters
ondersteunen de Digikoppeling protocollen ebMS en WUS, aangevuld met de
Digikoppeling Grote Berichten. Indien nodig vertaalt een andere adapter de interne
berichten naar het StUF protocol en vice versa. Externe koppelingen die gebruik
maken van Digikoppeling of StUF lopen altijd via het Centraal Aansluitpunt.
Pagina 11 van 38
Definitief | IMEA - Katern - Service Gerichte Architectuur | Versie 1.0
Figuur 6. Centraal Aansluitpunt
Het Centraal Aansluitpunt biedt daarnaast nog aanvullende functionaliteit zoals het
bijhouden van audit informatie1, archiveren van berichten, monitoren (gebruiksstatistieken) en het centraal opslaan en ontsluiten van een kopie van basisregistratie
informatie. Deze centrale kopie wordt gebruikt indien een basisregistratie niet
beschikbaar is of als de reactietijd bij het bevragen langer is dan in de SLA
afgesproken. Het Centraal Aansluitpunt is ingericht op basis van een zogenoemde
ESB.
2.6.1
Architectuurkeuze stelsel van ESB’s met een Centraal Aansluitpunt
De ESB’s in de IenM infrastructuren vormen samen een stelsel van ESB’s dat de
interne informatie-uitwisseling verzorgt. Door het Centraal Aansluitpunt wordt het
stelsel afgeschermd van de complexiteit van het koppelen met externe services.
Motivering
Communicatie tussen interne en externe systemen wordt gecentraliseerd en
gefaciliteerd door het Centraal Aansluitpunt.
Het ontsluiten van basisregistraties wordt doeltreffender en goedkoper,
omdat een externe koppeling slechts eenmaal gelegd hoeft te worden.
In het Centraal Aansluitpunt worden kennis en expertise gebundeld over
basisregistraties, Digikoppeling, StUF, Diginetwerk, Digipoort, informatie- en
berichtmodellen, etc.
De inspanning om individuele systemen te koppelen worden lager, omdat de
leveranciers van deze systemen niet hoeven te beschikken over deze
specifieke kennis en expertise.
1
Welk systeem en of persoon bevraagt een service.
Pagina 12 van 38
Definitief | IMEA - Katern - Service Gerichte Architectuur | Versie 1.0
Figuur 7. Interne systemen ontkoppelen van de complexiteit van het koppelen met externe services
2.7
Domein specifieke koppelingen
Als het centraal leggen van een koppeling niet bijdraagt aan de doelstellingen:
bundelen expertise, verhogen beheerbaarheid en flexibiliteit en beperken van
afhankelijkheden van wijzigingen in (externe) koppelvlakken, dan wordt deze
koppeling niet vanuit het Centraal Aansluitpunt gelegd, maar vanuit een ESB in het
specifieke domein. Het leggen van koppeling vanuit een specifiek domein kan ook
gewenst zijn vanwege het beperken van afhankelijkheden tussen domeinen, het
lokaal houden van communicatie (latency beperken), of als daarvoor specifieke
domeinkennis vereist is.
Ten overvloede: Communicatie met externe systemen loopt altijd via het Centraal
Aansluitpunt.
2.8
Beveiliging
De beveiliging richt zich primair op de gegevensuitwisseling tussen organisaties en is
gebaseerd op het concept van vertrouwde domeinen. Het concept van de
vertrouwde domeinen gaat er van uit dat binnen een vertrouwd domein de
beveiligingsmaatregelen aan de informatiebeveiligingseisen voldoen, waardoor
service afnemers en service aanbieders elkaar kunnen vertrouwen. Voor de
gegevensuitwisseling binnen haar vertrouwde domein kan iedere organisatie zelf
bepalen welke beveiligingsmaatregelen zij neemt.
Autorisatie en beveiligingsmaatregelen bepalen welke services beschikbaar zijn voor
een services afnemend systeem. Per service wordt bepaald of deze naar buiten toe
beschikbaar is en welke beveiligingsmaatregelen nodig zijn.
Dat een services afnemend systeem geautoriseerd is voor een service, betekent nog
niet dat het afnemende systeem geautoriseerd is voor alle data van die service. Een
service moet garanderen dat een afnemend systeem alleen toegang heeft tot data
Pagina 13 van 38
Definitief | IMEA - Katern - Service Gerichte Architectuur | Versie 1.0
waartoe dit services afnemende systeem geautoriseerd is, dit wordt ook wel filteren
genoemd. Filteren kan afhankelijk van de service op basis van organisatie, rol en
gebruiker gebeuren.
Bij elke serviceaanroep moet het mogelijk zijn om de unieke organisatie-, rol- of
gebruiker ID af te leiden. De service roept een autorisatieservice aan met één of
meerdere van deze ID’s. De autorisatieservice bepaalt of het afnemende systeem
geautoriseerd is om de service te gebruiken. Indien het services afnemende systeem
geautoriseerd is, worden de gegevens gefilterd op basis van organisatie-, rol- en
gebruiker ID.
2.9
Versies
In een servicegerichte architectuur is het van belang goed om te gaan met nieuwe
versies van services. Het is immers ongewenst om van service afnemers een
gedwongen of gelijktijdige migratie te eisen, bij het beschikbaar komen van een
nieuwe versie van de service. Het moet mogelijk zijn om nieuwe versies van
services geleidelijk in te voeren. Daarvoor is het nodig om gelijktijdig meerdere
versies van een service koppelvlak aan te bieden. Services afnemers moeten
expliciet kunnen kiezen wanneer ze overgaan op een nieuwe versie. Verschillende
versies van een service zijn herkenbaar aan het versienummer in de naamgeving
van de URI. Vanaf het moment dat een nieuwe versie van een service in productie
is, wordt de oude versie van de service in principe maximaal een jaar ondersteund.
De afnemers van de ‘oude’ service hebben dan voldoende tijd om hun systemen aan
te passen en geschikt te maken voor de nieuwe versie.
2.9.1
Architectuurkeuze ondersteuning versies
Vanaf het moment dat een nieuwe versie van een service in productie is, wordt de
oude versie van de service nog maximaal een jaar lang ondersteund.
Motivering
Services krijgen een nieuwe versienummer in de naamgeving (URI) als het
koppelvlak wijzigt.
De afnemers van de ‘oude’ service hebben dan voldoende tijd om hun
systemen aan te passen en geschikt te maken voor de nieuwe versie.
De beheerlasten aan de kant van de aanbieder worden beperkt.
Pagina 14 van 38
Definitief | IMEA - Katern - Service Gerichte Architectuur | Versie 1.0
3
Service gerichte architectuur: verdieping
3.1
Servicelagenmodel
Eén van de belangrijkste voordelen van een servicegerichte architectuur is de
mogelijkheid om efficiënt met veranderingen om te gaan. De meest fundamentele
eenheid van een SGA is de dienst (service). Een service gerichte architectuur (SGA)
is gebaseerd op een verzameling van diensten. De "stabiele" diensten zijn
gescheiden van "veranderlijke" bedrijfsprocessen. Deze diensten worden
georkestreerd tot IT-oplossingen. Daardoor kunnen veranderingen van business
eisen vaak worden ingevuld door het wijzigen van een bestaand proces of het
creëren van een nieuw proces op basis van de bestaande diensten. Deze aanpak
zorgt er voor dat veranderingen eenvoudiger (sneller en goedkoper) doorgevoerd
kunnen worden door het (opnieuw) samenstellen van oplossingen op basis van de
herbruikbare diensten. Diensten worden middelen, die gedeeld worden door
verschillende business oplossingen. Hierdoor wordt het mogelijk om business
oplossingen en diensten door verschillende teams parallel en autonoom te
ontwikkelen, elk met een eigen release- en beheercyclus.
De SGA van IenM is gebaseerd op een servicelagenmodel. Dit model biedt een
manier om services te categoriseren met gemeenschappelijke kenmerken.
Verschillende servicelagen zorgen voor ontkoppeling, onderhoudbaarheid,
wendbaarheid, flexibiliteit en hergebruik. Het servicelagenmodel kent drie lagen:
Processervices
Business services
Technische services
Onderstaande plaat is een voorbeeld van een concrete invulling van het
servicelagenmodel.
Figuur 8. Voorbeeld van het servicelagenmodel
Pagina 15 van 38
Definitief | IMEA - Katern - Service Gerichte Architectuur | Versie 1.0
De proces servicelaag is specifiek en maximaal aangesloten bij het bedrijfsproces
dat ondersteund wordt. De business servicelaag is generiek en maximaal
herbruikbaar. De technische services zijn applicatie specifiek en meestal erg
technisch van aard. De business laag zorgt er voor dat de technische en product
specifieke details van een systeem verborgen blijven, zodat afnemers deze services
kunnen gebruiken zonder kennis te hebben van het onderliggend systeem.
Figuur 9. De servicelagen zorgen voor maximale hergebruik op de business laag
Het is belangrijk om op te merken dat er naast services die business logica bevatten
er ook services zijn die niet-business logica bevatten. Het laatste type zijn services
die ook wel aangeduid worden als infrastructuur services deze groeperen
functionaliteit volgens een verwerkingscontext in plaats van een business context.
Voorbeelden hiervan zijn een beveiliging service (bijvoorbeeld authenticatie) en een
logging service.
Abstractie, een van de meest fundamentele SGA principes, steunt volledig op de
inzet van proces- en business services om bedrijfsproces en -functionaliteit, ofwel
business logica, in eigen domeinen te scheiden en isoleren. Dit zorgt voor een aantal
van de strategische voordelen van SGA zoals ontkoppeling, onderhoudbaarheid,
wendbaarheid, flexibiliteit en hergebruik.
Servicegerichtheid is een manier om geautomatiseerde business logica zo te
structureren dat dit zorgt voor een aanzienlijk verbetering van de flexibiliteit en
wendbaarheid om in te spelen op veranderingen. Dit wordt bereikt door gebruik te
maken van goed gedefinieerde business services die functionaliteit groeperen binnen
specifieke business contexten. Met deze opzet kan efficiënt gereageerd worden op
veranderingen in business eisen en business processen door het opnieuw
samenstellen van diensten.
Samenvattend: dit gewenste niveau van organisatorische flexibiliteit vereist het
creëren van een servicelagenmodel. Deze servicelagen zorgen voor een
afgebakende verzameling business services die gecoördineerd kunnen worden, het
introduceert het concept van servicelaag abstractie en zorgt voor ontkoppeling en
alignment tussen de business- en automatiseringsdomeinen van een onderneming.
In de volgende paragrafen worden de verschillende lagen van het servicelagenmodel
nader toegelicht.
Pagina 16 van 38
Definitief | IMEA - Katern - Service Gerichte Architectuur | Versie 1.0
3.1.1
Interactiekanalen
Een interactiekanaal ofwel front-end is een manier waarmee eindgebruikers
interactie hebben met services. Voorbeelden van interactiekanalen zijn een desktop
applicatie, een mobiele applicatie en een webapplicatie. Interactiekanalen bestaan
uit interne en externe applicaties die services afnemen. Voor organisaties die de
‘eigen’ applicaties niet direct willen of kunnen koppelen met services wordt door
IenM een interactiekanaal aangeboden. Dat IenM interactiekanaal maakt gebruik
van dezelfde services als organisaties die hun applicaties direct koppelen. Hierdoor
wordt gegarandeerd dat het resultaat over interne en externe interactiekanalen
heen hetzelfde is ongeacht of een actie wordt geïnitieerd vanuit het IenM interactiekanaal of vanuit een applicatie.
3.1.2
Processervices
Processervices zijn implementaties van bedrijfsproces logica die een aantal
opeenvolgende stappen uitvoert om een specifieke taak te realiseren. In essentie
zijn processervices verantwoordelijk voor het coördineren van de verschillende
business services. Deze processervice laag is specifiek en maximaal aangesloten bij
het bedrijfsproces dat ondersteund wordt. Deze laag kent geen of zeer beperkte
technische details.
Het combineren van verschillende services tot een nieuwe service wordt in
servicegerichte termen orkestreren genoemd.
Een processervice bestaat uit een aantal stappen met een bepaalde samenhang.
Processervices zorgen voor het onafhankelijk van elkaar maken (ontkoppelen) van
het bedrijfsproces en functionaliteit. Het bedrijfsproces dat gevoelig is voor
verandering en de functionaliteit die minder gevoelig is voor verandering. Hierdoor is
het eenvoudiger, beheersbaarder en goedkoper om een (bedrijfs)proces aan te
passen zonder onderliggende systemen of componenten aan te passen.
Een van de voordelen die het hanteren van processervices biedt is efficiënt
onderhoud. Wanneer bedrijfsproces logica diepgeworteld onderdeel is van systemen
vereisen wijzigingen in deze logica vaak grote herontwikkeling. Door een scheiding
of laag voor deze procesdetails te hanteren is het eenvoudiger om deze te
onderhouden en wijzigen zonder het onderliggende systeem te wijzigen omdat
functionaliteit niet rechtstreeks aan het proces gekoppeld is.
3.1.3
Business services
Business services zijn implementaties van functies die gerelateerd zijn aan entiteiten
die betekenisvol zijn voor de business (business context) en agnostisch
(onafhankelijk) zijn ten aanzien van het bedrijfsproces en onderliggend systeem.
Deze functies zullen altijd blijven bestaan, ongeacht hoe vaak de bedrijfsprocessen
of de onderliggende systemen veranderen. Deze services omvatten in veel gevallen
meerdere technische services. Vanwege behoud van overzicht is een logische
scheiding noodzakelijk en zijn business services domein specifiek. Deze servicelaag
is generiek en direct of via de processervices maximaal herbruikbaar. Deze laag kent
geen of zeer beperkte technische details.
Een business service zorgt er voor dat de technische, platform specifieke en
implementatie details van een systeem verborgen blijven, zodat afnemers deze
services kunnen gebruiken zonder kennis te hebben van de onderliggende
systemen. Er worden goed gedefinieerde en technologie en leverancier neutrale
interfaces aangeboden om hiermee de backend systemen toegankelijk te maken
voor afnemers.
Pagina 17 van 38
Definitief | IMEA - Katern - Service Gerichte Architectuur | Versie 1.0
Afnemers kunnen te maken hebben met meerdere business services. Waar mogelijk
moeten afnemers informatie gelijktijdig kunnen opvragen en wijzigen in
verschillende business services. Dit wordt gerealiseerd middels samengestelde
services.
Samengestelde services maken gebruik van meerdere technische services of
business services om een gecombineerde service aan te bieden. Een gecombineerde
service verbergt complexiteit voor de afnemer. Deze zorgt er voor dat gebruikte
services in de juiste volgorde worden aangeroepen en combineert het resultaat of
geeft een subset van het resultaat terug.
Bij samengestelde services is aanvullende ondersteuning voor transacties
noodzakelijk. IenM kiest voor het compensatiemechanisme om koppeling tussen
services te voorkomen. Dit houdt in dat een service een uitgevoerde wijziging
zelfstandig moet kunnen terugdraaien of dat er een mogelijkheid is om dit
handmatig te doen.
Door functionaliteit te baseren op business services vormt de processervicelaag een
bovenliggend besturingslaag die de business services aanstuurt. Wanneer er
wijzigingen aan een bedrijfsproces nodig zijn, wordt de processervicelaag beïnvloed,
maar de business services worden zoveel mogelijk afgeschermd voor deze
wijzigingen. Het proces moet mogelijk opnieuw worden samengesteld, uitgebreid
worden of zelfs gecreëerd, maar het belangrijkste voordeel hier is dat er meestal
geen fundamentele herontwikkeling nodig is en de scope van de wijziging beperkt is.
Hierdoor neemt de algehele impact van de veranderingen af. Door deze opzet zijn
business services maximaal herbruikbaar als bouwstenen.
3.1.4
Technische services
Technische services zijn basisservices. Vaak zijn technische services applicatie
specifiek en meestal erg technisch van aard. Het gebruik van deze technische
services vereist kennis van het achterliggend systeem. Dit zijn meestal webservices
die onderdeel zijn van een applicatie en daarmee niet leverancier- of productneutraal zijn. Het koppelvlak is leverancier- of product specifiek. Deze services
worden nooit direct door afnemers aangeroepen maar altijd via een processervice of
business service. Hierdoor is het mogelijk om een onderliggend systeem en/of
bijbehorende technische services te vervangen met geen of minimale impact voor de
afnemers.
Technische services zijn services die informatie ophalen uit- of wegschrijven naar
één systeem. Deze services representeren fundamentele en afgebakende operaties
in een systeem. Schrijfservices zorgen er voor dat gegevens toegevoegd of
bijgewerkt worden zonder dat er inconsistenties ontstaan in het achterliggend
systeem.
3.1.5
Backend
Een backend bevat één of meerdere componenten (systemen), in de meeste
gevallen is het een combinatie van meerdere componenten. Voorbeelden van
backend componenten zijn database, applicatieserver, content management
systeem (CMS) en document management systeem (DMS).
Pagina 18 van 38
Definitief | IMEA - Katern - Service Gerichte Architectuur | Versie 1.0
3.2
Service principes
Figuur 10. Services worden op verschillende manieren logisch gegroepeerd
Een dienst is een prestatie die het resultaat is van een aantal uitgevoerde
activiteiten, taken en handelingen, waarbij er een vergoeding verschuldigd is
voor de geleverde prestatie (niet voor de geleverde inspanning).
Een dienst wordt geleverd door een dienstverlener (service aanbieder).
Servicelagen bieden een manier om services te categoriseren om het proces te
ontkoppelen van de onderliggende techniek.
Business services zijn business domein specifiek. Business services worden in
business domeinen c.q. functionele groepen ingedeeld. Een functionele groep
categoriseert services die een logische eenheid vormen.
Business services hebben alleen kennis van het eigen business domein en niet
van andere business domeinen.
3.3
Communicatieprincipes
Elke servicelaag kent alleen de onderliggende servicelagen. Het aanroepen van
een service loopt altijd van bovenliggende laag naar onderliggende laag, maar
niet andersom.
Business services die over functionele groepen heen communiceren, doen dit via
processervices.
Elke laag en afnemer mag de proces laag gebruiken.
Processervices orkestreren en aggregeren de business services.
Business services orkestreren en aggregeren de technische services.
Technische services zijn vaak verweven met de applicatie die zij ontsluiten. Het
gebruik vraagt om kennis van deze applicaties.
Om wendbaar en flexibel te blijven en te zorgen dat applicaties vervangbaar zijn
mogen applicaties (afnemers) technische services nooit direct aanroepen, deze
worden altijd via een processervice of business service aangeroepen.
Het ontwikkelen van een business service die nodig is om een technische service
neutraal te ontsluiten is de verantwoordelijkheid van de eigenaar van het
systeem waar de technische service toebehoort.
Elke afnemer van een service is zelf verantwoordelijk voor de juistheid,
volledigheid en tijdigheid van de gegevens die nodig zijn voor een service
aanroep. Dit betekent bijvoorbeeld dat de afnemer een pre-controle uitvoert of
Pagina 19 van 38
Definitief | IMEA - Katern - Service Gerichte Architectuur | Versie 1.0
alle verplichte informatie ingevuld, geldig en compleet is, voordat deze wordt
aangeboden aan een service. Services en backend controleren op hun beurt of
de informatie geldig is voordat deze verwerkt wordt.
De pre-controle voorkomt pingpongen tussen afnemer en de verschillende
services en draagt bij aan een betere gebruikerservaring.
Een pre-controle hoeft niet perfect te zijn, het doel is zorgen dat processen in de
meeste gevallen goed gaan. Daarbij gaat het om een goede balans en niet om
een perfecte pre-controle.
3.4
Ontwerpprincipes
Een SGA kent dezelfde wetmatigheden als gedistribueerde systemen en
systeemintegratie. Het goed opzetten van dit soort systemen is lastig omdat er
afhankelijkheden worden gecreëerd tussen systemen. Er ontstaat een keten van
afhankelijke activiteiten. Een schakel in deze keten kan en zal falen. Bij het
ontwerp dient hier rekening mee gehouden te worden.
Bij het ontwerpen en implementeren van afnemende systemen moet rekening
gehouden worden dat aanroepen langer kunnen duren dan verwacht, dat
aanroepen zullen falen en dat een aanbiedend systeem niet beschikbaar zal zijn.
Een services wordt opgesplitst in kleinere services wanneer veel controle, regie
en sturing nodig is.
De namen van services en bijbehorende packages, URI’s, WSDL’s, XSD’s, etc.
bevatten geen verwijzingen naar een leverancier, product, implementatie en
technologie.
De namen van services bevatten een aanduiding van de te leveren diensten.
Voorbeelden: VerwerkenKlantmutaties, AfhandelenPrintopdrachten,
ControlerenFacturen, AfwijzenAanvraag, SamenstellenKlantbeeld.
Een service is onafhankelijk van de onderliggende technologie.
Dynamische processen zijn ontkoppelt van stabiele functionaliteit.
Services zijn autonoom en bevorderen hergebruik doordat ze een hoge
samenhang kennen en onafhankelijk zijn van elkaar (lage koppeling):
individuele services hebben een duidelijke verantwoordelijkheid binnen het
geheel en kennen een lage koppeling.
Samenhang betreft de functionele samenhang (cohesie) en het beheersbaar
houden van complexiteit. De taken van een service moeten draaien om één
onderwerp. Een service met lage samenhang doet dingen die weinig met elkaar
te maken hebben. Services met lage samenhang verrichten te veel taken en
delegeren deze niet. Een lage of slechte samenhang kan het noodzakelijk maken
een service te splitsen. Het gaat hierbij om business services en technische
services. Processervices mogen wel complex zijn, indien gewenst kunnen ook
deze opgesplitst worden.
Koppeling betreft de mate waarin een service verbonden is met, kennis nodig
heeft van, of afhankelijk is van andere services. Services dienen zo
onafhankelijk mogelijk te zijn, om te voorkomen dat wijzigingen in een service
leidt tot veranderingen in andere services.
Een service heeft een contract en een implementatie. Het contract beschrijft de
gestandaardiseerde berichten (koppelvlak) die toegang geven tot de service. Het
contract schermt daarmee de implementatiedetails af van de aanbieder.
Afnemers van een service hebben geen kennis (nodig) van de implementatie,
waardoor het mogelijk is om de implementatie aan te passen zonder dat dit
impact heeft op afnemers.
Een backend kan bestaan uit verschillende samenhangende systemen. De keuze
voor een SGA betekent niet dat een backend intern per definitie gebruik maakt
Pagina 20 van 38
Definitief | IMEA - Katern - Service Gerichte Architectuur | Versie 1.0
van services. Om redenen van performance en beperken van complexiteit kan
het wenselijk zijn om tussen deze systemen onderling direct te koppelen. Dit is
toegestaan zolang de gebruikte functionaliteit van de backend niet extern als
service wordt aangeboden aan afnemers.
Voor generieke zaken zoals identificatie, authenticatie, autorisatie,
onweerlegbaarheid, encryptie en procesbesturing, worden generieke
voorzieningen en services gebruikt.
De communicatie tussen afnemers en aanbieders is ontkoppeld en verloopt via
de ESB. Afnemers en aanbieders koppelen nooit rechtstreeks (point-to-point).
De berichten zijn herleidbaar in de keten. Een bericht wordt voorzien van een
correlatie ID. Dit ID wordt door elk component gelogd, hierdoor is het eenvoudig
om een transactie in de keten te volgen en om fouten te achterhalen en
herstellen.
3.5
Proces en compositie
3.5.1
Orkestratie
Het opeenvolgend uitvoeren een aantal geautomatiseerde processtappen met een
bepaalde volgorde en samenhang wordt ondersteund door middel van Business
Process Execution Language (BPEL). BPEL is een gestandaardiseerde oplossing die
de interactie tussen verschillende services orkestreert op basis van configuratie en
de mogelijkheid biedt om complexe (langlopende) processen te beschrijven, inclusief
foutafhandeling en compensatie handelingen. Handmatige processtappen worden
ondersteund door middel van een taken service of BPEL extensie BPEL4People.
3.5.2
Taken service
Het BPEL proces biedt de mogelijkheid om handmatige activiteiten op te nemen in
een taken service. Een taken service zet de benodigde handmatige activiteiten in
een takenlijst. Deze takenlijst is gekoppeld aan een gebruiker of een rol. Het
systeem communiceert met de taken service om de takenlijst voor de gebruiker of
rol op te halen. De gebruiker of gebruikers met die rol kunnen de taken in de lijst
zien en uitvoeren. Als de taak is uitgevoerd koppelt de taken service het resultaat
terug naar het BPEL proces en gaat de proces service verder.
3.5.3
BPEL4People
BPEL4People is een gestandaardiseerde extensie die BPEL uitbreidt met de
mogelijkheid om rol gebaseerde handmatige activiteiten op te nemen als onderdeel
van een proces. Een proces service kan de benodigde handmatige taak in een
takenlijst zetten. Deze takenlijst is gekoppeld aan een gebruiker of een rol. De
gebruiker of gebruikers met die rol kunnen de taken in de lijst zien en uitvoeren. Als
de taak is uitgevoerd gaat de proces service verder.
IenM heeft de voorkeur om gebruik te maken van BPEL4People om handmatige
processtappen te integreren met BPEL.
Pagina 21 van 38
Definitief | IMEA - Katern - Service Gerichte Architectuur | Versie 1.0
4
Informatie-uitwisseling
4.1
Inleiding
Systemen wisselen steeds vaker geautomatiseerd informatie uit met andere
systemen, bijvoorbeeld met de basisregistraties. Een dergelijke informatieuitwisseling vindt plaats binnen de context van een proces. Een proces bestaat
vrijwel altijd uit deelprocessen en interactieprocessen tussen deze deelprocessen.
Het interactieproces tussen twee systemen wordt het koppelvlak genoemd. In de
volgende figuur is een proces weergegeven met deel- en interactieprocessen,
koppelvlakken en ondersteunende systemen.
Figuur 11 Een proces met deel- en interactieprocessen, koppelvlakken en ondersteunende systemen
Om informatie via een koppelvlak geautomatiseerd uit te kunnen wisselen zijn er
meerdere afspraken nodig. Om inzichtelijk te maken welke afspraken dat zijn, wordt
gebruik gemaakt van twee modellen: het informatie-uitwisseling lagenmodel en het
elektronisch berichtmodel.
4.2
Informatie-uitwisseling lagenmodel
Het informatie-uitwisseling lagenmodel kent vijf lagen, te weten bedrijfsproces,
gegevens, applicatie, communicatiefunctie en communicatievoorziening. In het
model ondersteunt elke laag de bovenliggende laag.
Pagina 22 van 38
Definitief | IMEA - Katern - Service Gerichte Architectuur | Versie 1.0
Figuur 12 Het informatie-uitwisseling lagenmodel
Per laag worden afspraken gemaakt over de acties, reacties en interpretaties, in het
model is dit weergegeven met horizontale pijlen per laag (stippellijnen). De aard van
de afspraken is weergegeven bovenop deze horizontale pijlen, de afspraken gaan
over de uit te wisselen bedrijfsinformatie, gegevenselementen, bedrijfsdocumenten,
bijlagen2 en berichten.
Zie Bijlage A voor een uitgebreidere versie van het informatie-uitwisselingsmodel.
Daarin zijn de verschillende niveaus van interoperabiliteit benoemd, de afspraken
die per niveau van toepassing zijn en voorbeelden opgenomen.
Door afspraken op elk van de vijf lagen te maken, wordt eenvoud van aansluiten,
transparantie en interoperabiliteit bereikt:
Datacommunicatievoorziening
De datacommunicatievoorziening (het netwerk) zorgt voor het daadwerkelijke
transport van de informatie van de ene locatie naar de andere. Op deze laag worden
afspraken gemaakt over het transportprotocol (TCP) en het netwerkprotocol (IP).
Communicatiefunctie
De communicatiefunctie is te beschouwen als een elektronische postkamer die zorgt
voor verzenden en ontvangen van elektronische berichten. Op deze laag worden
afspraken gemaakt over het communicatieprotocol (HTTP, HTTPS, SMTP, JMS enz.).
2. Een bijlage bij een bedrijfsdocument bevat informatie die ongestructureerd is of waarvan de structuur niet
primair relevant is voor de bedrijfstransactie.
Pagina 23 van 38
Definitief | IMEA - Katern - Service Gerichte Architectuur | Versie 1.0
Applicatie
De applicaties van de betrokken organisaties zijn dankzij de infrastructuur in staat
om bedrijfsdocumenten en bijlagen uit te wisselen. Op deze laag worden afspraken
gemaakt over de bedrijfsdocumenten en bijlagen die worden uitgewisseld.
Gegevens
De informatie in de bedrijfsdocumenten wordt gestructureerd en gegroepeerd met
behulp van gegevenselementen. Op deze laag worden afspraken gemaakt over de
betekenis en eigenschappen van gegevens, deze worden in gegevensmodellen en definities vastgelegd.
Bedrijfsproces
De uitgewisselde informatie zorgt er voor dat op het niveau van bedrijfsproces het
gewenste interactieproces plaatsvindt.
4.3
Elektronisch berichtmodel
In het elektronisch berichtmodel gaat het over de opbouw van een elektronisch
bericht. Voor het bericht wordt gebruik gemaakt van Simple Object Access Protocol
(SOAP). SOAP is een protocol dat de envelop en de regels beschrijft hoe een
ontvanger om moet gaan met het bericht dat in de envelop zit. SOAP maakt het
mogelijk om via services informatie uit te wisselen. De exacte vulling van SOAP
berichten verschilt per service.
Figuur 13 Voorbeeld van de opbouw van een elektronisch bericht
Pagina 24 van 38
Definitief | IMEA - Katern - Service Gerichte Architectuur | Versie 1.0
Een bericht bestaat, naast de protocolheader, uit vier onderdelen, te weten
berichtheader, bedrijfsdocument, berichtinhoud en bijlagen.
Protocolheader
De protocol header bevat transportprotocolinformatie, deze is uitsluitend van belang
voor de samenwerking tussen twee communicatiefuncties (de ‘postkamers’).
Bij een tweezijdige SSL verbinding wordt het SN (subject) veld uit het PKIoverheid
certificaat van de aanvrager gehaald en toegevoegd aan de protocolheader. Met
deze informatie uit het PKIoverheid certificaat zijn achterliggende koppelingen in
staat een bevraging eenduidig te autoriseren.
Berichtheader
De berichtheader bevat protocolinformatie voor ontvangst (WS-Addressing),
beveiliging (WS-Security), betrouwbaarheid (WS-ReliableMessaging) enz.
Bedrijfsdocument
Het bedrijfsdocument is een gestructureerde gegevensset bestaande uit
gegevenselementen. Het bedrijfsdocument bevat informatie voor het
(bedrijfs)proces.
Berichtinhoud
De berichtinhoud bevat de gestructureerde informatie die tussen twee
bedrijfsprocessen wordt uitgewisseld.
Bijlagen
De bijlagen bevatten in beginsel ongestructureerde bedrijfsinformatie, zoals
documenten, afbeeldingen of foto’s.
De samenhang tussen het informatie-uitwisseling lagenmodel en het elektronisch
berichtmodel komt tot uiting in de volgorde van het in- en uitpakken van de uit te
wisselen informatie. Wanneer op de bedrijfsproceslaag behoefte is aan informatie uit
een ander systeem, wordt dit verzoek ‘naar onderen toe’ per laag steeds verder
‘ingepakt’: het verzoek in gegevenselementen, de gegevenselementen in een
bedrijfsdocument, het document in een bericht, het bericht in een enveloppe. De
enveloppe gaat uiteindelijk naar het andere systeem. Na ontvangst door het andere
systeem wordt de enveloppe ‘naar boven toe’ per laag steeds verder ‘uitgepakt’:
bericht, bedrijfsdocument, gegevenselementen en tenslotte het verzoek.
Het antwoord op het verzoek volgt de omgekeerde weg. Het antwoord wordt door
het aanbiedende systeem weer laagsgewijs ingepakt en door het afnemende
systeem uitgepakt. Na verwerking van de gevraagde informatie kan het
bedrijfsproces weer verder met de volgende stap.
Pagina 25 van 38
Definitief | IMEA - Katern - Service Gerichte Architectuur | Versie 1.0
5
Informatie-uitwisseling: verdieping
5.1
Enterprise service bus
Een Enterprise Service Bus (ESB) is een infrastructuur component en vormt de
technische backbone voor de geautomatiseerde informatie-uitwisseling. Een ESB
richt zich primair op de informatie-uitwisseling tussen systemen en het garanderen
van de betrouwbaarheid daarvan. Bij de betrouwbaarheid gaat het om zaken als
gegarandeerde aflevering, gegarandeerde volgorde van aflevering, prioriteren van
berichten, routeren van berichten, transformeren, converteren, throttling, traffic
shaping, load balancing en failover. Door gebruikt te maken van een ESB hoeven
service afnemers en service aanbieders deze complexe zaken niet zelf te
implementeren, waardoor hun implementaties minder complex zijn. De keuze voor
een ESB betekent dat deze een aantal van de volgende functies uitvoert.
Figuur 14 Functies van de ESB
Protocollen
Ondersteuning voor zowel WUS (WSDL, UDDI en SOAP) als ebMS3 (Electronic
Business Message Service). Bij interne communicatie wordt alleen WUS toegepast.
Extern wordt WUS toegepast bij bevragen (synchrone gegevensuitwisseling, vraag
en direct antwoord) en ebMS en WS-RM4 bij meldingen (asynchrone berichtuitwisseling, vraag en eventueel later een antwoord). Andere protocollen zijn FTP,
JMS, SMTP etc.
3
4
ebMS is een protocol om de berouwbaarheid van berichtenuitwisseling te garanderen. Het regelt zaken zoals
gegarandeerde aflevering, gegarandeerde volgorde van afhandeling en gegarandeerde eenmalige verwerking.
WS-ReliableMessaging is onderdeel van WUS en kan als alternatief voor ebMS gebruikt worden.
Pagina 26 van 38
Definitief | IMEA - Katern - Service Gerichte Architectuur | Versie 1.0
Procescoördinatie
Het coordineren van het aanroepen van webservices, zodat het voor de afnemer als
één samenhangend proces wordt ervaren (orkestreren).
Transformeren
Het vertalen tussen verschillende berichtstructuren (inhoud). Voor transformeren
geldt dat systemen moeten voldoen aan de door IenM gehanteerde interne
koppelvlakken. Dit betekent dat service afnemers en service aanbieders er zelf voor
moeten zorgen dat hun berichten hieraan voldoen.
Converteren
Het vertalen tussen verschillende transportprotocollen. Service afnemende systemen
en service aanbiedende systemen kunnen zelf kiezen welk transportprotocol zij
gebruiken, het vertalen hiertussen wordt door de ESB verzorgd. Voor converteren
geldt wel dat systemen moeten voldoen aan de door IenM gehanteerde interne
transportprotocollen. Dit betekent dat service afnemers en service aanbieders er zelf
voor moeten zorgen dat een ondersteunde transportprotocol wordt gebruikt.
Routeren
Op basis van regels bepalen voor welk systeem een bericht bedoeld is op basis van
header (WS-Addressing).
Betrouwbaarheid
Aflevergarantie zorgt er voor dat een bericht (eenmalig) en in de juiste volgorde
wordt afgeleverd bij de juiste ontvanger (WS-RM, ebMS, JMS).
Transport
Verschillende transportprotocollen worden naast elkaar gebruikt. Afnemende
systemen en webservices aanbiedende systemen kunnen verschillende
transportprotocollen gebruiken. De integratiefunctie zorgt voor vertaling tussen de
verschillende transportprotocollen.
Beveiligen
Identificatie, authenticatie en autorisatie zorgen er voor dat alleen geauthentiseerde
en geautoriseerde afnemende systemen toegang hebben tot een webservice.
Encryptie op basis van PKI certificaten (intern) of PKIoverheid certificaten (extern)
van gevoelige gegevens zorgt voor beveiliging op zowel transportniveau (SSL/TLS)
als berichtniveau (WS-Security).
Integriteit
Het tekenen van berichten op basis van PKI certificaten (intern) of PKIoverheid
certificaten (extern) zorgt er voor dat de authenticiteit en integriteit van berichten
gewaarborgd is en dat gecontroleerd kan worden dat een bericht onderweg niet
gewijzigd is en van de juiste organisatie afkomstig is (WS-Security).
Auditing
Het vastleggen van informatie zodat het onweerlegbaar is dat een bericht is
ontvangen van of verzonden naar een bepaalde organisatie.
Pagina 27 van 38
Definitief | IMEA - Katern - Service Gerichte Architectuur | Versie 1.0
Monitoren
Event logging om het gebruik van services te monitoren en hierover te rapporteren
(gebruiksstatistieken).
Informatie-uitwisselingspatronen
Ondersteuning voor verschillende informatie-uitwisselingspatronen, zoals synchroon
(request response), asynchroon (fire and forget en publish subscribe) en
gebeurtenissen (events).
5.2
Koppelvlak
Er is één gecentraliseerd koppelvlak met de buitenwereld, de demilitarized zone
(DMZ). Alle netwerkverkeer vanaf en met externe netwerken loopt via de DMZ. Alles
buiten het eigen domein wordt als niet vertrouwd beschouwd. De DMZ is semivertrouwd, omdat derden hier toegang toe hebben. Het interne netwerk is
vertrouwd en niet extern toegankelijk. De webserver, reverse proxy en API Gateway
staan in de DMZ en zijn als enige servers voor de buitenwereld toegankelijk. De
DMZ en intern netwerk zijn fysiek gescheiden netwerken.
Er wordt compartimentering toegepast en tussen compartimenten wordt alleen
noodzakelijke communicatie toegestaan. Het compromitteren van een server of
applicatie heeft hierdoor niet direct gevolgen voor een ander compartiment. Voor
compartimentering is een gelaagde opbouw noodzakelijk. Het beveiligingsniveau per
laag neemt toe door communicatie tussen lagen te beperken tot de aangrenzende
lagen. De presentatielaag communiceert met de servicelaag, de servicelaag met de
systeemlagen en de systeemlagen met de datalaag.
5.3
Endpoints
Een endpoint ofwel URI is een uniek adres waar op een service te benaderen is.
Endpoints worden volgens de volgende systematiek opgebouwd.
http(s)://<omgeving>.<domein>:[poort]/<service groep>/<versie>/<service>
Een voorbeeld
https://acc.ilt.nl:8043/inspectieview/bedrijven/v2/opvragenDossier
Een URI element maakt gebruik van camel case, waarbij het eerste element begint
met een kleine letter.
omgeving
Omgeving waarin de service actief is: dev, tst, int, acc, pre of prd.
domein
Domein waar de service actief is: ienm.nl, ilent.nl, rws.nl, nea.nl.
Systemen die in de buitenwereld een eigen identiteit hebben, bijvoorbeeld
Olo of LAVS, hebben een eigen domein (omgevingsloket.nl,
landelijkasbestsysteem.nl).
poort
Poort waarop de server draait waarop de service actief is. Poort is
optioneel en is alleen van toepassing indien direct met de ESB wordt
gecommuniceerd. Standaard wordt via de reverse proxy of API Gateway
Pagina 28 van 38
Definitief | IMEA - Katern - Service Gerichte Architectuur | Versie 1.0
gecommuniceerd en gebruik gemaakt van de standaard poorten, namelijk
80 (http) en 443 (https).
functionele
Functionele groep waar de service toe behoort. Dit is een logische
groep
groepering. Deze kan bestaan uit een of meerdere elementen gescheiden
door een forward slash.
versie
Major versienummer van de service. Het versienummer begint bij 1 en
wordt met 1 opgehoogd voor elke major release waar het koppelvlak
wijzigt (niet backward compatible). Minor versienummers staan in het
bericht zelf.
service
De service zelf. Deze kan bestaan uit een of meerdere elementen
gescheiden door een forward slash.
5.4
Beveiliging
De beveiliging richt zich primair op de gegevensuitwisseling tussen organisaties. Dit
is het concept van vertrouwde domeinen. Het concept van de vertrouwde domeinen
gaat er van uit dat binnen een vertrouwd domein de beveiligingsmaatregelen aan de
informatiebeveiligingseisen voldoen, waardoor services afnemers en services
aanbieders elkaar kunnen vertrouwen.
Netwerken tussen vertrouwde domeinen worden als niet veilig beschouwd. Dit geldt
ook voor overheidsnetwerken en Diginetwerk. Voor het transport over deze nietvertrouwde netwerken zijn beveiligingsmaatregelen noodzakelijk in de vorm van
encryptie op transportniveau (SSL/TLS). Als berichten vertrouwelijke informatie
bevatten wordt dit aangevuld met encryptie op berichtniveau. In de afspraken die
een service aanbieder en service afnemer maken over informatie-uitwisseling wordt
duidelijk vastgelegd welke beveiligingsmaatregelen van toepassing zijn. Berichten
kunnen op de volgende niveaus beveiligd worden.
Identificatie en authenticatie
Identificatie en authenticatie bij externe communicatie wordt gerealiseerd door het
toepassen van tweezijdige SSL/TLS, daarbij identificeren zowel het service aanbiedende als het service afnemende systemen zich met behulp van een PKIoverheid
certificaat. Bij elke serviceaanroep wordt gecontroleerd of het organisatie ID in het
bericht overeenkomt met het organisatie ID (OIN) in het PKIoverheid certificaat is
en of deze organisatie geautoriseerd is voor de service die wordt aangeroepen.
Intern zal na ingebruikname van de API Gateway OAuth toegepast voor identificatie
en authenticatie.
Transport
Informatie in berichten wordt door encryptie op transportniveau (SSL/TLS)
afgeschermd voor onbevoegden.
De beveiliging op transportniveau is een zogenoemde point-to-point beveiliging.
Voor een bericht dat via meerdere overdrachtspunten wordt getransporteerd, moet
op elk overdrachtspunt opnieuw een beveiligde verbinding opgebouwd worden met
het volgende overdrachtspunt. De informatie in de berichten is op de overdrachtspunten leesbaar. Indien het bericht vertrouwelijke informatie bevat dient beveiliging
op transportniveau aangevuld te worden met encryptie op berichtniveau.
Bericht
Pagina 29 van 38
Definitief | IMEA - Katern - Service Gerichte Architectuur | Versie 1.0
Informatie in berichten wordt door encryptie op berichtniveau (WS-Security)
afgeschermd voor onbevoegden. De beveiliging op berichtniveau is een zogenoemde
end-to-end beveiliging. De informatie in de berichten is dan ook op de overdrachtspunten niet leesbaar.
Normaal gesproken zijn service afnemers en service aanbieders zelf
verantwoordelijk voor het versleutelen en ontsleutelen van berichten. IenM kiest er
echter voor om deze verantwoordelijkheid op de ESB op te lossen en niet in de
achterliggende systemen of services zelf.
Integriteit
Door berichten te ‘ondertekenen’ met behulp van een PKIoverheid certificaat is de
authenticiteit en integriteit van deze berichten gewaarborgd en kan gecontroleerd
worden dat een bericht onderweg niet gewijzigd is en afkomstig is van de juiste
organisatie (WS-Security). De beveiliging op integriteitsniveau is een zogenoemde
end-to-end beveiliging.
Normaal gesproken zijn service afnemers en service aanbieders zelf
verantwoordelijk voor het ondertekenen van berichten en het controleren hiervan.
IenM kiest er echter voor om deze verantwoordelijkheid op de ESB op te lossen en
niet in de achterliggende systemen of services zelf.
Combinatie van niveaus
Combinatie van bovengenoemde beveiligingsmaatregelen.
Het classificatieniveau van de informatie die wordt uitgewisseld, bepaalt het vereiste
beveiligingsniveau. In de volgende tabel zijn de verschillende classificatieniveaus
van informatie weergegeven en de niveaus waarop beveiligingsmaatregelen
genomen moeten worden.
Classificatieniveau
Transportniveau
Niet geclassificeerd
x
Confidentieel
x
Vertrouwelijk
x
Berichtniveau
Integriteitsniveau
x
x
x
Geheim
Zeer geheim
De laatste twee categorieën mogen niet elektronisch uitgewisseld worden.
5.5
Herleidbaarheid
Berichten moeten herleidbaar zijn in de keten. Een bericht wordt voorzien van een
uniek ID. Dit ID wordt door elk systeem gelogd, zodat het eenvoudig is om een
transactie in de keten te volgen. Indien het berichtenverkeer wordt geïnitieerd door
een actie van een gebruiker dan dient het initiërend systeem ook het gebruiker ID te
registeren. Als een bericht het antwoord is op een voorgaand bericht dan wordt in
het antwoordbericht het unieke ID het oorspronkelijke bericht opgenomen. Hierdoor
worden berichten traceerbaar door de hele keten heen, dit vereenvoudigd het
achterhalen en herstellen van fouten. Daarnaast wordt het mogelijk om auditing
informatie bij te houden. Voor het registreren van het ID wordt gebruik gemaakt
van de WS-Addressing velden MessageID en RelatesTo.
Pagina 30 van 38
Definitief | IMEA - Katern - Service Gerichte Architectuur | Versie 1.0
6
Informatie-uitwisseling: standaard uitwisselingsformaat
6.1
Inleiding
Voor geautomatiseerde informatie-uitwisseling tussen systemen zijn afspraken nodig
over het verpakken van de informatie in elektronische berichten ten behoeve van
het versturen ervan, dit geldt voor zowel de ‘envelop’ als het ‘document’ dat er in
wordt verpakt. De afspraken hebben gemeenten vastgelegd in standaard
uitwisseling formaat (StUF). Het College van Standaardisatie heeft StUF geplaatst op
haar ‘pas toe of leg uit’-lijst en is verplicht voor alle ketens waarin informatieuitwisseling met gemeenten plaatsvindt.
Het generieke karakter van de StUF-standaard wordt wel eens vergeleken met de
pads voor een Senseo-apparaat. Je kunt met de pads, een gestandaardiseerde
verpakking, vele smaken koffie zetten (maar ook chocolademelk en thee).
In de volgende figuur is een gedeelte van de ‘StUF-familie’ weergegeven.
Figuur 15 Een gedeelte van de StUF-familie
In bovenstaande figuur lopen de verticale balkjes door onder de vier horizontale
balkjes. Dit om zichtbaar te maken dat de verticale modellen altijd
gegevenselementen bevatten uit de horizontale modellen. In een verticaal model
zijn daar gegevens voor een specifieke sector aan toegevoegd.
6.2
StUF berichtenstandaard
Pagina 31 van 38
Definitief | IMEA - Katern - Service Gerichte Architectuur | Versie 1.0
Binnen de StUF-familie wordt de centrale plaats ingenomen door de ‘StUF
berichtenstandaard’. Op basis van deze berichtenstandaard zijn zowel de horizontale
sectormodellen (generieke berichtenschema’s) als verticale sectormodellen
(specifieke berichtenschema’s) gedefinieerd.
6.3
StUF protocolbindingen
In de StUF protocolbindingen is uitgewerkt hoe StUF-berichten gebruik maken van,
oftewel ‘gebonden’ zijn aan internationale transportprotocollen zoals HTTP, HTTPS of
JMS. Daarnaast is er ondersteuning voor internationale berichtprotocollen zoals WUS
en ebMS, waarbij rekening wordt gehouden met de profielen die hierop gedefineerd
zijn door Digikoppeling.
6.4
StUF horizontale sectormodellen
Er zijn twee horizontale sectormodellen: StUF Basisgegevens (StUF-BG) en StUF
Zaken (StUF-ZKN). In deze sectormodellen zijn StUF berichten uitgewerkt voor het
uitwisselen van basisgegevens gebaseerd op het RSGB en van zaakgegevens
gebaseerd op het RGBZ.
RSGB
In het RSGB, het Referentiemodel Stelsel Gemeentelijke Basisgegevens, zijn de
gegevens van alle relevante basisregistraties uitgewerkt, en aangevuld met
gemeente-specifieke basisgegevens.
RGBZ
In het RGBZ, het Referentiemodel Gemeentelijke Basisgegevens Zaken, zijn de
gegevens uitgewerkt die minimaal nodig zijn om op de hoogte te blijven van de
voortgang van lopende zaken, en het kunnen verantwoorden en reconstrueren van
lopende en afgeronde zaken.
6.5
StUF verticale sectormodellen
Er zijn meerdere verticale sectormodellen, bijvoorbeeld StUF-LVBAG en StUF-WKPB.
In deze sectormodellen zijn StUF berichten uitgewerkt voor het uitwisselen van
informatie met de landelijke voorzieningen van de basisregistraties Adressen en
Gebouwen (BAG) en die van publiekrechtelijk beperkingen (WKPB).
6.5.1
Architectuurkeuze standaard informatie-uitwisseling
Voor de informatie-uitwisseling in ketens met daarin ook gemeenten wordt gebruik
gemaakt van het Standaard Uitwisseling Formaat (StUF).
Motivering
StUF staat op de ‘pas toe of leg uit’-lijst van het College Standaardisatie en
is verplicht voor alle ketens waarin informatie-uitwisseling met gemeenten
plaatsvindt.
Het gebruik van deze bouwsteen is in lijn met NORA en MARIJ.
Pagina 32 van 38
Definitief | IMEA - Katern - Service Gerichte Architectuur | Versie 1.0
7
Informatie-uitwisseling: e-Overheid bouwstenen
7.1
Beschikbare bouwstenen
Diginetwerk
Digikoppeling
Systeem
overheidsorganisatie A
Digikoppeling
Voor de geautomatiseerde informatie-uitwisseling tussen systemen van overheidsorganisaties zijn twee bouwstenen beschikbaar: Digikoppeling en Diginetwerk.
Systeem
overheidsorganisatie B
Figuur 16 Informatie-uitwisseling tussen overheidsorganisaties
Voor de geautomatiseerde informatie-uitwisseling tussen systemen van overheidsorganisaties en bedrijven is een extra bouwsteen beschikbaar: Digipoort.
Figuur 17 Informatie-uitwisseling tussen overheid en bedrijven
7.2
Diginetwerk
Diginetwerk is een landelijke bouwsteen die overheidsorganisaties op eenvoudige en
gestandaardiseerde wijze de mogelijkheid biedt om geautomatiseerd informatie uit
te wisselen met andere overheidsorganisatie. Diginetwerk koppelt bestaande
transportvoorzieningen zoals Haagse Ring, Gemnet, SUWInet en SURFnet tot één
overheidsbreed netwerk. Diginetwerk is een Virtual Private Network (VPN), een
besloten netwerk. Dit VPN schermt de uit te wisselen informatie af van de
buitenwereld, maar daar binnen (op het VPN) is de informatie niet afgeschermd.
7.3
Digikoppeling
Digikoppeling is een overheidsbrede standaard, een eenduidige set afspraken, op
het gebied van informatie-uitwisseling. Deze afspraken hebben betrekking op
informatie-uitwisseling tussen twee systemen via services. De standaard draagt bij
aan een eenvoudige en veilige informatie-uitwisseling en zorgt voor maximale
interoperabiliteit. Digikoppeling kan ook toegepast worden bij het elektronisch
berichtenverkeer tussen overheden en bedrijven.
Pagina 33 van 38
Definitief | IMEA - Katern - Service Gerichte Architectuur | Versie 1.0
7.4
Digipoort
Digipoort is een landelijke bouwsteen die bedrijven de mogelijkheid biedt om
geautomatiseerd informatie uit te wisselen met overheidsorganisaties. Digipoort
zorgt er voor dat de informatie van een bedrijf bij de juiste overheidsorganisatie
terecht komt en dat informatie die een overheidsorganisatie verstuurt, wordt
afgeleverd bij het juiste bedrijf. De informatie-uitwisseling tussen een
overheidsorganisatie en Digipoort vindt op dezelfde wijze plaats als tussen systemen
van overheidsorganisaties.
Het voordeel van Digipoort voor niet-overheidspartijen is dat zij via één aansluiting
kunnen koppelen met steeds meer systemen van de overheid. Het voordeel voor
overheidsorganisaties is dat zij via één aansluiting kunnen koppelen met nietoverheidspartijen. Dit vereenvoudigt de beheerlast voor koppelingen aanzienlijk.
7.4.1
Architectuurkeuze generieke bouwstenen voor informatie-uitwisseling
Voor de informatie-uitwisseling met systemen van overheidsorganisaties wordt
gebruik gemaakt van Digikoppeling en Diginetwerk. En in aanvulling daarop van
Digipoort voor de informatie-uitwisseling met systemen van bedrijven.
Motivering
De bouwstenen zijn voor overheidsbrede gebruik ontwikkeld en beschikbaar.
Het gebruik van deze bouwstenen is in lijn met NORA en MARIJ.
Pagina 34 van 38
Definitief | IMEA - Katern - Service Gerichte Architectuur | Versie 1.0
8
Bijlage A: Informatie-uitwisselingsmodel uitgebreid
Pagina 35 van 38
Definitief | IMEA - Katern - Service Gerichte Architectuur | Versie 1.0
9
Bijlage B: PKIoverheid certificaten
Extern zijn services alleen beschikbaar voor bekende en geautoriseerde afnemers.
Bij informatie-uitwisseling moet de identiteit van een toeleverancier of afnemer
eenduidig en betrouwbaar worden vastgesteld (identificeren en authentiseren) en
moet bepaald worden of deze toegang heeft tot de gevraagde service (autoriseren).
Bij informatie-uitwisseling tussen overheidspartijen onderling wordt gebruik
gemaakt van PKIoverheid certificaten voor identificatie en authenticatie. IenM
hanteert hetzelfde mechanisme bij informatie-uitwisseling met bedrijven en indien
van toepassing burgers. Bij de informatie-uitwisseling wordt dan op transportniveau
een tweezijdige SSL/TLS verbinding opgebouwd waarbij zowel de aanbieder als de
afnemer zich identificeren met een PKIoverheid certificaat.
PKIoverheid certificaten bestaan uit meerdere certificaten, een zogenaamde
certificaat chain die een chain of trust vormt. Het valideren van een client certificaat
wordt gedaan door het valideren van deze chain of trust. Hierbij wordt de certificaat
chain achterstevoren afgelopen vanaf het client certificaat tot en met de root
certificate authority (Root CA). Gevalideerd wordt of elk certificaat in de chain of
trust is uitgegeven door een vertrouwde partij. Als het client certificaat vertrouwd is
wordt op basis van de begin- en einddatum gecontroleerd of het certificaat nog
geldig is en dat deze niet ingetrokken is (revoked). Controle of een certificaat
ingetrokken is, wordt gedaan aan de hand van een certificate revocation list (CRL).
De CRL lijsten van PKIoverheid certificaten staan op de website van Logius5.
Figuur 18 Chain of trust van een PKIoverheid certificaat
5
https://crl.pkioverheid.nl/
Pagina 36 van 38
Definitief | IMEA - Katern - Service Gerichte Architectuur | Versie 1.0
Toelichting op de certificaat chain zoals weergegeven in bovenstaande figuur:
Client: In het subject van het certificaat is een Overheidsidentificatienummer
(OIN) opgenomen. Het OIN is uniek en behoort bij één organisatie.
CSP: Een Certificate Service Provider (CSP) is een partij die beschikt over een
CSP certificaat op basis waarvan deze certificaten kan uitgeven. Er zijn
verschillende CSP’s voor PKIoverheid. De CSP kan verschillen per client
certificaat. De CSP certificaat wordt in de API Gateway trust store geplaatst.
Intermediate CA en Root CA: Bij PKIoverheid certificaten zijn de intermediate CA
en Root CA altijd hetzelfde. Beide certificaten worden in de API Gateway trust
store geplaatst.
Bij de validatie van de chain of trust wordt gevalideerd of het certificaat uitgegeven
is door een vertrouwde partij (Root CA) en of alle tussenliggende intermediairs
vertrouwd zijn. Verschillende client certificaten kunnen dezelfde chain of trust
hebben. Het is daarom noodzakelijk dat ook het client certificaat zelf gevalideerd
wordt. Dat wordt gedaan door het OIN nummer in het certificaat te controleren. Het
OIN is opgenomen in het subject.SERIALNUMBER veld van het certificaat.
Autoriseren wordt gedaan op basis van de combinatie OIN en service URI. Hiermee
kan op serviceniveau geautoriseerd worden. Als het certificaat geauthentiseerd is en
de combinatie OIN en URI geautoriseerd is dan heeft de afnemer toegang tot de
desbetreffende service.
IenM handelt identificatie, authenticatie en autorisatie op het extern koppelvlak
centraal af. Hierdoor hoeven achterliggende systemen of services dit niet zelf te
regelen. In de toekomst zal identificatie, authenticatie en autorisatie volledig
transparant door de API Gateway worden afgehandeld.
Tot de API Gateway beschikbaar is wordt identificatie en authenticatie opgelost op
de reverse proxy (RP) en autorisatie in de koppeling op de ESB. Als het client
certificaat vertrouwd is, wordt het OIN of het hele subject.SERIALNUMBER uit het
client certificaat gehaald en als HTTP header in de request doorgegeven naar de
ESB.
Figuur 19 Identificatie en authenticatie door reverse proxy, autorisatie door koppeling
Pagina 37 van 38
Definitief | IMEA - Katern - Service Gerichte Architectuur | Versie 1.0
De RP kan het OIN dus op twee manieren doorsturen naar de ESB, afhankelijk van
de gehanteerde methode is dat andere HTTP header gezet:
CERT_SUBJECT: De RP haalt het hele subject.SERIALNUMBER uit het certificaat
en geeft deze in de HTTP header CERT_SUBJECT door naar de koppeling op de
ESB. De koppeling op de ESB extraheert zelf het OIN uit de subject en
controleert of het OIN geautoriseerd is voor de koppeling.
CERT_OIN: De RP haalt het OIN zelf uit het subject.SERIALNUMBER van het
certificaat en geeft deze in de HTTP header CERT_OIN door naar de koppeling op
de ESB. De koppeling controleert of het OIN geautoriseerd is voor de koppeling.
Indien een OIN niet geautoriseerd is wordt een HTTP status code 401 Unauthorized
teruggegeven.
Pagina 38 van 38

Download Report