Ministerie van Infrastructuur en Milieu 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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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)://.<domein>:[poort]/<service groep>//<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


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


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


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


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


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


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


8

Bijlage A: Informatie-uitwisselingsmodel uitgebreid

Pagina 35 van 38


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


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


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

Ministerie van Infrastructuur en Milieu IMEA - Katern - Service Gerichte Architectuur

Recommend Documents