GeoStor - About GeoStor: Design And Architecture

This report documents the GeoStor architecture as of March 2002. It will be periodically updated to reflect the modifications and enhancements that are being implemented as research and development proceed.

The name GeoStor refers to a comprehensive, web-based geodata delivery system. At the core of this system is a massive Oracle database containing all publicly available geodata for the state of Arkansas. Each data theme (e.g. roads, streams) is represented by a main table in the database and a series of supporting tables. Each feature (e.g. a specific road segment, bridge, building, etc.) is stored as a single record in each feature table. In addition to the geographic data component, each record also stores attributes about the feature (e.g. road pavement, bridge width, building size). A key aspect of the data structure is the inclusion of metadata. Metadata about each feature class (e.g. roads, buildings) is stored in the DBMS but is also exposed to standard geographic search engines via an FGDC clearinghouse that is directly linked to the database. In addition to feature class metadata, each feature (record) also has key metadata elements that provide links back to the original sources. Access to the data can be geographic searches ("what is here"), metadata bases ("what data was prepared by agency X in 2001") or both. Finally the DBMS architecture serves as a back-end to a wide range of client applications from a variety of COTS (commercial of the shelf software) vendors, including ESRI, MapInfo, Intergraph, PCI Geomatics and others.

To provide a "user friendly" web accessible interface for users desiring to access data from GeoStor the CAST development team has created the set of Java-based applications with portions that run in a client web-browser. The central data access application is GeoSurf, described below.

GeoSurf is a Java-based product that allows the user to query and download data from GeoStor. The user can query the database with geographic and metadata constraints to find data layers of interest. These layers can then be viewed or downloaded to the user's machine. GeoSurf allows the user to specify geographic clip boundaries, projection, and data format (ArcView Shapefile, MapInfo, ESRI geodatabase, DGN, etc.) and packages the data layer as specified. GeoSurf's implementation uses a Java Applet, a collection of Java Servlets, several third party products, and (currently) some Perl scripts for glue. This document will describe the high-level architecture of GeoSurf.

GeoSurf is predominantly message-driven, consisting of a number of more-or-less autonomous software entities, each of which spends most of its time waiting around, listening for the other software entities to ask it to do something. The communication protocol is "call-response": I ask you for something and you give it to me. In creating whatever it is I've asked for, you may have to ask other entities for other things. In a few special cases, I may not want anything returned to me, but am instead simply asking you to do something. Another term for this sort of architecture is "event-driven": each entity is waiting for particular events to occur, to which it is programmed to respond with a particular action. Such an architecture is inherently modular and, consequently, easily modified and extended as requirements evolve.

As with all web applications, GeoSurf has server-side components (those which run on CAST's servers) and client-side components (those which run in a user's browser and plug-ins). The call-response paradigm holds both within the client-side and for client-server interactions. Both the server and the client side of GeoSurf contain software components developed by CAST and commercial components from third party vendors.

Figure 1 is a diagram showing all of the major components of GeoSurf and the communication paths between them. The servlets (specialized Java applications for delivering complicated web content) are shown in green. The Oracle database and various other support elements that don't interface directly to the web are shown in black. The green and black components, taken together, comprise the server-side of GeoSurf. The GeoSurf applet and its components are shown in blue. This is the client-side of GeoSurf. Communication paths between them are shown in red. User workflow is managed by the applet. Consequently, the software entities within the applet communicate with each other. Servlets, by their nature, respond to requests from clients. Each of the servlets serves a particular applet component.

Figure 1. An entity-communication diagram displaying the communication paths between all the major software entities that compose GeoSurf. The client-side entities (in blue) correspond to the visual entities presented to the user on the screen. The server-side entities (in green) support the client-side by providing interfaces to the Oracle database and shell activities (in black) necessary for GeoSurf processing. The "call-response" paradigm is clearly evident. There are exceptions. For instance, the Geographic Filter receives LocationEvents from the Locator but sends no direct response back. Architecturally, the Locator is part of the Geographic Filter. The Locator collects geographic filtering parameters from the user and passes them to the Geographic Filter but does not have any interest in what the Geographic Filter does with them. The Geographic Filter passes them back to the DataLister via a LocationEvent, thus completing another call-response loop.

Figure 2 presents three sequence diagrams showing the interactions between software entities following three different actions taken by a user. The event-driven, call-response nature of the architecture is clearly evident. The static nature of Figure 1, taken alone, is inherently unsatisfying in terms of answering questions of process. Figure 2 shows three sequence diagrams, each describing a chain of events that takes place for a given action taken by a user and his mouse: 2a) describes the sequence of events that occurs when GeoSurf is first invoked; 2b) describes a typical sequence of events occurring after a user clicks the "Geographic Filter" button of the DataLister; 2c) describes a typical sequence of events occurring after a user clicks the "Download" button of the DataLister.

The next two sections will examine the client and server side components respectively: