Netwerkarchitectuur koppelvlakken/interfaces

De netwerk architectuur beschrijft welke typen gegevensuitwisseling gerealiseerd worden met welke technische (netwerk)componenten.
Communicatie in de verschillende koppelvlakken tussen klanten en het WVP wordt gestandaardiseerd door inzet van twee systeemintegratiepatronen: file-transfer en messaging

File Transfer

Een belangrijke bron voor gegevens in het WVP zijn de beoordelingsresultaten met bijbehorende documenten uit het WBI. Het formaat van de bestanden is divers, maar wordt beperkt tot een aantal formaten waarvan SQLite (met SpatiaLite extensie) de belangrijkste is. De gegevens uit het WBI kunnen alleen aangeboden worden met behulp van file-transfer. Er is hier vooralsnog geen ander kanaal beschikbaar.
Datasets worden vanuit het WBI naar het WVP gestuurd door een file transfer koppelvlak waarbij de beschikbaarheid van files via een bericht wordt aangegeven.

Request – Reply

Als een service een andere service aanroept en een antwoord terug verwacht, spreken we van een Request-Reply pattern. Hierin worden het request en reply over een eigen channel verstuurd. Het request kan hierin zowel point-to-point zijn, als publish-subscribe.
De implementatie van dit pattern kan zowel synchroon (webservice), als asynchroon (Message Que) zijn. Biede zijn toegestaan of maken we hierin een (nadere) keuze?Beide zijn toegestaan, maar we hebben een voorkeur voor webservice. Maar ik verwacht dat dit niet altijd te realiseren is.
Het request-reply koppelvlak wordt gebruikt voor het berichtenverkeer tussen WVP en klant.
Keringbeheerders kunnen asynchroon berichten naar het WVP sturen met de mededeling dat nieuwe data klaar staat.

Systeemcontext en koppelvlakken

In het WVP moeten een aantal koppelvlakken/interfaces naar verschillende gebruikers en/of systemen gerealiseerd worden. De schets van de Systeemcontext in § 3.3 geeft een overzicht van deze interfaces. Onderstaande lijst geeft een (technische) beschrijving van de interfaces. (de nummering van de interfaces verwijst naar deze systeemcontext). De uitwisseling van gegevens naar en van het WVP is gebaseerd op de Open Standaarden comply-or-explain lijst. Per interface is, voor zover bekend, het gebruikte uitwisselformaat genoemd.

Upload Beoordelingsgegevens (interface 1)

Datastroom: Alle resultaten van de verschillende faalmechanismen (sommen en toetsoordelen) worden per dijkvak (= deel van het dijktraject) verzameld in Ringtoets. Ringtoets gebruikt voor de opslag en verwerking van gegevens een SQLite database (met spatial-extensie). Deze SQLite-database, gecombineerd met aanvullende beoordelingsgegevens, moet met behulp van een upload-mechanisme in een (per keringbeheerder) private data-store geplaatst kunnen worden.

Requirements:

• de webinterface biedt de mogelijkheid om meerdere bestanden als 'set' (per dijkvak/dijktraject) tegelijkertijd te uploaden.
• Voor de traceerbaarheid van de gegevens blijven de metagegevens van de 'set' beschikbaar en opvraagbaar
• Het upload-mechanisme moet meerdere uploads simultaan kunnen verwerken.

Technische specificaties:

• omvang dataverkeer: nog onbekend, maar kan omvangrijk worden
• frequentie van gebruik: onbekend, met waarschijnlijk periodieke pieken
• gebruikers: keringbeheerder

Protocol stack: Request/response en File-transfer

Uitwisselformaat: SQLite (het WBI is geen web-applicatie en kent geen standaard uitwisselformaat. Het gebruikt intern SQLite als opslag. Het WVP gebruikt deze SQLite-bestanden in zijn geheel), XLS/CSV, XML
Functionaliteit:

• • De Keringbeheerder krijgt een Private Data-store toegewezen waar hij zijn datasets kan bewaren.
  • De webinterface heeft een pagina waarin de keringbeheerder zijn datasets kan samenstellen
  • Deze pagina bevat ook de mogelijkheid om aan de dataset een 'Veiligheidsoordeel' toe te voegen. In concept is dat een (vrije) tekstbericht dat gelinkt wordt aan de dataset.
  • Keringbeheerder 'request' een upload van dataset, het WVP start een file-transfer (pull)
  • Gegevens blijven als set bij elkaar (hoeft niet fysiek)
  • De beoordelingsgegevens worden aangeleverd in de vorm van een SQLite/SpatiaLite bestand.
  • SQLite is serverless, dat betekent dat het WVP de IO op de database regelt. Dit vraagt extra aandacht bij de ontwikkeling van de applicatie met betrekking tot geheugengebruik.
  • De geuploade data wordt in twee slagen gevalideerd:
    • De eerste validatie (klopt de set als geheel) vindt real-time plaats, zodat de beheerder direct terugkoppeling krijgt als er fouten in de upload zit.
    • Bij een geslaagde upload naar de private data-store van de beheerder wordt een tweede validatie gestart. Aangezien dit enige tijd kan duren moet dit ook asynchroon verwerkt kunnen worden.
    • De applicatie leest periodiek de geuploade gegevens en gaat deze verwerken. In de tweede slag vindt onder andere validatie tegen de aquo-standaardDe leverancier/projectteam moet er rekening mee houden dat technische uitwisselformaten als RfC op de Aquo-standaard worden ingediend. In het acceptatieproces van deze RfC's kunnen uitwisselformaten mogelijk nog wijzigen...Toegevoegd (xsd) plaats.
    • Wanneer dit allemaal goed is gegaan worden gegevens geïmporteerd in de database.
    • In de import blijft de relatie met de bronbestanden in de private data-store gehandhaafd.
    • Als dit proces is afgerond krijgt de gebruikeraangezien het rimair gaat om communicatie tussen keringbeheerder en ILT verstaan we deze beide onder 'gebruiker'?Aangevulds (Keringbeheerder en ILT) een bericht

NB. technische uitwisselformaten worden als RfC op de Aquo-standaard ingediend. In het acceptatieproces van deze RfC's kunnen uitwisselformaten mogelijk nog wijzigen.

Aanleveren NBPW aan WBI (interface 2)

Datastroom: Het WVP levert NBPW-dijktrajecten (d.i. liggingsgegevens met norm) aan voor het WBI.
Requirements: Beschikbaar stellen van dijktraject per keringbeheerder
Technische specificaties:

• omvang dataverkeer: gering

• frequentie van gebruik: gering

• gebruikers: keringbeheerder

Protocol stack: Web Service (WFS)
Uitwisselformaat: GML
Functionaliteit: Het WVP levert dijktrajecten per keringbeheerder.

• In een Dijktraject zijn ligginggegevens van keringen samengevoegd met norm.
• Het WVP is voor WBI de enige toegang voor deze gegevens.
• Het WVP levert de dijktrajecten als service (WFS)
• Levering van dijktraject aan keringbeheerder is selectie
• De dijktrajecten bestaan minimaal uit: uniek ID, versie gegevens, geometrie
• De dijktrajecten worden in een GIS van de keringbeheerder opgeknipt in vakken per faalmechanisme.
• De herleidbaarheid naar het gebruikte Dijktraject wordt bij opknipping in toetsvakken gehandhaafd (door bijv. overerving van het ID van het Dijktraject).

NB. technische uitwisselformaten worden als RfC op de Aquo-standaard ingediend. In het acceptatieproces van deze RfC's kunnen uitwisselformaten mogelijk nog wijzigen.

Terugmeldingen van WVP naar keringbeheerders (interface 3)

Datastroom: het proces rondom aanleveren van beoordelingsgegevens wordt ondersteunt met berichten. Dit kunnen service-berichten zijn in de website (zoals: upload geslaagd, bestanden gevalideerd) of email berichten (zoals "beoordelingsgevens goedgekeurd door ILT")
Requirements: alle berichten worden opgeslagen en moeten herleidbaar zijn.
Technische specificaties:

• omvang dataverkeer: gering
• frequentie van gebruik:
• gebruikers: keringbeheerder:

Protocol stack: Request/response
Uitwisselformaat: nog onbepaald (mime, json, xml)
Functionaliteit:

