Katern GEMMA Verbinden
Hoofdstuk: Bijlage: Integratiestijlen en functies
- Inleiding
- Principes en richtlijnen
- Ontsluiting en actualiteit van gegevens
- Verbinden met klanten
- Verbinden in ketens en netwerken
- Referentiecomponenten voor integratie
- GEMMA Patronen
- Bijlage: Integratiestijlen en functies
Deze pagina is een onderdeel van Katern GEMMA Verbinden compleet: Hele document bekijken - Exporteren - Definitie
Vanuit de literatuur zijn er een aantal standaard patronen beschreven die gebruikt worden bij het integreren van informatiesystemen. Deze patronen worden integratiestijlen genoemd. In dit hoofdstuk worden de uit de literatuur bekende integratiepatronen beschreven en worden de belangrijkste functies beschreven die voor de implementatie van de integratiepatronen van belang zijn.
Integratiestijlen
Bij uitwisseling tussen, en integratie van, informatiesystemen werken één of meer informatiesystemen samen tijdens de uitvoering van hun functies. Deze samenwerking kan bestaan uit de uitwisseling van gegevens, informatie of signalen met andere informatiesystemen of het laten uitvoeren van delen van taken van het ene informatiesysteem door een ander informatiesysteem. Voor het laten samenwerken van informatiesystemen zijn binnen de IT een aantal standaard ‘integratiestijlen’ beschreven. De leidende stijlen zijn (Hophe & Woolf, 2006):
- Gedeelde database (shared database);
- Bestandsuitwisseling;
- Externe applicatiefunctionaliteit aanroep, en
- Berichtuitwisseling.
Elk van de integratiestijlen kent een toepassingsgebied, specifieke voor- en nadelen en functionaliteit die benodigd is voor het realiseren van de integratiestijl. In de praktijk bij gemeenten worden de meeste van deze integratiestijlen toegepast.
Doel van de integratiestijl is het delen van gegevens tussen informatiesystemen. Dit wordt in deze integratiestijl bereikt door meerdere informatiesystemen gebruik te laten maken van één gedeelde gegevensopslag. Toegang tot de gegevensopslag wordt verschaft door aan de informatiesystemen lees- en schrijfrechten op deze gegevensopslag te verlenen. Toegang tot de gegevens wordt geleverd door het database management systeem (DBMS).
Gedeelde database integratiestijl (uit model: GEMMA 2) - Toon SVG - Download als csv
Het door meerdere informatiesystemen lezen van gegevens uit een gedeelde database is vanuit het oogpunt van gegevensintegriteit relatief risicoloos. Aan het muteren van gegevens in een gedeelde database kleven op dat vlak wel risico’s. Bij mutaties van gegevens in een gedeelde database borgt het DBMS de referentiële integriteit van de gegevens. Wat het DBMS niet doet is het borgen van de kwaliteit van de gegevens. Deze kwaliteitscontroles liggen immers in bedrijfsregels vast in de bedrijfslogica van informatiesystemen die gebruik maken van de gedeelde opslag. Hierdoor kan het voorkomen dat gegevens die door informatiesysteem A worden opgeslagen volgens de bedrijfsregels van informatiesysteem B van onvoldoende kwaliteit zijn. Denk hierbij aan controles die worden uitgevoerd op de combinatie van postcode, huisnummer en straatnaam. Sommige informatiesystemen zullen deze combinatie afdwingen door gebruik van een postcodetabel terwijl andere informatiesystemen dit niet doen.
De gedeelde database integratiestijl kent verder zeer beperkte mogelijkheden op het gebied van informatiebeveiliging, bescherming van de privacy en verantwoording over de verwerking van gegevens. De oorzaak hiervan ligt in een aantal oorzaken:
- Er is geen mogelijkheid om op het niveau van de gegevensopslag doelbinding van de afnemer af te dwingen bij het verwerken van gegevens. Doelbinding kan slechts afgedwongen worden in de aangesloten informatiesystemen;
- Gegevens kunnen buiten de uitvoering van een proces om gemuteerd worden door een andere applicatie. Dit staat op gespannen voet met de integriteit van gegevens en het achteraf kunnen afleggen van verantwoording over de uitvoering van processen;
- Gegevens kunnen verloren gaan of inconsistent worden doordat de verschillende aangesloten informatiesystemen op verschillende wijze omgaan met het ‘locken’ van gegevens in de database op het moment dat gegevens gemuteerd worden.
Om bovenstaande redenen is toepassing van deze integratiestijl bij de verwerking van privacygevoelige gegevens afgeraden . Indien gegevens van verschillende informatiesystemen opgeslagen moeten worden binnen één gegevensopslag dan is daarvoor het ‘Externe applicatiefunctionaliteit aanroep’ integratiepatroon de aangewezen oplossing. Hierbij moet worden opgemerkt dat deze aanbeveling geldt voor situaties waar meerdere informatiesystemen gegevens delen en niet van toepassing is op één informatiesysteem wat meerdere referentiecomponenten implementeert. Op het moment dat één informatiesysteem invulling geeft aan meerdere referentiecomponenten dan is er geen bezwaar tegen het delen van de opslag door deze referentiecomponenten. De beschreven nadelen treden dan namelijk niet op.
Een gebied waarop deze integratiestijl wel toegepast kan worden is het geo-domein. In dit domein worden gegevens verwerkt die meestal publiek van aard zijn. Hierdoor treden de eerder genoemde risico’s op het gebied van de privacy niet op. Met name in dit domein is het mogelijk om, via een modern databasemanagementsysteem dat ook geografische data kan verwerken (bijvoorbeeld Oracle Spatial), verschillende ruimtelijke objecten binnen één databaseopslag bij te houden. Een dergelijk databasemanagement is tevens in staat om de geografische data via slimme views zo te transformeren, zodat dezelfde geodata voor verschillende GIS-systemen (Geoviewer, BeheerGIS, AnalyseGIS en een GEO-API) begrijpelijk wordt. Belangrijk hierbij is wel dat per objecttype er één eigenaar benoemd is zodat geen dubbel beheer van objecten plaatsvindt met risico’s van het overschrijven van wijzigingen. De eerder beschreven locking problematiek wordt daarmee data beheersbaar en een beperkt risico.
Een bijzondere uitwerking van de ‘gedeelde database’ integratiestijl is geven van leesrechten tot gegevens van een informatiesysteem aan andere informatiesystemen via directe toegang tot de gegevensopslag. Toegang tot de gegevens wordt geleverd door het database management systeem (DBMS). Gegevens worden gelezen uit de database via gegevensservices die aangeroepen worden via een SQL- of soortgelijke interface.
Integratiestijl data integratie (uit model: GEMMA 2) - Toon SVG - Download als csv
Een aantal van de nadelen die spelen bij de ‘gedeelde database’ integratiestijl kleven ook aan de ‘data integratie’ integratiestijl. Het aanroepende informatiesysteem moet toegang hebben tot de database en moet de structuur, en onderlinge verbanden, van de databasetabellen kennen. Bij wijziging van de structuur van de opslag kan dit leiden tot het ‘breken’ van de koppeling.
Situaties waarbij toepassing van deze integratiestijl valt te overwegen is bij de ontsluiting van gegevens van bronsystemen naar management informatie- en rapportagesystemen.
Geadviseerd wordt om grote terughoudendheid te betrachten ten aanzien van de toepassing van deze integratiestijl, in het bijzonder op het moment dat deze integratiestijl wordt toegepast in een omgeving waar informatiesystemen van meerdere verschillende leveranciers gebruikt worden. In deze situatie is kan het namelijk voorkomen dat de verschillende leveranciers verschillende strategieën toepassen ten aanzien van ‘locking’ van gegevens (optimistisch/ pessimistisch en record/table locking) wat in het ergste geval kan leiden tot verlies van gegevens en inconsistente gegevens.
Door de gedeelde generieke functionaliteit van de GEMMA architectuur wordt geen ondersteuning geboden voor deze integratiestijl.
Bestandsuitwisseling
Doel van de integratiestijl is het delen van gegevens tussen informatiesystemen. Bij deze integratiestijl wordt dit gerealiseerd door het uitwisselen van bestanden tussen informatiesysteem. Door de bedrijfslogica van het verzendende systeem worden gegevens geëxporteerd naar een bestand wat op een meestal gestandaardiseerde wijze is gestructureerd (syntax). Denk hierbij aan CSV, JSON of XML-bestanden. Bedrijfslogica van het ontvangende systeem (de consumer) importeert via een applicatieinterface het bestand wat door een zendend systeem is aangemaakt (de provider), transformeert desgewenst de gegevens en neemt deze op in de eigen gegevensopslag. Integratiefuncties die van belang zijn bij deze integratiestijl zijn transformatie, monitoring en beveiliging.
Integratiestijl Bestandsuitwisseling (uit model: GEMMA 2) - Toon SVG - Download als csv
Deze integratiestijl wordt in de praktijk relatief frequent toegepast. Voorbeelden zijn het aanleveren van statistische gegevens aan het Centraal Bureau voor de Statistiek (CBS) en het uitwisselen van iWmo en iJw berichten met zorgaanbieders via de up- en download portalen van het Gemeentelijk Gegevensknooppunt (GGk).
Belangrijk aandachtspunt bij de bestandsuitwisseling integratiestijl is de borging van een adequaat niveau van beveiliging van de infrastructuur die gebruikt wordt bij de uitwisseling. Indien gevoelige gegevens uitgewisseld worden dient de uitwissing van de gegevens op een veilige wijze plaats te vinden. Dit vraagt bij deze integratiestijl om technische zaken zoals HTTPs of sFTP en uitwisseling via een private infrastructuur zoals Gemnet.
Externe applicatiefunctionaliteit aanroep
Doel van de integratiestijl is het hergebruik maken van logica van informatiesystemen. Hiertoe stellen informatiesystemen services die bepaalde functionaliteit uitvoeren beschikbaar aan andere informatiesystemen. Technisch gezien kunnen deze services op verschillende manieren worden geïmplementeerd. De uitdrukkelijke voorkeur is om gebruik te maken van services die toegankelijk zijn via http(s) als transportprotocol, SOAP of REST als communicatie protocol en XML of JSON als uitwisselformaat. De services die door systemen beschikbaar worden gesteld kunnen direct, of via een servicebuscomponent worden aangesproken. Door het gebruik van een servicebuscomponent wordt zogenaamde 'loose coupling' geïmplementeerd. Hierdoor worden point-to-point koppelingen met afhankelijkheden tussen informatiesystemen voorkomen. Deze wijze van koppelen heeft de voorkeur boven het direct onderling koppelen van informatiesystemen.
Het informatiesysteem dat de service aanbiedt aan afnemende informatiesystemen heeft de verantwoordelijkheid te borgen dat gegevens die door de service geleverd worden enkel aan geautoriseerde afnemende informatiesystemen geleverd worden. Een afnemend informatiesysteem mag alleen geautoriseerd worden voor de gegevens die het afnemende informatiesysteem nodig heeft voor de uitvoering van wettelijke taken (doelbinding). Een informatiesysteem kan verschillende doelbindingen ondersteunen. Het is de verantwoordelijkheid van het afnemende informatiesysteem te borgen dat een eindgebruiker enkel gegevens kan verwerken voor de doelbinding waarvoor werkzaamheden worden verricht. In de afspraken die tussen aanbieder en afnemer van gegevens worden gemaakt worden de randvoorwaarden afgesproken die gelden ten aanzien van het gebruik van de gegevens. Deze afspraken kunnen worden vastgelegd in een Gegevensleveringsovereenkomst (GLO). Zie het Tactisch Katern Gegevensmanagement voor een nadere beschrijving van de inhoud van een GLO en de bij het opstellen van een GLO betrokken rollen.
Integratiestijl externe applicatiefunctie aanroep (uit model: GEMMA 2) - Toon SVG - Download als csv
In bovenstaand figuur wordt de service die door Informatiesysteem A wordt geboden gebruikt door Informatiesysteem B. Bij dit integratiepatroon is het van belang om gebruik te maken van services die duidelijk zijn omschreven, en zijn gestandaardiseerd op het gebied van autorisatie en authenticatie. Dit maakt het op een uniforme, en controleerbare wijze implementeren van beveiligings- en monitoringsfuncties mogelijk. Dit laatste is van belang in verband met het in control zijn over de verwerking van gegevens en het compliant zijn op het gebied van wet- en regelgeving.
Berichtuitwisseling
Doel van de integratiestijl is het integreren van informatiesystemen zonder de systemen van elkaar afhankelijk te maken (zogenaamde tight coupling). Bij deze integratiestijl verzend een informatiesysteem bij voorkeur via een servicebus een bericht naar een ander informatiesysteem. Doel van het bericht is om bedrijfslogica in het ontvangende systeem aan te spreken zonder afhankelijk te zijn van de beschikbaarheid van het ontvangende systeem en zonder te wachten op de uitvoering van de bedrijfslogica. Het gaat hierbij dus meestal om asynchrone integratie. Voor het zendende informatiesysteem is het enkel van belang dat het bericht correct ontvangen is door de servicebus. Wanneer de ontvangende partij het bericht ontvangt, en wat deze partij met het bericht doet is ontkoppeld van het verzenden van het bericht door de verzender.
Integratiestijl berichtuitwisseling (uit model: GEMMA 2) - Toon SVG - Download als csv
Binnen deze integratiestijl kan een opdeling worden gemaakt in berichten die enkel context bevatten en berichten die context en de inhoudelijke gegevens bevatten. In het eerste geval spreken we binnen GEMMA over notificaties en in het tweede geval over kennisgevingen. Notificaties geven aan dat er iets gebeurd is en kennisgevingen geven aan dat er iets gebeurd is en wat de relevante gegevens daarbij zijn.
Integratiefuncties
Om de eerder beschreven integratiepatronen te implementeren zijn een aantal functies nodig die generiek zijn voor alle integratiepatronen en functies die voor één of meerdere patronen van belang zijn. De functies zijn:
- routeren;
- orkestreren;
- transformeren;
- abonneren;
- loggen;
- monitoren;
- beveiligen.
Elk van deze functies kent zijn eigen doel en verantwoordelijkheden. Onderstaande tabel geeft per integratiestijl de integratiefuncties weer waaraan invulling moet worden gegeven.
| Orkestreren | Routeren | Transformeren | Abonneren | Monitoren | Loggen | Beveiligen | |
|---|---|---|---|---|---|---|---|
| Gedeelde opslag | X | X | X | ||||
| Data integratie | X | X | X | X | |||
| Bestandsuitwisseling | X | X | X | X | X | X | |
| Externe applicatiefunctionaliteit aanroep | X | X | X | X | X | X | X |
| Berichtuitwisseling | X | X | X | X | X | X |
De verschillende functies worden hieronder nader geduid en beschreven.
Abonnementenfunctie
De abonnementenfunctie is verantwoordelijk voor het registreren van de afnemers die in een bepaald gegeven of signaal, of categorie van gegevens en signalen, geïnteresseerd zijn. Via de abonnementenfunctie kan een afnemer zich abonneren op wijzigingen van gegevens of ontvangen signalen. De afnemer kan per abonnement instellen wat de condities zijn waaronder een gegeven of signaal naar de ontvanger verzonden moet worden.
Routeringsfunctie
De routeringsfunctie is verantwoordelijk voor het afleveren van berichten en bestanden bij de juiste partij(en). De routeringsfunctie kan routeren op basis van de soort serviceaanvraag (message-based routing) of op basis van de inhoud van een serviceaanvraag (content-based routing). De routeringsfunctie heeft de verantwoordelijkheid om te borgen dat de berichten die aangeboden worden daadwerkelijk afgeleverd worden op de plek van bestemming (guaranteed delivery). Dit zal in de meeste gevallen worden geïmplementeerd door een voorziening die berichten tijdelijk opslaat tot ze succesvol afgeleverd zijn (store-and-forward).
Orkestratiefunctie
Via de orkestratiefunctie is het mogelijk om één serviceaanvraag te laten beantwoorden door meerdere partijen. De serviceaanvraag wordt hiertoe gesplitst en naar meerdere partijen gerouteerd. Iedere partij is verantwoordelijk voor het beantwoorden van een deel van het verzoek. De antwoorden van de verschillende partijen worden door de orkestratiefunctie ontvangen en samengevoegd naar één antwoord richting de aanvrager. De orkestratiefunctie maakt gebruik gemaakt van de routeringsfunctie voor wat betreft de guaranteed delivery functionaliteit voor tijdelijke opslag van het verzoek, de verschillende aanvragen en deelantwoorden. De orkestratiefunctie wordt daarom altijd samen met de routeringsfunctie geboden. Andersom kan de routeringsfunctie wel zonder orkestratiefunctie worden gebruikt. Eventueel gebruik van de transformatiefunctie behoort ook nog tot de mogelijkheden.
Transformatiefunctie
De transformatiefunctie biedt de mogelijkheid om gegevens die tussen een leverancier en afnemer van een dienst worden uitgewisseld te transformeren. Denk hierbij aan een transformatie van een datum in formaat YYYYMMDD naar dd-mm-yyyy of het samenvoegen van de waarde van twee attributen naar één attribuutwaarde.
Logging
Deze functie registreert de verwerking van gegevens. Per verwerking worden datum/tijd van verwerking, soort verwerking, gebruiker, doelbinding en verwerkte attributen/categorieën vastgelegd. De registratie dient bij voorkeur vastgelegd te worden op een niet muteerbaar medium om de integriteit van de registratie te kunnen garanderen.
Monitoringsfunctie
Een belangrijke verbindingsfunctie is die van monitoring. De monitoringfunctie houdt statistische gegevens bij waarmee inzicht gegeven kan worden in het gebruik van services, responsetijden en opgetreden fouten. Met behulp van de gegevens van de monitoringsfunctie kan bepaald worden of de afgesproken SLA’s ten aanzien van de diensten gehaald worden en kan proactief actie ondernomen worden op het moment dat verstoringen optreden.
Beveiligingsfunctie
De beveiligingsfunctie borgt dat toegang tot gegevens of diensten plaatsvindt via autorisatie-objecten. Alle toegang tot autorisatie-objecten wordt expliciet geauthenticeerd en geautoriseerd, tenzij deze openbaar toegankelijk zijn. Gebruikers krijgen enkel toegang tot autorisatie-objecten indien zij persoonlijk, of via een rol, hiertoe geautoriseerd zijn.