Het spreekt voor zich dat de architectuur van geGIS volledig in overeenstemming is met de visie die schuilt achter het geGIS concept. Deze laat zich samenvatten als volgt:

• Het oprichten van een ecosysteem van servers die authentieke brondata op een open en standaard manier uitwisselen over het Internet
• Het gebruiken van dit ecosysteem als voedingsbodem voor een nieuwe generatie geoloketten die steunen op de krachtige Web 2.0 technologie

geGIS gaat dus in eerste instantie over het beheer en de uitwisseling van authentieke brondata tussen gelijkwaardige servers. geGIS vertrekt daarbij vanuit de vaststelling dat momenteel heel wat organisaties gedwongen zijn om het feitelijke beheer van hun data af te staan aan zogenaamde GIS "specialisten". Onze basisfilosofie is dat iedere IT organisatie in staat moet zijn om zijn om zijn eigen geodata te beheren en ook de uitwisseling ervan te verzorgen. Dit vraagt om een architectuur die radicaal verschilt van die van bijvoorbeeld Google Maps , waarbij slechts 1 centrale databeheerder bestaat.

De uitwisseling van geodata op gelijke voet is slechts mogelijk door standaardisatie. Hiervoor zorgen de open GIS standaarden van het Open Geospatial Consortium . geGIS brengt deze standaarden in de praktijk maar gaat daarbij verder: de aldus uitgewisselde lagen kunnen onmiddellijk worden ingezet in een publiek geoloket. Aangezien het hier om een Web 2.0 client toepassing gaat is er bovendien een duidelijke gedefinieerde client-service interface. Onderstaand plaatje maakt dit duidelijk:

 

Links op de figuur ziet men 2 geGIS servers en een andere, niet nader benoemde server die aan de OGC standaarden voldoet. Deze wisselen data uit met de centrale geGIS server via de server-to-server interface 1.Als protocol wordt daarbij een van de standaard OGC protocollen gebruikt (WFS voor vector data, WMS voor raster data) of een web service protocol (SOAP) voor alfanumerieke gegevens (bv CRAB).

In het midden bevindt zich de centrale geGIS server waarop een drietal geGIS loketten geconfigureerd zijn.

Rechts op de figuur ziet men de front end van elk van de drie geoloketten. In tegenstelling tot een klassieke Web toepassing, waar alle data in de web pagina's vervat zit, is er hier een volwaardige client-server interface 2 die zorgt voor de uitwisseling van zowel geodata als alfanumerieke data. Deze interface is gebaseerd op JSON-RPC, een lichtgewicht protocol dat specifiek ontworpen werd om efficient te communiceren met AJAX toepassingen.

geGIS aan de binnenkant

Het geGIS platform is opgebouwd als een klassieke 3-tier J2EE toepassing. In een 3-tier toepassing zijn de presentatielaag, de businesslaag en de datalaag redelijk strikt van elkaar gescheiden en als afzonderlijke onderhoudbare modules opgevat. De presentatielaag bestaat voor een Web toepassing voornamelijk uit web pagina's en javascript code. De businesslaag bevat de centrale logica van het systeem en bestaat uit Java code op de server die via een servlet wordt aangesproken. De datalaag omvat de persistente media (databank, shape bestanden) en de toegangslogica ervan. We zullen nu elk van deze lagen meer in detail beschrijven.

De datalaag

In een GIS architectuur neemt de datalaag een centrale plaats in. Om geografische data van de meest uiteenlopende formaten en afkomstig uit de meest diverse media te kunnen ondersteunen is het van groot belang om in een abstract datamodel te voorzien. Details zoals het inlezen van shape bestanden of het aanspreken van een databank of externe server om een datalaag te ondervragen kunnen dan netjes achter een uniforme API verborgen worden. Liever dan het wiel opnieuw uit te vinden, hebben we voor geGIS gekozen om reeds bestaande Java technologie te hergebruiken. We hebben ons gebaseerd op de zeer krachtige en uitgebreide geotools bibliotheek, een open source bibliotheek die het concept van een datastore hanteert om geodata op een hoger niveau te behandelen.

