Ministerie van Infrastructuur en Milieu Standaard Platform - Aansluitvoorwaarden Applicaties en Componenten

Transcriptie

1 Document D-4 Ministerie van Infrastructuur en Milieu Standaard Platform - Aansluitvoorwaarden Applicaties en Componenten Versie 1.0 Datum 15 juli 2014 Status Definitief

2

3 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 Stephen Oostenbrink Pagina 3 van 26

4

5 Inhoud 1 Inleiding Identificatie Leeswijzer Doel van dit document Referenties Afkortingen Begrippen en aan applicaties Opzet applicaties Applicatie Ontwikkelen voor het Standaard Platform Scheiden van omgevingsspecifieke configuratie Databases Database wijzigingen ESB Applicatie Server (AS) containers Performance Applicaties zijn clusterbaar Applicaties zijn Java EE 6 compliant Webservices zijn stateless Versioneren Omgevingsspecifieke configuratiebestanden Aanlever formaat van artefact(en) Uitrollen Leveranciersomgeving en PKIoverheid certificaat Opzet Databases Ingebruikname Command line client Black box Ondersteuning Bijlage 1 XSD s common.xsd application-deployment-meta.xsd Pagina 5 van 26

6

7 1 Inleiding 1.1 Identificatie Dit document beschrijft de eisen die het Standaard Platform van het Ministerie van Infrastructuur en Milieu (IenM) stelt aan leveranciers zodat hun maatwerksoftware samenwerkt met het Standaard Platform. 1.2 Leeswijzer Om dit document goed te begrijpen wordt het document IMEA Katern Standaard Platform als bekend verondersteld. 1.3 Doel van dit document Het doel van dit document is het informeren van leveranciers aan welke eisen hun maatwerksoftware moet voldoen om gebruik te kunnen maken van het Standaard Platform. 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 - v0.9.docx 2 SGA IMEA - Katern - Service Gerichte Architectuur - v1.0.docx 3 SP IMEA - Katern - Standaard Platform - v1.0.docx 4 Koppelingen IMEA - Katern - ESB Koppelingen - v1.0.docx 5 Aansluitvoorwaarden IMEA - Aansluitvoorwaarden - v1.0.docx 1.5 Afkortingen In dit document worden de volgende afkortingen gehanteerd. Zie het document IenM Standaard Platform Afkortingen en begrippen [Afkortingen en begrippen]. 1.6 Begrippen Aangezien dit document voor diverse doelgroepen bedoeld is en het in algemene zin belangrijk is dat een document op een eenduidige manier geïnterpreteerd wordt, volgen hierna diverse begrippen die van belang zijn bij het lezen van dit document. Zie het document IenM Standaard Platform Afkortingen en begrippen [Afkortingen en begrippen]. Pagina 7 van 26

