The geGIS architecture is obviously perfectly in keeping with the vision reflected in the geGIS concept, which may be summed up as follows:

• Creating an ecosystem of servers for exchanging authentic source data over the Internet on an open and standard basis
• Using this ecosystem as a medium for a new generation of geowindows based on high-performance Web 2.0 technology

geGIS first and foremost involves the management and exchange of authentic source data between equal servers. geGIS operates on the basis of the fact that myriad organisations are now compelled to entrust the actual administration of their data with so-called GIS "specialists". Our basic philosophy is that every IT organisation should be able to manage and exchange its own geodata. This calls for an architecture that differs drastically from Google Maps, for example, for which solely one central data manager is available. The exchange of geodata on equal terms is possible solely via a process of standardisation, thanks to the open GIS standards of the Open Geospatial Consortium. As well as putting these standards into practice geGIS forges further ahead: the layers developed may be deployed straightaway in a public geowindow. There is also a clearly defined client-service interface to reflect the involvement of a Web 2.0 client application, as underscored by the following figure:

 

On the left-hand side of the figure there are 2 geGIS servers and another unspecified server consistent with the OGC standards, which exchange data from the central geGIS server via the server-to-server interface 1. The protocol is based on one of the standard OGC protocols (WFS for vector data, WMS for raster data) or a web service protocol (SOAP) for alphanumerical data (such as CRAB).

In the middle is the central geGIS server on which three geGIS windows are configured.

The right-hand side of the figure shows the front end of each of the three geowindows. In contrast to a standard Web application, where all data is located in the web pages, a full-function client-server interface 2 is featured here for the exchange of both geodata and alphanumerical data. This interface is based on JSON-RPC, a light-weight protocol especially designed for seamless communication with AJAX applications.

Inside geGIS

The geGIS platform has been developed as a standard 3-tier J2EE application, where the presentation layer, the business layer and the data layer are fairly strictly separated from each other, conceived as separately maintainable modules. In the case of a Web application, the presentation layer primarily covers the web pages and JavaScript code. Featuring the system's central logic, the business layer comprises a Java code on the server which is addressed via a servlet. The data layer covers the persistent media (data base, shape files) and the access logic. We will now describe each of these layers in great detail. 

The data layer

The data layer is a key component of GIS architecture. It is vital to have an abstract data model so as to be able to support geographical data in a huge variety of formats, derived from a wide spectrum of media. Details such as reading in shape files or addressing a database or external server to query a data layer may be neatly concealed behind a uniform API. Rather than reinventing the wheel, we have decided to reuse existing Java technology for geGIS. We based ourselves on the high-performance, comprehensive geotools library, an open source library using the datastore concept to process geodata at a higher layer.

The figure above illustrates the generation of the data layer. Underneath are the various data sources geGIS may draw upon: WMS and WFS servers, data base and (PostGreSQL, Oracle, ...), raster files (TIFF, GIF, JPEG, ...) and standard shape files. Each data source is addressed by a specific piece of logic, the datastore, shown in purple. The datastore translates a uniform API into the underlying medium so the developer can address all data uniformly in the business layer without worrying about the physical source.

The business layer

The geGIS application logic is concentrated in the business layer. As what is involved is a web application, the layer is addressable from outside via a web interface. geGIS stands apart from a standard web application because of the extensive use of AJAX. With a standard web application a web page is requested directly from the browser (by clicking on a link or a form button). The server then processes this request (how this happens will be considered shortly) and returns a completely new page. The procedure is different with AJAX: the user performs the same operation, but instead of calling up a new page, a so-called asynchronous request is sent (which means this happens behind the scenes, so to speak, while the user may initiate another action in the meantime) and the server returns solely a quantity of data. The requested data continues to be processed in the browser by the JavaScript logic. The key advantage for the end user is the web page does not need to be refreshed and the application therefore behaves more like a desktop application.

The figure above shows an incoming request on the left-hand side. As we said earlier, this request is sent in JSON format. The server is configured so that the JSON request reaches a JSON servlet to be converted into a command that continues to be processed by the central ApplicationController class. This class is responsible for dispatching commands to the actual application. The right-hand side of the figure shows the application is associated with a user session (which is typically provided by J2EE servlet container), so that user-specific operations, such as authorisation (granting rights on the basis of roles) and filtering (restricting geographical rights), may be undertaken.

The logic involving the creation of the window and the consultation and management of layers is chiefly provided for in the LayerManager class. A layer is an abstraction from a uniform dataset added to which is a quantity of metadata determining whether the layer is visible, editable and so on. The layer itself ultimately communicates with the data-tier via the datastore API.

The presentation layer

As geGIS is a web application the presentation layer involves a combination of HTML pages and JavaScript. The presentation layer comprises visible components or widgets and presentation logic. Extensive use is made of the Dojo Toolkit to generate the visible part. This features a set of reusable widgets and an I/O library that supports AJAX. 

The figure above offers a brief overview of the generation of the presentation layer or front end. The layout of a geowindow is portrayed on the bottom left-hand side of the figure. This comprises key widgets such as the GlobalMap, the OverviewMap, the TreeControl and the Legend. When a user performs an operation, the related user event is processed by the MapController (this applies at least for events on the map, other actions are dealt with in a similar way). Depending on the mode where the map is located, the event continues to be processed by the controller belonging to this mode (SelectController, ZoomController, etc...).

Events concerning the map, such as requesting vector objects, are processed by the LayerManager. This requests objects via the CacheManager, which first checks whether these objects are in the cache, otherwise the request is forwarded to the server in the form of a JSON command. The DataManager is responsible for this communication.