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

Transcriptie

1 Document D-8 Ministerie van Infrastructuur en Milieu IMEA - Katern - Service Gerichte Architectuur Versie 1.0 Datum 15 juli 2014 Status Definitief

2 Colofon Versie 1.0 Contactpersoon Paul Leunissen M Paul.Leunissen@minienm.nl Ministerie van Infrastructuur en Milieu Hoofddirectie Financiën, Management en Bedrijfsvoering Directie Concern Informatievoorziening Afdeling Architectuur en Informatie Management Team Architectuur Koningskade 4 Postbus EX Den Haag Auteurs Peter Visser Stephen Oostenbrink Pagina 2 van 38

3 Inhoud 1 Inleiding Identificatie Leeswijzer Doel van dit document Referenties Afkortingen en begrippen Service Gerichte Architectuur Inleiding Architectuurkeuze Service Gerichte Architectuur Servicecontract Performance Onderscheid externe en interne informatie-uitwisseling Externe informatie-uitwisseling Interne informatie uitwisseling Architectuurkeuze onderscheid interne en externe informatie-uitwisseling Stelsel van ESB s met het Centraal Aansluitpunt Centraal Aansluitpunt Architectuurkeuze stelsel van ESB s met een Centraal Aansluitpunt Domein specifieke koppelingen Beveiliging Versies Architectuurkeuze ondersteuning versies Service gerichte architectuur: verdieping Servicelagenmodel Interactiekanalen Processervices Business services Technische services Backend Service principes Communicatieprincipes Ontwerpprincipes Proces en compositie Orkestratie Taken service BPEL4People Informatie-uitwisseling Inleiding Informatie-uitwisseling lagenmodel Elektronisch berichtmodel Informatie-uitwisseling: verdieping Enterprise service bus Koppelvlak Endpoints Beveiliging Herleidbaarheid Pagina 3 van 38

4 6 Informatie-uitwisseling: standaard uitwisselingsformaat Inleiding StUF berichtenstandaard StUF protocolbindingen StUF horizontale sectormodellen StUF verticale sectormodellen Architectuurkeuze standaard informatie-uitwisseling Informatie-uitwisseling: e-overheid bouwstenen Beschikbare bouwstenen Diginetwerk Digikoppeling Digipoort Architectuurkeuze generieke bouwstenen voor informatie-uitwisseling Bijlage A: Informatie-uitwisselingsmodel uitgebreid Bijlage B: PKIoverheid certificaten Pagina 4 van 38

5 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. # Referentie Document 1 Afkortingen en begrippen IenM - Standaard Platform - Afkortingen en begrippen v1.0.docx 2 SP IMEA - Katern - Standaard Platform - v1.0.docx 3 Aansluitvoorwaarden IenM - SP Koppelingen - Eisen - v1.0.docx 1.5 Afkortingen en begrippen Zie voor een toelichting op de gehanteerde afkortingen en begrippen het document [Afkortingen en begrippen]. Pagina 5 van 38

6 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

7 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 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

8 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

9 2.4 Onderscheid externe en interne informatie-uitwisseling Bij de informatie-uitwisseling wordt onderscheid gemaakt tussen uitwisselen met interne en externe systemen 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 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

10 Figuur 4. Interne en externe systemen ontkoppelen door gebruik te maken van intern en extern koppelvlak 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

11 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

12 Figuur 6. Centraal Aansluitpunt Het Centraal Aansluitpunt biedt daarnaast nog aanvullende functionaliteit zoals het bijhouden van audit informatie 1, 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 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

13 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

14 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 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

15 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

16 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

17 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 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 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

18 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 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 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

19 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

20 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