Non-federated ArcGIS services

Inleiding

Dit document is een vervolg op de memo uit medio 2023. Dit document probeert de huidige stand van zaken weer te geven.

Kort gezegd zijn federated ArcGIS services te beschrijven als services waarvoor de security centraal geregeld wordt via Portal for ArcGIS. Ook het beheer van deze services loopt vervolgens via Portal for ArcGIS. Dit betekent wel dat Portal for ArcGIS een hele belangrijke rol krijgt in de architectuur, en dat voorkomen moet worden dat dit een single point of failure wordt.

ArcGIS Enterprise on Kubernetes

Bij Rijkswaterstaat zal er op termijn een migratie plaatshebben richting OpenShift. Dit betekent dat het GIS platform zich zal gaan baseren op ArcGIS Enterprise on Kubernetes (k8s), en niet meer op de Windows versie van ArcGIS Enterprise zoals dat momenteel het geval is.

ArcGIS Enterprise on k8s is in principe een hele andere architectuur, gebaseerd op micro services. Dit betekent ook dat de mogelijkheid van non-federated ArcGIS Services verdwenen is. Dit is door meerdere bronnen bevestigd inmiddels, zie ook dit antwoord op het Esri community forum.

Zoals ook in dat antwoord aangegeven is, is het belangrijk om de specifieke use cases die momenteel bediend worden door de non-federated ArcGIS server oplossing helder te krijgen zodat we kunnen bekijken hoe we deze use cases vorm kunnen geven in de nieuwe architectuur. Deze zullen geformuleerd moeten worden door de belangrijkste afnemers van de non-federated ArcGIS services.

Het is overigens niet zo dat de non-federated optie (Standalone ArcGIS Server site, zie figuur hieronder) verdwijnt in de Windows gebaseerde ArcGIS Enterprise versie, daar blijft deze optie gewoon beschikbaar.

Het is overigens ook niet zo dat de beveiliging op standalone ArcGIS Server onvoldoende zou zijn. Portal for ArcGIS heeft meer opties, maar ArcGIS Server standalone kan ook voldoen aan de eisen gesteld vanuit Security By Design.

GeoWeb Modules

Een verschil tussen GeoWeb Modules en GeoWeb HTML 5.5 is dat Portal for ArcGIS een vereiste is om te kunnen verbinden met services. De items moeten ook aanwezig zijn in Portal for ArcGIS en zijn dan pas beschikbaar voor gebruik in de viewers. Dit geldt ook voor de koppeling naar Catalogue Services for the Web (CS-W), die in GeoWeb Modules niet meer beschikbaar is, er is dus geen koppeling mogelijk met het Data Register (GeoNetwork).

GeoWeb Access Control is een module om meer fine-grained access control te krijgen op ArcGIS Server (bijvoorbeeld op attribuut niveau, of op geometrie niveau). Op dit moment wordt GeoWeb Access Control nog niet gebruikt binnen het GIS platform maar er wordt wel over nagedacht. GeoWeb Access Control is ook afhankelijk van Portal for ArcGIS en werkt dus alleen voor federated ArcGIS Server services.

Conclusie

Uiteindelijk, wanneer het OpenShift platform operationeel is, zullen ArcGIS non-federated services verdwijnen in ArcGIS Enterprise for Kubernetes.

In dit licht bezien is het nodig om zo snel mogelijk de use cases helder te krijgen welke momenteel afhankelijk zijn van non-federated services, zodat we, eventueel in overleg met de leverancier, kunnen kijken naar alternatieven in de nieuwe architectuur, die functioneel gezien hetzelfde kunnen bereiken.

Ook is het belangrijk om Portal for ArcGIS niet als een single point of failure te hebben in de nieuwe (k8s) architectuur, wat nu wel het geval is in de huidige architectuur.

Het lijkt onvermijdelijk dat Portal for ArcGIS een steeds belangrijkere rol gaat spelen, en dus zal bijdragen aan de vendor lock-in, maar misschien is het mogelijk middels nog nader te formuleren constraints dit enigszins te beperken.