8 2 en aan applicaties Maatwerksoftware moet aan een aantal eisen voldoen om gebruik te maken van het Standaard Platform. Hierdoor zal de applicatie correct werken op het Standaard Platform en automatisch uitgerold worden. De eisen beschreven in dit hoofdstuk zijn gerealiseerd als referentie implementatie zodat ontwikkelaars beschikken over een werkend voorbeeld, zie hoofdstuk Opzet applicaties Een applicatie bestaat uit een front-end en de backend componenten die ontsloten worden met webservices. Deze webservices zijn altijd ontkoppeld door de ESB. OA01 OA02 OA03 OA04 OA05 Front-end: De front-end ook wel aangeduid als interactiekanaal is de gebruikersinterface die verantwoordelijk is voor het afhandelen van de gebruikersinteractie en terugkoppeling naar de gebruiker. De front-end bevat geen business logica. Business logica is onderdeel van de backend en wordt met webservices ontsloten. De front-end maakt gebruik van de backend webservices via koppelingen op de ESB. Rechtstreekse koppelingen zijn niet toegestaan. Voorbeelden van een interactiekanaal zijn mobile, app, web en desktop. Koppelingen: Een koppelvlak op de ESB. Een ESB zorgt voor ontkoppeling tussen webservice afnemende systemen en webservice aanbiedende systemen. Backend: Met backend wordt alles bedoeld dat verantwoordelijk is voor een specifiek groep functionaliteit én data. De functionaliteit van een backend wordt ontsloten via webservices. Deze webservices zijn niet direct te benaderen maar altijd via een koppeling op de ESB. De backend functionaliteit kan via webservices ook aan andere systemen dan de eigen front-end beschikbaar gesteld worden. Hierdoor wordt een eenduidig resultaat over interactiekanalen en systemen heen gegarandeerd. Gegevens: De gegevens van een applicatie ook wel aangeduid als applicatiedata staat in een database. Deze gegevens zijn alleen via de backend toegankelijk. Een applicatie kan bestaan uit verschillende componenten. Deze component worden door architectuur geïdentificeerd. De componenten kennen elk een eigen release- en beheercyclus en moeten als zelfstandige component uitgerold kunnen worden. 2.2 Applicatie AG01 AG02 De gestructureerde gegevens van een applicatie worden opgeslagen in een database. Deze gegevens zijn alleen via de backend toegankelijk. Applicaties die gebruik maken van het Standaard Platform zijn OS agnostisch. Dit betekent dat er binnen de applicaties geen aannames gedaan mogen worden over het besturingssysteem waarop het Standaard Platform draait. Denk hierbij bijvoorbeeld aan het gebruik van File.seperator in plaats van het hard coderen van een / of \ karakter. Daarnaast moeten alle bestandsverwijzingen Pagina 8 van 26

9 hoofdlettergevoelig geïmplementeerd worden, zodat bestanden ook gevonden worden op besturingssystemen die hiervan uitgaan. Een URL is een uniek adres waar op een applicatie te benaderen is. URL worden volgens de volgende systematiek opgebouwd. http(s)://<omgeving>.<applicatienaam status>.<domein>/[applicatie context] Een voorbeeld voor de actieve versie van een applicatie met context root Een voorbeeld voor de actieve versie van een applicatie zonder context root Een voorbeeld voor een nieuwe versie van een applicatie Op deze manier is het mogelijk om meerdere versies van een applicatie naast elkaar te draaien. Een URL element maakt gebruik van kleine letters. Omgeving domein applicatienaam status Omgeving waarin de applicatie actief is: dev, tst, int, acc, pre of prd. Domein waar de applicatie 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). De logische naam van de applicatie. Als deze onderdeel is van het domein dan wordt geen status opgenomen in het domein, omdat dit de actieve versie impliceert. Als de applicatienaam wordt gebruikt dan is er geen applicatiecontext. Status geeft aan of het de actieve of nieuwe versie van een applicatie betreft. applicatiecontext De context waaronder de applicatie beschikbaar is. Deze wordt niet gebruikt indien de applicatienaam wordt gebruikt. 2.3 Ontwikkelen voor het Standaard Platform Om het ontwikkelen op basis van het Standaard Platform zo eenvoudig mogelijk te maken stelt IenM een tweetal kant en klare omgevingen beschikbaar als virtuele machine (VM). Hiermee beschikt de leverancier in haar eigen omgeving over een volledig werkend Standaard Platform inclusief clustering en automatisch uitrolmechanisme. Hierdoor kan de leverancier zich richten op het ontwikkelen van de applicatie en hoeft zich niet bezig te houden met het inrichten van het platform (infrastructuur en middleware). Pagina 9 van 26