Bovenstaande figuur illustreert de opbouw van de datalaag. Onderaan bevinden zich de diverse databronnen waaruit geGIS kan putten: WMS en WFS servers, databanken (PostGreSQL, Oracle, ...), raster bestanden (TIFF, GIF, JPEG, ...) en klassieke shape bestanden. Elke databron wordt aangesproken door een specifiek stuk logica, de datastore , die in het paars weergegeven is. Deze datastore zorgt voor de vertaling van een uniforme API naar het onderliggende medium toe, zodat de ontwikkelaar in de businesslaag alle data op een uniforme manier kan aanspreken, zonder zich om de fysische bron te bekommeren.

De businesslaag

De toepassingslogica van geGIS zit geconcentreerd in de businesslaag. Aangezien het om een webtoepassing gaat is deze laag aanspreekbaar van buitenaf door een web interface. Wat geGIS daarbij onderscheidt van een klassieke webtoepassing, is het uitvoerig gebruik van AJAX. Bij een klassieke web toepassing vraagt men rechtstreeks een webpagina aan vanuit de browser (door bv. op een link of een formulierknop te klikken). De server handelt dan deze aanvraag af (hoe dit gebeurt zullen we straks bespreken) en stuurt een volledige nieuwe pagina terug. Bij AJAX is dit anders: de gebruiker voert wel dezelfde handeling uit, maar dit leidt niet tot het opvragen van een nieuwe pagina! In de plaats daarvan wordt een zogenaamd asynchroon request gestuurd (dit betekent dat dit als het ware achter de schermen gebeurt, en de gebruiker ondertussen reeds een andere actie kan ondernemen) en de server stuurt enkel een hoeveelheid data terug. De opgevraagde data wordt dan in de browser verder verwerkt door de javascript logica. Voor de eindgebruiker is het grote voordeel dat er geen heropfrissing van de webpagina nodig is en de toepassing zich dus meer gedraagt als een desktop toepassing.

Op bovenstaande figuur zien we links bovenaan een aankomend request. Zoals reeds vermeld wordt dit request in JSON formaat opgestuurd. De server is zodanig geconfigureerd dat het JSON request op een JSON servlet terechtkomt. De servlet zorgt voor de omvorming van het request naar een commando dat dan verder verwerkt wordt door de centrale ApplicationController klasse. Deze klasse is verantwoordelijk voor de dispatching van commando's naar de eigenlijke applicatie. Zoals men rechts kan zien is de applicatie geassocieerd met een gebruikerssessie (dit is iets wat standaard voorzien wordt door de J2EE servlet container), waardoor men gebruikersspecifieke zaken zoals authorisatie (toekennen van rechten op basis van rollen) en filtering (beperken van de geografische rechten) kan invoeren.

De logica die te maken heeft met de opbouw van het loket en het consulteren en beheren van lagen zit hoofdzakelijk vervat in de LayerManager klasse. Een laag is een abstractie van een uniforme dataset met daaraan toegevoegd een hoeveelheid metadata die bepaalt of de laag zichtbaar, editeerbaar, enz... is. De laag zelf communiceert uiteindelijk met de data-tier via de datastore API.

De presentatielaag

Aangezien geGIS een webtoepassing is bestaat de presentatielaag uit een combinatie van HTML pagina's en javascript. De presentatielaag bestaat uit zichtbare componenten of widgets en presentatielogica. Voor de opbouw van het zichtbare gedeelte werd uitvoerig gebruik gemaakt van de Dojo Toolkit . Deze bevat een set van herbruikbare widgets en een I/O bibliotheek die AJAX ondersteunt.

Bovenstaande figuur geeft een kort overzicht van de opbouw van de presentatielaag of front end. Links onderaan staat de layout geschetst van een geoloket. Dit omvat belangrijke widgets zoals de kaart (GlobalMap), het overzichtskaartje (OverviewMap), de boomstructuur (TreeControl) en de legende (Legend). Wanneer de gebruiker een actie onderneemt wordt het bijhorende user event verwerkt door de MapController (dit geldt tenminste voor events op de kaart, andere acties worden op een gelijkaardige manier afgehandeld). Afhankelijk van de modus waarin de kaart zich bevindt, wordt het event verder afgehandeld door de bij deze modus horende controller (SelectController, ZoomController, enz...). Events die met de kaart te maken hebben, zoals het opvragen van vectorobjecten, worden door de LayerManager afgehandeld. Deze vraagt de objecten aan via de CacheManager, die eerst nagaat of deze objecten al in de cache aanwezig zijn. Indien dit niet het geval is wordt de aanvraag verder doorgestuurd naar de server in de vorm van een JSON commando. Voor deze communicatie is de DataManager verantwoordelijk.