A Package-Based Architecture for Customized GIS

A Package-Based Architecture for Customized GIS

Andrés Pazos (Universitat Jaume I, Spain), José Poveda (University of Texas, USA) and Michael Gould (Universitat Jaume I, Spain)
Copyright: © 2009 |Pages: 9
DOI: 10.4018/978-1-59140-995-3.ch039
OnDemand PDF Download:
$37.50

Abstract

In this chapter we present a package-based component architecture for the specific deployment and maintenance of public sector applications, specifically corporate Geographical Information Systems (GIS). The three-tier architecture defines a group of server-side packages, a kernel and external packages, that are dynamically requested and assembled at execution time according to the needs of individual users to produce on demand customized GIS applications. An intermediate middleware layer handles user authentication and version control. In order to demonstrate the proposed architecture, a practical prototype has been implemented using Java WebStart. This prototype demonstrates the creation of several GIS client applications, with increasing levels of functionality, and based on free software packages.
Chapter Preview
Top

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.

Key Terms in this Chapter

Graphical User Interface (GUI): The graphical user interface or GUI, provides the user with a method of interacting with the computer and its special applications, usually via a mouse or another selection device. The GUI usually includes such things as windows, an intuitive method of manipulating directories and files, and icons

Binding: Language-dependent code that allows a software library to be called from that computer language.

Middleware: Layer(s) of software between client and server processes that deliver the extra functionality behind a common set of APIs that client and server processes can invoke.

Client-Server Architecture: The term client/server was first used in the 1980s in reference to personal computers (PCs) on a network. The actual client/server model started gaining acceptance in the late 1980s. The client/server software architecture is a versatile, message-based and modular infrastructure that is intended to improve usability, flexibility, interoperability, and scalability as compared to centralized, mainframe, time sharing computing. A client is defined as a requester of services and a server is defined as the provider of services. A single machine can be both a client and a server depending on the software configuration.

Commercial Off-the-Shelf (COTS): A general term for software products that are made and available for sale or lease.

Component: In object-oriented programming and distributed object technology, a component is a reusable program building block that can be combined with other components in the same or other computers in a distributed network to form an application.

XML: XML (Extensible Markup Language) is a flexible way to create common information formats and share both the format and the data on the World Wide Web, intranets, and elsewhere.

Application Programming Interface (API): The interface to a library of language-specific subroutines, for instance a graphics library that implement higher level graphics functions.

CGIS: Corporate GIS. A Corporate Geographic Information System is a GIS defined to be used as a corporate resource by the members of an enterprise or institution.

Complete Chapter List

Search this Book:
Reset