Liggingsgegevens Keringen en CDL (interface 4)

Datastroom: Aanleveren van de liggingsgegevens om de NBPW te kunnen samenstellen
Requirements: Een voorziening voor de opslag van (verschillende versies van) de aangeleverde liggingsgegevens en de norm.
NB. In de toekomst gaat de aanlevering van liggingsgegevens via de CDL (Centrale Distributie Laag) loopt. In Increment 1 moeten liggingsgegevens wel aan het WVP aangeleverd kunnen worden, maar de interface loopt nog niet via de CDL. In de modulaire opbouw van zowel CDL als WVP wordt rekening gehouden met deze toekomstige interface.
Technische specificaties:

• omvang dataverkeer: gering
• frequentie van gebruik: niet frequent
• gebruikers: keringbeheerder

Protocol stack: Web Service, WMS, eventueel WFS-t
Uitwisselformaat: nog onbepaald
Functionaliteit:

• keringbeheerders kunnen op basis van een OGC webservice en/of een upload van een GIS-bestand (shapefile) de ligging van de primaire waterkeringen aanleveren aan het WVP
• Validatie van aangeleverde liggingsgegevens op basis van het uitwisselformaat (syntactische validatie) en controle van topologische consistentie, waarbij de resultaten van de validatie worden gelogd en terug gemeld
• Notificatie voor de (functioneel) beheerder van het WVP dat (nieuwe) liggingsgegevens zijn aangeleverd
• Assemblage van de liggingsgegevens (waterkeringen en kunstwerken) tot een landelijk beeld
• Versioning voor aangeleverde liggingsgegevens, waarbij alle leveringen zijn/worden gelogd en wijzigingen in versies onderling traceerbaar zijn.

Aanmelding aan HWBP van Keringbeheerders naar WVP (interface 5)

Datastroom: Invoeren/wijzigen versterkingsprojecten (aanmelden)
Requirements: Webform
Technische specificaties:

• omvang dataverkeer: gering
• frequentie van gebruik: niet frequent
• gebruikers: keringbeheerder

Protocol stack: Web Service, WMS, eventueel WFS-t
Uitwisselformaat: nog onbepaald
Functionaliteit:

• Via het WVP aanmelden (middels e-formulier(en)Zijn er nog specifieke (technsiche) eisen voor dergelijke e-formulieren van toepassing?) van versterkingsprojecten met de gegevens van de bij het project behorende dijkvak(ken) en/of kunstwerk(en).
• De volgende gegevens moeten bij de aanmelding tenminste kunnen worden opgevoerd:
  • (1) Projectgegevens (naam, projectnummer etc.),
  • (2) Beschrijving van te versterken dijkvakken en/of kunstwerken,
  • (3) Beoordelingsresultaten > "koppelen" (veiligheidsoordeel op traject en vakniveau),
  • (4) Detailgegevens/parameters (per dijkvak) t.b.v. bepalen urgentie en kosten door HWBP
• Bij de aanmelding worden de in het WVP beschikbare gegevens van de Nationale basisbestanden en de beoordelingsgegevens maximaal hergebruikt.
• De gegevens die de keringbeheerder via het WVP aanlevert worden opgeslagen en gelogd, zodat deze (in een later stadium) kunnen worden gewijzigd, aangevuld en getraceerd (wie heeft wanneer welke gegevens i.k.v. de aanmelding ingevoerd).
• Een deels ingevulde aanmelding (e-formulier) moet kunnen worden bewaard en/of opgevraagd/hersteld (bij een externe verstoring, zoals het uitvallen van de internetverbinding).

Voortgang Versterkingsprojecten (interface 6)

Datastroom: Opvragen voortgang versterkingsprojecten
Requirements: Voor deze interface wordt in Increment 1 een informatieanalyse uitgevoerd
Technische specificaties:

• omvang dataverkeer: gering
• frequentie van gebruik: niet frequent
• gebruikers: keringbeheerder

Protocol stack: onbekend
Uitwisselformaat: nog onbepaald (mime, json, xml)
Functionaliteit:

Landelijke rapportage beoordelen en versterken (interface 7)

