A Package-Based Architecture for Customized GIS

Introduction

Geographic Information Systems (GISs) have migrated over the past decade, from stand-alone scientific niche applications to key parts of corporate IT infrastructures in public sector (and commercial) organizations (Longley et al, 2001). GISs provide services such as vehicle fleet tracking, spatial planning (optimal location of resources), and in general any service relying on location information as part of the context within which other information is interpreted. Corporate GISs are complex, multi-participant (cost-sharing) and multi-user computing environments complicating practical tasks such as data sharing among departments and routine system maintenance. Each of potentially thousands of users may have specific requirements based on their capacity to use the GIS, and hardware and software configuration requirements. Conventionally, system administrators install custom upgrades and extensions one workstation at a time, or offer all users the same monolithic package to be downloaded remotely. Until recently, GIS software packages were largely monolithic; although experience shows that many users exercise only a fraction of the functionality offered by a full-featured GIS, system administrators were required to install and support a full, often costly, commercial license for each and every user. In search of just the right set of functionality for particular users, two primary options have emerged: end user development (EUD) which assumes the user has software development skills (Morch, 2004) or server-side configuration of software modules, here termed packages based on the terminology common in the Java, Perl, and Python communities.

In organizations with an elevated number of users, and especially in the public sector which is extremely cost conscious, an extensible and easily-customizable GIS application solution is needed. This is possible assuming two levels of application flexibility. On one hand at administration level the system should present scalability that allows the use of existing software modules or components, and on the other hand, at user level, the user should be able to determine locally the customization, installing or updating only the parts from the kernel of the system needed to perform the work (Morch, 1997).

The component-based software development (CBSD) paradigm (Brown, 2000) is helping to bring this extensibility and flexibility to reality. In the CBSD approach new code development is minimized and system upgrades become the task of replacement of well-bounded functional units of the system. In our proposed architecture, the components are grouped into packages, defined as a functional, replaceable set of services. A package is a higher-level aggregation of functionality compared to an ActiveX component or a JavaBean. Adherence to interface standards allows acquisition of packages developed from third-party developers (Commercial off-the-shelf (COTS) or open source) and adapting them to the CBSD. These applications may be composed of a light kernel, which implements the basic functionality, and a set of independent packages offering extended functionality (commonly called plug-ins). In this case, each package implements a specific part of the GIS—data conversion, visualization, and so forth, is connected to the kernel through published interfaces in order to compose the final application desired by the user.

The architecture described here centralizes software maintenance and distribution, exploiting the existence of ubiquitous Internet infrastructure throughout the public sector (in the developed world). Conventional client/server architectures do not cope well with certain authentication and monitoring requirements. For this, the authors moved to 3-tier software architecture. A central server stores and dispatches the different packages that would compose the final application, while the middleware provides a natural place to locate the adaptive behaviour (McKinley, 2004). The client interface is through a specific HTTP browser that connects to the middleware services. System administrator takes charge of controlling the server side adapting and updating the packages to the CBDS.