10 VM01 VM02 VM03 VM05 De leverancier dient met de VM images in eigen omgeving te testen of de applicatie correct werkt op het Standaard Platform en automatisch uitgerold kan worden. De leverancier dient de voorgeschreven Standaard Platform componenten met de gespecificeerde versies te gebruiken. Het is niet toegestaan om instellingen van Standaard Platform componenten te wijzigen, bijvoorbeeld geheugen, caching, poortnummers, databasesinstellingen en beveiligingsinstellingen. Een applicatie stelt een health service beschikbaar op basis van REST en JSON. Met deze service kan de status van alle applicatie componenten opgevraagd kunnen worden. Bijvoorbeeld: { health : { Versie : 1.3.5, Front-end : OK, } } Services : [ UserAdmin : { Status : OK, Versie : 1.0.0, Gemiddelde response tijd : 950ms, Langste response tijd : 2045ms, Kortste response tijd : 670ms, Afgesproken response tijd : 1000ms, Requests: : 1200, Errors : 12 }, Login : { } ] Database : OK, DMS : OK, Hiermee ligt de kennis van de status bij de applicatie zelf en kan in een keer een overzicht opgevraagd van de status van alle applicatie componenten. Deze informatie wordt door de monitoring gebruikt om de status van de applicatie componenten te monitoren en te waarschuwen bij afwijkingen. VM06 VM07 De health service kan informatie over een component als geheel aanleveren ( of gedetailleerde informatie zoals beschreven in VM05 ( Een applicatie dient ook een webpagina beschikbaar te stellen waarmee de health service informatie direct opgevraagd kan worden door een beheerder. Zie hoofdstuk 3 voor een verdere toelichting van de VM images. Pagina 10 van 26

11 2.4 Scheiden van omgevingsspecifieke configuratie Omgevingsspecifieke configuratie instellingen zijn instellingen die verschillen per omgeving (ONT, TST, INT, ACC, PRE en PRD). SO01 SO02 De omgevingsspecifieke instellingen worden in aparte configuratiebestanden geplaatst. Deze configuratiebestanden worden in de GR gezet. Een applicatie haalt de omgevingsspecifieke instelling op uit de GR met behulp van de ConfigurationLoader API Onderscheid vertrouwelijke en niet vertrouwelijke configuratie Bij omgevingsspecifieke configuratie instellingen wordt onderscheid gemaakt tussen vertrouwelijke en niet vertrouwelijke instellingen. Vertrouwelijke configuratie instellingen zijn parameters die vanuit informatie beveiligingsoogpunt als gevoelig worden beschouwd. Denk hierbij aan gebruikersnamen, wachtwoorden en interne IP adressen. Vertrouwelijke instellingen worden door TB beheerd en niet vertrouwelijke door FB. De ConfigurationLoader API zorgt dat vertrouwelijke en niet vertrouwelijke instellingen transparant voor de webapplicatie afgehandeld worden. VO01 Bij omgevingsspecifieke configuratie instellingen wordt onderscheid gemaakt tussen vertrouwelijke en niet vertrouwelijke instellingen die in verschillende bestanden worden opgeslagen Cachen van omgevingsspecifieke configuratie instellingen Vanuit performance oogpunt is het niet gewenst dat de omgevingsspecifieke configuratie instellingen bij elke aanroep uit de GR worden ingelezen. Om dit te voorkomen worden de omgevingsspecifieke configuratie instellingen gecached. Cachen van de omgevingsspecifieke configuratie instellingen wordt door de ConfigurationLoader API zelf geregeld. De ConfigurationLoader API zal de omgevingsspecifieke configuratie instellingen na een configureerbare periode automatisch opnieuw inlezen. Het is ook mogelijk om via de ConfigurationLoader API het opnieuw inlezen te forceren. CO01 Het is niet toegestaan om omgevingsspecifieke configuratie instellingen in de applicatie zelf te cachen in welk vorm dan ook. 2.5 Databases Applicatiedata staat in een database die in een databasecompartiment staat. Dit databasecompartiment is onderdeel van het Standaard Platform. Het Standaard Platform stelt als enige eis dat de gebruikte database door Liquibase ondersteund wordt. Pagina 11 van 26

12 DB01 DB02 De volgende databaseplatformen zijn beschikbaar: PostgreSQL, SQL Server en Oracle. De voorkeur gaat uit naar PostgreSQL dan naar SQL Server en als laatste optie Oracle. 2.6 Database wijzigingen Liquibase wordt gebruikt voor de definitie van het initiële databasestructuur en eventuele initiële gegevens. Ook wijzigingen in de databasestructuur of de gegevens en migreren van gegevens worden middels Liquibase scripts doorgevoerd. Hierdoor wordt het mogelijk om database wijzigingen als onderdeel van de applicatie te packagen en automatisch uit te voeren als onderdeel van het automatische uitrolmechanisme. DW01 DW02 DW03 DW04 Liquibase wordt gebruikt voor de definitie van het initiële databasestructuur en eventuele initiële gegevens (stamgegevens). Wijzigingen in de databasestructuur of de gegevens en migreren van gegevens worden middels Liquibase scripts doorgevoerd. Het eenmalig inladen van data mag handmatig gebeuren. Voor het terugkerend inladen van data dient de applicatie zelf voorzieningen treffen Initiëren Liquibase scripts Het uitvoeren van de Liquibase scripts wordt via de Servlet Listener geïnitieerd. Hierdoor wordt de Liquibase script als eerste actie na het starten van de webapplicatie uitgevoerd. Dit zorgt er bovendien voor dat het uitrollen van de applicatie faalt als de Liquibase scripts falen. LI01 Een applicatie stelt een Servlet Lister beschikbaar om Liquibase te initiëren Database wijzigingen zijn niet-destructief De kern van het maken van niet-destructieve wijzigingen is het opdelen van wijzigingen in zo klein mogelijke refactorings. Zo is het splitsen van een tabel een aaneenschakeling van de kleinere refactorings: toevoegen tabel en een aantal keer verplaats kolom. ND01 ND02 ND03 Het is mogelijk dat meerdere versies van dezelfde applicaties hetzelfde databaseschema gebruiken. Bij het doorvoeren van database wijzigingen met Liquibase scripts moet worden gewaarborgd dat alle gemaakt wijzigingen niet-destructief zijn, zodat verschillende versie van de applicaties blijven functioneren. Database wijzigingen zijn opgedeeld in kleine aangeschakelde refactorings. Pagina 12 van 26

13 Hieronder worden een aantal niet-destructieve database refactorings beschreven. Deze zijn gebaseerd op het boek Database Refactoring [2]. De volgende tabel geeft een lijst met mogelijke refactorings weer. Een complete lijst van refactorings is te vinden in het boek Database Refactoring [2]. Refactoring Drop Column Merge Tables Move Column Rename Column Replace One-To-Many With Associative Table Split Table Merge Columns Add Lookup Table Uitleg WSO2 DSS Bij het gebruik van Data Services Server (DSS) zijn aanvullende instructies nodig om Liquibase te gebruiken om database wijzigingen automatisch uit te rollen. Er dient een minimale webapplicatie te zijn die enkel als doel heeft de Liquibase scripts uit te voeren. De webapplicatie artefact wordt samen met het DSS artefact als applicatie artefact aangeboden en uitgerold. 2.7 ESB KE01 KE02 Het gebruik van custom mediators is alleen toegestaan in overleg met architectuur. Zie voor de overige eisen het document IenM - ESB Koppelingen - en. 2.8 Applicatie Server (AS) containers Er zijn per applicatie twee type Applicatie Server (AS) containers beschikbaar. Eén stateful en één stateless. Een stateful container houdt tussen aanroepen door sessie informatie bij en wordt voor de front-end (UI) gebruikt. De stateless container houdt geen sessie informatie bij en wordt gebruikt voor de backend en webservices 1. AS01 AS02 De front-end draait in een stateful container. Dit is een domme gebruikersinterface die geen business logica bevat. De backend draait in een stateless container. De backend bevat de business logica en ontsluit de applicatiegegevens. 1. Dit zijn de webservices die de backend functionaliteit ontsluiten. Pagina 13 van 26

14 De containers zijn geoptimaliseerd voor het doel waar deze voor dienen, o.a. door het beperken van het beschikbare geheugen. Container Geheugen Geclusterd (HA) Java EE profiel Stateful 4 GB Ja Web Stateless 1 GB Nee Full Gedeeld of dedicated Een AS container kan door een aantal applicaties gedeeld worden of dedicated zijn voor een enkele applicatie. Dit wordt per applicatie bepaald aan de hand van het verwachte gebruik, vereiste schaalbaarheid en het bedrijfsrisico bij verstoring van de dienstverlening. Een applicatie kan bestaan uit meerdere componenten. Deze componenten kunnen een AS container delen of verdeeld worden over verschillende containers. Hoe applicatie componenten worden verdeeld wordt bepaald aan de hand van het verwacht gebruik, vereiste schaalbaarheid en het bedrijfsrisico bij verstoring van de dienstverlening. GD01 GD02 De componenten van een applicatie worden in overleg met Architectuur bepaald. De deployment model van applicatie componenten wordt in overleg met Architectuur bepaald Capaciteit Het is mogelijk dat er meerdere instanties van een container type op een server draaien voor een applicatie om de verwerkingscapaciteit te vergroten. De inrichtingskeuze is afhankelijk van de benodigde capaciteitseis, vereiste schaalbaarheid en verwacht gebruik van de applicatie. CA01 Het aantal applicatie containers wordt in overleg met Architectuur bepaald. 2.9 Performance Applicaties dienen gebruik te maken van de caching mechanisme van de applicatiecontainer om te voorkomen dat de database wordt belast met veelvoorkomende verzoeken. Het SP biedt een gedistribueerde cache mechanisme dat over geclusterde containers heen werkt. PE01 PE02 Applicaties maken gebruik van caching door gebruik te maken van JPA 2 en object type (entities) zijn cache enabled. De cache periode is per object type (entity) instelbaar door een functioneel beheerder. Pagina 14 van 26

15 2.10 Applicaties zijn clusterbaar Alle Standaard Platform componenten zijn geclusterd. Een applicatie moet om kunnen gaan met een geclusterde omgeving. Een applicatie mag er niet vanuit gaan dat verschillende aanroepen door dezelfde server worden afgehandeld. Hier moet bij het ontwikkelen rekening mee gehouden worden. CL01 Een applicatie moet kunnen draaien met een geclusterde omgeving De HTTP sessie is serializable SE01 Gegevens van de front-end die in de HTTP sessie worden opgeslagen moeten serializable zijn, zodat deze tussen de containers in een cluster uitgewisseld kunnen worden Grootte van de HTTP sessie GR01 Bij clustering worden gegevens van de front-end in de HTTP sessie uitgewisseld tussen de containers in een cluster. Om dit snel en betrouwbaar te kunnen doen moet de grootte van de sessie beperkt worden tot maximaal 10MB Persisteren van gegevens Voor het persisteren van gegevens tussen verschillende aanroepen wordt gebruik gemaakt van de database, de HTTP sessie of een gedeeld bestandssysteem. PG01 PG02 Het is niet toegestaan om gegevens op het lokaal bestandssysteem op te slaan, omdat het niet gegarandeerd is dat dezelfde server een volgende aanroep afhandelt. Het bestandssysteem moet configureerbaar zijn Applicaties zijn Java EE 6 compliant EE01 Alleen features van de Java EE 6 specificatie uit het profile behorende bij het type applicatie (zie paragraaf 2.7) mogen gebruikt worden Webservices zijn stateless WS01 Een webservice is altijd stateless. Dit betekent dat binnen de webservice zelf, in de applicatiecontainer, geen state mag worden bijgehouden in een HTTP of EJB sessie. Pagina 15 van 26

16 WS02 De enige state die een webservice mag gebruiken is state uit een database of gedeeld bestandssysteem Versioneren Applicaties VA01 Applicaties worden geversioneerd conform de standaard beschreven in paragraaf ESB resources Er kunnen één of meerdere actieve productie versies van een koppeling zijn. Hierdoor kunnen afnemers van een koppeling in eigen tempo en gecontroleerd overgaan naar een nieuwe versie. Er wordt geen maximum gesteld aan het aantal actieve versies van een koppeling. Dit aantal dient tot een minimum beperkt te worden. Dit wordt gedaan door een maximum periode te hanteren dat een oude koppelvlak ondersteund wordt na het beschikbaar komen van een nieuwe versie (standaard 1 jaar). Daarnaast worden wijzigingen waar mogelijk als non breaking wijziging doorgevoerd. Het versioneren van koppelingen en de hiervoor benodigde ESB resources vereist specifieke aandacht, om het mogelijk te maken om meerdere actieve versies van een koppeling naast elkaar te draaien. De volgende regels gelden hierbij Major en minor versie MM01 MM02 MM03 MM04 Er wordt bij de ESB onderscheid gemaakt tussen de koppeling zelf (proxy) en de ondersteunende ESB resources. Een koppeling is het koppelvlak en ondersteunende ESB resources zijn (herbruikbare) functionaliteiten die door verschillende koppelingen gebruikt kunnen worden, zoals de generieke foutafhandeling sequence. Ook bij herbruikbare ESB resources, zoals de generieke foutafhandeling sequence, moet het mogelijk zijn om een nieuwe versie in gebruik te nemen zonder dat alle afhankelijk koppelingen van de voorgaande versie in één keer over moeten. Deze koppelingen kunnen door het versioneren gecontroleerd en in eigen tempo over. Ook hier geldt dat de oude versie voor een beperkt periode ondersteund wordt (standaard 1 jaar). Bij applicatiebeheer afspraken dient rekening gehouden te worden met aanpassingen door nieuwe releases van een koppelvlak en herbruikbare ESB resources. ESB resources worden geversioneerd op major en minor versie. Dit geldt in ieder geval voor de volgende resources: Proxies Pagina 16 van 26

17 Sequences Endpoints Custom mediators Resources in de GR zoals: o XSD o WSDL o XSLT o Configuratieparameters o Configuratiebestanden MM05 De identificerende naamgeving van ESB resources moeten een versieaanduiding bevatten om onderscheid te kunnen maken tussen versies. Deze ESB resources worden geversioneerd op bestandsnaam, bijvoorbeeld VoorbeeldProxy-v1_4.xml. Hierdoor is het mogelijk om versies waarvan de major- en/of minornummer verschillen gelijktijdig te draaien en testen. Het is niet wenselijk om versies, waarvan alleen het patchnummer verschilt, naast elkaar te kunnen testen. Het gaat in dit laatste geval namelijk om een actieve versie waarop een patch is doorgevoerd. In onderstaand voorbeeld maakt een proxy gebruik van een ondersteunende ESB resource (foutafhandeling sequence). <proxy xmlns=" name="bagproxy-v1_1" transports="https,http" servicegroup="nl.ienm.ca" statistics="disable" trace="disable" startonload="true"> <target> <insequence> <sequence key="foutafhandelingseq-v2_1"/> Voorbeeld 1. Proxy GR resources VG01 VG02 Resources in de GR worden van major en minor versie voorzien in de bestandsnaam. In onderstaand voorbeeld is de versie af te leiden uit de bestandsnaam: _system/governance/voorbeeldapplicatie/xsd/voorbeeld-v1_0.xsd De resources die tot dezelfde koppeling behoren worden gegroepeerd door deze in een aparte folder te zetten. Bijvoorbeeld: _system/governance/voorbeeldapplicatie/v1_0/xsd/voorbeeld-v1_0.xsd Pagina 17 van 26

18 Koppelvlak VK01 Naast het versioneren van de resources, WSDL en XSD, dient ook het koppelvlak zelf van een versie voorzien te zijn Namespace VN01 Koppelvlakken worden geversioneerd door een versienummer toe te voegen aan de namespace. De service zelf (WSDL) en de berichtstructuur (XSD) worden voorzien van een namespace waarin enkel de major versie is opgenomen. Bijvoorbeeld: nl.minienm.example.v URL s Uniform Resource Locators (URL s), bij koppelingen ook wel aangeduid als een Endpoint (EP), zijn een belangrijk onderdeel bij het versioneren van een applicatie of een koppeling. Dit geldt zowel voor webapplicaties als ook voor koppelingen die een koppelvlak op een URL beschikbaar stellen. VN02 Koppelvlakken worden geversioneerd door een versienummer toe te voegen aan de namespace. De service zelf (WSDL) en de berichtstructuur (XSD) worden voorzien van een namespace waarin enkel de major versie is opgenomen. Bijvoorbeeld: nl.minienm.example.v1. VN03 URL s van webservices voldoen aan de standaard zoals beschreven in paragraaf 5.3 Endpoints in het document IMEA Katern Service Gerichte Architectuur voor koppelingen. VN04 Bij applicaties kunnen maximaal twee versies van een applicatie gelijktijdig in een omgeving in gebruik zijn: de actieve versie en de nieuwe versie. Om dit mogelijk te maken worden er eisen gesteld aan het versioneren van de URL s. Er zijn standaard URL s zonder versienummers die naar deze twee versies wijzen. Dit wordt geregeld met behulp van een reverse proxy. Dit wordt bij het automatisch uitrollen ingesteld. Op productie is maar één standaard URL beschikbaar en deze wijst naar de actieve versie. Dit betekent dat op alle omgevingen behalve PRD getest worden door naar een specifieke URL te navigeren Koppelvlak versie VK01 Bij koppelingen is er sprake is van een major versie indien er sprake is van niet backward compatible (breaking) wijzigingen in het koppelvlak. Een koppelvlak wordt alleen op major versie geversioneerd. De minor versie wordt opgenomen in het bericht zelf. Pagina 18 van 26

19 Proxy services VP01 Het moet mogelijk zijn om meerdere versies van proxy services gelijktijdig te testen. Proxy service URL s zijn daarom geversioneerd op major en minor versienummer Webapplicaties VW01 Webapplicaties hebben als context root de naam van het software artefact, bijvoorbeeld erru Webapplicaties worden uitgerold op basis van een software artefact waar de major, minor en patch versie in de applicatienaam is opgenomen. Hierdoor draait de webapplicatie onder de context root waarin het versienummer is opgenomen. De erru war zal bijvoorbeeld beschikbaar zijn op Middels een reverse proxy wordt de actuele versie van de applicatie beschikbaar gesteld, in dit geval: en de nieuwe release als Omgevingsspecifieke configuratiebestanden OC01 OC02 OC03 OC04 De omgevingsspecifieke configuratie staat in aparte configuratiebestanden. Deze worden in de GR gezet. Het Standaard Platform biedt een standaard API (ConfigLoader) waarmee de omgevingsspecifieke configuratiebestanden ingelezen kunnen worden. Deze API zorgt ervoor, transparant voor de applicatie, dat de juiste omgevingsspecifieke configuratie wordt ingelezen afhankelijk van de omgeving (ACC, PRE, PRD). Applicaties maken gebruik van ConfigLoader om de omgevingsspecifieke instellingen op te vragen/ Een template configuratiebestand wordt bij oplevering van een applicatie meegeleverd voor zowel de vertrouwelijke als niet vertrouwelijke omgevingsspecifieke configuratie instellingen. TB en FB gebruiken deze template om de omgevingsspecifieke configuratiebestanden te maken. Indien het een aanlevering betreft van een bestaande applicatie dan dienen de wijzigingen ten opzichte van de bestaande omgevingsspecifieke configuratiebestanden aangegeven te worden. Op basis hiervan kunnen TB en FB de bestaande omgevingsspecifieke configuratiebestanden aanpassen Aanlever formaat van artefact(en) AF01 De verschillende onderdelen van een applicatie worden als package aangeleverd (applicatie artefact). Dit package is een zipbestand met de verschillende applicatie onderdelen (software artefacten) en een metadatabestand (applicationdeployment-meta.xml). Dit metadatabestand identificeert de applicatie en geeft aan naar welke Standaard Platform componenten de verschillende applicatie Pagina 19 van 26

20 onderdelen uitgerold moeten worden. Het uitrolmechanisme bepaald tevens op basis van de informatie in het metadatabestand naar welke infrastructuur de applicatie onderdelen uitgerold moeten worden. AF02 AF03 AF04 De applicatie package is omgevingsonafhankelijk en wordt as is en volledig geautomatiseerd naar de verschillende omgevingen uitgerold. De omgevingsspecifieke configuratie instellingen zorgen er voor dat de applicatie correct werkt op deze omgevingen. Het applicatie artefact wordt als zipbestand aangeleverd. In de hoofddirectory van het zipbestand staan de software artefacten waaruit de applicatie artefact bestaat en een application-deployment-meta.xml. Het metadatabestand voldoet aan de in bijlage 2 beschreven XSD. De source code en geautomatiseerde tests worden als aparte QA zip bestand meegeleverd in de applicatie package Uitrollen De GR biedt functionaliteit om applicaties automatisch uit te rollen. Met deze functionaliteit kan een applicatie automatisch en gecontroleerd door de verschillende omgevingen van een OTAP straat worden uitgerold en teruggerold. Een applicatie doorloopt alle omgevingen en eindigt uiteindelijk in de PRD omgeving. Om een applicatie van de ene omgeving naar de andere omgeving door te zetten vindt een promote plaats. Het omgekeerde gebeurt door middel van een demote. UR01 UR02 In de eigen omgeving maakt de leverancier gebruik van de beschikbaar gestelde VM images om aan te tonen dat de applicatie op het Standaard Platform draait en geautomatiseerd uitgerold kan worden. Bij het uitrollen dient in het bijzonder aandacht besteed te worden aan database wijzigingen. Het handmatig uitvoeren of terugdraaien van database wijzigingen is niet toegestaan. Pagina 20 van 26

21 3 Leveranciersomgeving Er worden een leveranciersomgeving beschikbaar gesteld aan softwareleveranciers. Deze leveranciersomgeving bestaat uit twee omgevingen die zijn ingericht conform het Standaard Platform. De leverancier gebruikt deze leveranciersomgeving om zelf te testen of een maatwerkapplicatie draait op het SP en automatisch uitgerold kan worden. Daarnaast wordt deze leveranciersomgeving gebruikt om een release van de applicatie geautomatiseerd op te leveren aan IenM. 3.1 en Om de leveranciersomgeving te gebruiken dient de leverancier te beschikken over een eigen PKIoverheid certificaat. 3.2 PKIoverheid certificaat PKI certificaten worden gebruikt om te authentiseren en autoriseren. IenM stelt self signed certificaten beschikbaar om netwerkverkeer te beveiligen tussen de eigen omgeving van de leverancier en de leveranciersomgeving voor zowel applicatie- als berichtenverkeer. Daarnaast dient de leverancier over een eigen geldige PKIoverheid certificaat te beschikken voor communicatie tussen de leveranciersomgeving en het Centraal Aansluitpunt (CA). PO01 PO02 Een leverancier dient over een eigen en geldig PKIoverheid certificaat te beschikken. IenM stelt een self signed certificaat beschikbaar aan de leverancier. De leverancier is verantwoordelijk om dit certificaat vertrouwelijk te behandelen. 3.3 Opzet De leveranciersomgeving bestaat uit twee omgevingen (TST en INT). Een leverancier maakt gebruik van deze omgevingen om aan te tonen dat de applicatie op het Standaard Platform draait en geautomatiseerd uitgerold kan worden. In de onderstaand figuur wordt het uitrolproces in de tijd weergegeven. Pagina 21 van 26