Datastroom: Het WVP is de enige plaats waar zowel beoordelingsgegevensniet in lijn met definities elders; toetsoordelen zijn ook toetsgegevens...gewijizgd (met veiligheidsoordelen), rijksoordelen en aanmeldgegevens HWBP over alle normtrajecten detail: rijksoordel is niet van de keringbeheerder...bij elkaar beschikbaar zijn. Welke informatie gevraagd gaat worden is onbekend. Net zo als de rapportage-tooling van de gebruikers. Het idee is om de data op twee manieren te publiceren:

1. Via de WVP website
2. Middels een Private web API voor geautoriseerde gebruikers met toegang tot specifieke dataDit is in lijn met wat hierover in paragraaf 1.1 is beschreven "een dashboard met een geïntegreerde en interactieve kaartviewer"?aangevuld.

Requirements: Het dashboard moet responsive zijn, de kaartviewer moet basis gis-functionaliteit bevatten (zoomen, pannen, lagen selecteren, infoteksten) en geïntegreerd zijn met andere onderdelen van het dashboard, zoals grafieken en tekstblokken
Technische specificaties:

• omvang dataverkeer:
• frequentie van gebruik: onbekend
• gebruikers: divers

Protocol stack: Web Services, WMS
Uitwisselformaat: nog onbepaald
Functionaliteit:

• Dashboard met een geïntegreerde en interactieve kaartviewerZoals benoemd in paragraaf 1.1
• Toegang van specifieke datasets m.b.v. een API landelijk beeld (verzamelde gegevens van alle bronhouders) van de beoordelingsresultaten, aanmeldgegevens HWBP en programmaoverzicht HWBP.

NB. Via interface 7 worden ook het landelijke beeld van de liggingsgegevens primaire keringen vanuit het WVP aan DGRW aangeleverd

Aanleveren Normen vanuit DGRW aan het WVP (interface 8)

Datastroom: Het DGRW levert 'normen' aan het WVP. De normen worden toegevoegd aan het geaggregeerd beeld van de primaire keringen. Dit is het NBPW.
Requirements:
Technische specificaties:

• omvang dataverkeer: gering
• frequentie van gebruik: niet frequent
• gebruikers: keringbeheerder

Protocol stack: Web Service (WFS)Voor aanlevering van liggingsgegevens van keringbeheerder -> WVP ook shapefiles?!Zie vorge opm
Uitwisselformaat: GML
Functionaliteit: Het NBPW wordt als basisbestand/dataset opgenomen in het WVP.
NB. De assemblage van NBPW vindt buiten het WVP plaats. Het WVP fungeert hier alleen als portal.

Beoordelingsresultaten van WVP naar ILT (interface 9)

Datastroom: Nadat Beoordelingsgegevens zijn geüpload en gevalideerd en de Keringbeheerder daarvan op de hoogte is gesteld, krijgt hij in het WVP de mogelijkheid om het ILT toegang te geven tot de beoordelingsresultaten incl. veiligheidsoordeel. Het ILT kan (met behulp van een selectie) beoordelingsgegevens van één of meerdere beheerders raadplegen en/of downloaden.
Requirements:

• Keringbeheerder kan status van beoordelingsgegevens veranderen
• Keringbeheerder kan het ILT read-only toegang geven tot bepaalde versies van de datasets
• 'Read only' data toegang voor het ILT naar de Private data-storesDeze snap ik niet.Naar welke Private data-stores? Of krijgt ILT een eigen data-store in het WVP (wellicht logisch).Is het zo duidlijker? van de keringbeheerders voor het inzien van beoordelingsgegevens

Technische specificaties:

• omvang dataverkeer:
• frequentie van gebruik: niet frequent
• gebruikers: ILT

Protocol stack: Web Service
Uitwisselformaat: nog onbepaald (waarschijnlijk XML)
Functionaliteit:
Het WVP moet functionaliteit hebben om de SQLite bestanden te kunnen inzien.

Rijksoordeel van ILT naar WVP (interface 10)

Datastroom: De dataset 'rijksoordeel' voor de betreffende beoordeling van de betreffende keringbeheerder is actueel in WVP en kan, indien definitief, door de keringbeheerder worden gebruikt voor aanmelden van HWBP-projecten
Requirements:

