Copyright © DFC NV, K.U.Leuven R&D Divisie SADL
| Revision History | |
|---|---|
| Revision 1.0 | Document creation. First version for the October-11 release. |
MAJAS is a toolkit for the development of web-based Geographic Information Systems (GIS). Essentially, it turns the user's web browser into a small GIS system.
MAJAS is an acronym for Mapping with Asynchronous JavaScript and SVG. This acronym introduces the two fundamental technologies underpinning MAJAS: AJAX for client-server communication and SVG for graphical rendering.
This document describes MAJAS from several viewpoints:
the Use Case Viewpoint explaining the MAJAS use cases
the Logical Viewpoint that outlines its static structure
the Dynamic Viewpoint describing how MAJAS realizes its use cases.
The Component Viewpoint outlining how the various artifacts that make up MAJAS are organized
The Deployment Viewpoint outlining the deployment environment for MAJAS
MAJAS has an 3-tier architecture:
The Persistence tier is made up of one or more
Datastores.Datastores represent physical data storage that may be local or remote, and can be RDBMS systems, (shape) files, WFS/WMS servers, etc.The Application Logic tier consists of the business logic: execution of application commands, encoding of features into JSON objects for consumption by the MAJAS Presentation Tier, rendering of printable maps, etc.
The Presentation tier consists of SVG, HTML and JavaScript that jointly realise the user-interface and render the geographic features.
The Application Logic and Presentation Tiers communicate through a JSON-RPC bridge. JSON-RPC is a remote procedure call protocol where requests and responses are objects that are serialized using JSON.
TODO: create a graphic
The Use Case Viewpoint is described in the document: "gGIS_use-case-model.odt" (found: here) (in dutch).
The following diagram describes the core server-side MAJAS classes.
The GGISAction is a STRUTS action that starts a MAJAS application session for the end-user. It initialises an Application, ApplicationController and a user Session. The GGISJSONServlet The ApplicationController serves as a Front Controller for the system, receiving all requests from the MAJAS client and taking appropriate actions. The actions it can perform have been implemented using the Command pattern: each action is as an ApplicationCommand.
Each MAJAS ApplicationController is capable of handling the requests from several MAJAS Applications. See section Section 1.2, “MAJAS Application Class”. This implies that a single MAJAS deployment can be configured to provide several different MAJAS Applications.
MAJAS Applications represent GIS applications that are presented to end-users. The essential elements of an Application are the Map and the LayerManager. These classes correspond to client-side JavaScript classes of the same name (see below).
The LayerManager creates and provides access to Layers. Layers correspond to geographic feature types (data layers) and contain the information such as at what scales its geographic features will be visible, whether it is editable, and how the features will be styled. An essential service of the Layer is painting its features in SVG. This service is provided by the Layer's SvgPainter.
Layers have access to the geographic feature type through the LayerModel Interface. This interface has methods for retrieving features based on a query window (bounding box) and for updating individual features. LayerModels rely for data access in turn on the CRUDProvider Interface that abstracts from the difference of data access (see Section 1.3, “MAJAS Data Access Classes”).
From an end-user perspective, a MAJAS deployment serves many different applications. These applications are generated at system start-up from configuration documents. The diagram below presents the classes that hold this configuration information in memory.
The most important class is ApplicationCatalog. The ApplicationCatalog reads the configuration files and builds up the other Configuration objects. It als has a method to create an Application instance for a user.
The diagram below presents the core structure of the MAJAS Client.
The MapController implements most of the functionality that is available through the MAJAS User-Interface. The MapController methods will be registered as event-handlers for user-interface widgets. The MapController controls two maps (SVG Documents that are embedded in the UI HTML page). The GlobalMap is the map to which features are rendered and with which the user interacts. The OverViewMap presents the complete viewable area and show the current map extent that is active in the GlobalMap. The MapController also has a list of previous map extents (the mapViewHistory).
The MapController uses the LayerManager to control the contents of the GlobalMap. The LayerManager knows when to make data layers visible or invisible (depending on scale level), how to render features, their labels, etc. For each layer in the application, the LayerManager has a Layer object which holds the configurable metadata about the layer.
The LayerManager retrieves all data trough the CacheManager. The CacheManager holds a cache of recently retrieved vector features and raster images (the lists cachedFeatureLayers and rasterZoomLevels). For vector features the data is organized in a QuadTree structure that provides reasonably efficient retrieval of all features in a given spatial extent.
When data is not present in the cache, the CacheManager requests the data from the DataManager. Its primary function is to retrieve new raster and vector data from the MAJAS server. Data retrieval is handled through a JSON-RPC protocol using the XmlHTTP transport.
The client-side JavaScript classes have dependencies to the Dojo JavaScript toolkit.
Many of the use cases involve the execution of an operation that requires co-operation between client and server. Such operations are implemented using the command pattern. A suitable command JavaScript object is created on the client, serialized and sent to the server (using JSON-RPC) where it is deserialized into a corresponding Java command object. This object is then executed by the ApplicationController.
The following sequence diagram shows how a new application is started for an end-user.
The Struts action "GGISAction" constructs the User and Application, and JSONRPCBrige objects, and registers these in the servlet Session object. Then it forwards the client-browser to the interface.jsp page that renders an appropriate DHTML user-interface. User-interface events on the client give rise to JSON-RPC requests that are sent to the GGISJSONServlet.
Retrieval of vector data is one of the core actions of the system. Data retrieval is usually triggered by a zoom- or pan-operation on the client. The following sequence diagram shows the complete process.
When the user clicks the Zoom-out button, the event is handled by the mapController. It calculates the new mapextent, modifies the viewbox on the globalMap, and requests the to compose a new map. It is the responsability of the layerManager to ensure that the SVG view (globalMap) renders the correct features (show all features within the (new) map extent, show only layers that are visible at the (new) scale, etc.).
When the layerManagercacheManager to ensure that all its features within the new mapextent are loaded in the SVG. the cacheManager looks up which parts of the mapextent have already been retrieved. For the other parts, a data request is sent to the dataManager.
The dataManager uses the dojo.io JavaScript package to forward the request to the server. The client-server communication uses XmlHTTP as transport, and JSON-RPC as the RPC protocol. These requests are asynchronous: the dataManager registers a handler (a cacheManager method) with the request that will process the return sent by the server.
On the server-side, the request is received by the GGISJSONServlet which uses the RPCJSONBridge to execute the request on the ApplicationController.
The following component diagram presents the software source code organisation of MAJAS.
The business layer is composed of the package 'be.ggis' and several framework packages (geotools, STRUTS, JSON-RPC, and Hibernate). The 'be.ggis' packages consists of several sub-packages. The most important of which are:
application: this package contains all classes that make up a MAJAS
Application.command: this contains the
ApplicationControllerand allApplicationCommands.config: the classes that make up the configuration infrastructure (e.g.
ApplicationCatalog).data: the classes that implement the GeoTools
DataStoreinterfaces for Hibernate or WMS persistence.
The Business layer depends on a set of configuration files that hold the persistent configuration information. For each application a separate application folder exists in the 'applications' folder. The folder name is the name of the application. The two SVG documents are the empty templates for the global and the overview maps. The application.xml file contains the complete configuration for the application.
The presentation layer consists server-side of a set of JSP pages. interface.jsp is the most important of these. It renders the initial user interface. Client-side the UI is presented by means of the rendered JSP pages, and the MAJAS JavaScript library. This library relies in turn on the DOJO library.
