|
|
|
System Architecture
|
Using middleware for GIS integration and factors for evaluating technologies
David K. Eason, Consultant
Geographic Information Technology, Inc.
101 Inverness Drive East, Suite 130
Englewood, CO 80112
Voice: (303) 708-9355 x142
Fax: (303) 708-9356
email:deason@geoit.com, eason@acm.org
Gary L. Powell, Senior Consultant
Geographic Information Technology, Inc.
5185 West Del Rio Street, Chandler, AZ 85226-1944
Voice/Fax: (480) 940-4434
email:gpowell@geoit.com
Abstract
This paper defines "middleware," reviews a few examples of some major middleware
technologies, and describes factors for comparing those technologies. Middleware
enables integration of components with each other, such as adding GIS capabilities to
other enterprise information systems such as Outage Management, Customer
Information, and Enterprise Resource Planning. Middleware provides the glue that
transparently connects these systems, reducing development costs and enabling
components to change without affecting other components. Examples of middleware
technologies include DCOM, CORBA, JAVA, RPC/DCE, MQS, and XML. Each of
these technologies has different capabilities and considerations for use. Such factors can
be used to evaluate most other middleware technologies.
Introduction
- Motivation for Middleware
Geographic Information Systems have evolved from "islands of automation" to systems
that need to be integrated with a wide variety of other enterprise information systems.
These include work management, outage management, customer information, mobile
dispatch, and enterprise resource planning systems. A significant portion of the system
development part of most GIS implementations now involves establishing interfaces with
these other systems. A functional architecture diagram (Figure 1) illustrates this situation.
Figure 1. Example GIS Functional Architecture Diagram
With few systems, developers would build custom one-to-one interfaces. With many
systems, this approach becomes untenable, since each application must be altered with
every change made to the overall workflow or business structure. Using a middlewarebased
approach simplifies integrating large numbers of components; changes are
generally required only to the middleware itself, leaving the applications untouched.
Middleware thus offers a more effective and efficient approach to enterprise application
integration (EAI).
Middleware has often been selected as an integration tool for adding functionality to
legacy systems. For example, a company may decide that their mainframe customer
information system needs to be connected with a GIS for supporting new customer
service capabilities. Middleware helps this process. Middleware is also the method of
choice for developing very large systems from scratch. It allows asynchronous
evolutionary development of the different components; the system can begin useful
operation without waiting for a single component to implement a non-essential feature.
- Definition of Middleware
The purpose of middleware is to simplify the process of connecting applications or
components, including those found on different platforms across networks. Middleware
has been characterized in many ways: as the glue that holds components together, as an
insulator that protects business logic developers from complex network protocols, and as
a facilitator for reducing conflicts between platforms. It is a layer of software that can
support multiple communication protocols, multiple programming languages, and
multiple computer platforms.
In the most general sense, middleware encompasses all the technologies that support
interactions between components. In contrast to single, monolithic applications that
attempt to do almost everything, middleware-connected systems comprise many
components that offer discrete capabilities, often running on different computers with
different operating systems. Choosing and constructing appropriate middleware solutions
eases component integration and enhances scalability and maintainability. Integration,
scalability, and maintainability are three important aspects to successful information
system implementations.
- Non-Technical Challenges
We will focus here on technical characteristics of middleware solutions. Many challenges
that face middleware developers, however, are not technical. Because legacy systems are
often part of the equation, learning how to interface with the legacy systems can be a
significant challenge. Politics often play a part also, as different business units within a
company perceive interfaces with other components as a risk to their system's stability,
data integrity, or security. A solution that may be perfectly sound technically may be
politically untenable. Component interfaces may change over time, giving middleware
developers the sense that their architectures are built on sand. These types of nontechnical
issues must be given careful consideration to achieve success in all phases of a
system's life cycle.
- Selected Middleware and Paper Structure
Middleware encompasses many different concepts. It can be a programming language
that provides developers with a means to build remote interfaces. It can be a method of
specifying the nature of the data being shared between components. Finally, it can be a
shrink-wrapped product that forces component independence by completely decoupling
the interfaces between components; using an unchangeable, third-party interface scheme
and appropriate application programming interfaces (APIs) for using that scheme. More
than one middleware technology is often used concurrently in order to meet complex
system goals.
Since it is not possible to review all available middleware technologies in this paper, only
a few representative products and methods will be discussed. Each will be discussed in
terms of performance, platforms, development ease, reliability, scalability, reusability,
synchronous vs. asynchronous, and open vs. proprietary. These concepts are extensible to
all other middleware technologies.
Many factors contribute to a company's choice of middleware technologies. Some
factors, such as choice of platform, may be predetermined. Others, such as development
ease and cost, depend on in-house talent and budgetary constraints. Some of these factors
are discrete ("to deploy a Unix computer or not?") while others imply a continuum ("how
reliable is this product?"). The non-discrete factors are evaluated below according to the
authors' experience and independent trade journal research. Accompanying each factor is
a discussion of how the different middleware technologies fill that space. These details
will help managers and developers decide how to proceed with their middleware
implementations.
|
|
|
|