• Keringbeheerder kan status van beoordelingsgegevens veranderen
• 'Read only' data toegang voor het ILT naar de Private data-stores
• Status van beoordelingsgegevens-set wordt gewijzigd. Zie opmerkingen bij interface 14.
• Melding (email) richting keringbeheerder.
• ILT voert het rijksoordeel in via het WVP
• Het Rijksoordeel, de melding naar KB en de beoordelingsgegevens-set blijven aan elkaar gekoppeld

Technische specificaties: In mijn beleving wordt dit een webinterface (webfor ulier) in het WVP.Anders gezegd: ILT voert het rijksoordeel in via het WVP.

• omvang dataverkeer: gering
• frequentie van gebruik: niet frequent
• gebruikers: ILT

Protocol stack: Request/response, Web Service
Uitwisselformaat: nog onbepaald (waarschijnlijk XML)
Functionaliteit: Webformulier dat toegankelijk is voor ILT voor het invoeren van het Rijksoordeel op definitieve datasets.

Beoordelingsresultaten en aanmelding van WVP naar HWBP (interface 11)

Use case: HWBP002
Datastroom: De keringbeheerder kan zijn versterkingsproject(en) via het WVP aanmelden voor opname in de programmering van HWBP.
Requirements:

• Handmatige invoer (inclusief eenvoudige 'tekenfunctie' voor het intekenen van projectsecties)
• Parameter gestuurd webformulier (parameters zijn nog onbekend)
• Aanmelding kan alleen plaatsvinden als er een positief Rijksoordeel is
• Bij aanmelding moet eventueel een samenvatting van, of een verwijzing naar de gebruikte beoordelingsgegevens meegeleverd kunnen worden.
• Aanmeldgegevens worden opgeslagen in de WVP database.

Technische specificaties:

• omvang dataverkeer: gering
• frequentie van gebruik: niet frequent
• gebruikers: keringbeheerder

Protocol stack: Request/response, Web Service (WMS, WFS-t)
Uitwisselformaat: nog onbepaald (waarschijnlijk XML)
Functionaliteit:

• Er moet GIS-functionaliteit komen om de verbetertraject te kunnen bepalen/afbakenen en aanmelden.

Programma overzicht van HWBP naar WVP (interface 12)

Use case:
Datastroom:
Requirements: Nog nader uit te werken
Technische specificaties:

• omvang dataverkeer: gering
• frequentie van gebruik: niet frequent
• gebruikers: keringbeheerder

Protocol stack: Web Service
Functionaliteit:

Gebruik Aquo-standaard in WVP (interface 13)

Datastroom: zie §8.2 en §8.3
Requirements: De validatie van een deel van de Beoordelingsgegevens gebeurt tegen Aquo-standaard
Technische specificaties:

• omvang dataverkeer: gering
• frequentie van gebruik: niet frequent
• gebruikers:

Protocol stack: XML/GML en XSD
Functionaliteit: De validatie moet niet na de eerste fout afgebroken worden en moet voor de eindgebruiker zinvolle (of bruikbare) Nederlandstalige foutmeldingen opleveren.

Aanleveren van WVP aan PDOK (interface 14)

Datastroom: een aantal landelijke datasets waarvan het WVP beschouwd kan worden als bronhouder worden gepubliceerd via PDOK
Requirements: nog nader te specificeren
Technische specificaties:

• omvang dataverkeer: gering
• frequentie van gebruik: niet frequent
• gebruikers:

Protocol stack: Web service (WFS)
Uitwisselformaat: GML
Functionaliteit:

Gebruik referentiegegevens uit PDOK aan WVP (interface 15)

Datastroom: Voor de kaartviewer kan gebruik worden gemaakt, bijv. als onderlegger, van een aantal landelijke datasets die PDOK beschikbaar stelt.
Requirements:
Technische specificaties:

• omvang dataverkeer: gering
• frequentie van gebruik: niet frequent
• gebruikers:

Protocol stack: Web Service (WMS, WFS)
Uitwisselformaat: WMS, GML
Functionaliteit: In de WVP kaartviewer moeten de beschikbare kaartlagen te selecteren zijn.

→ Verder naar Globale gegevensopslag