OGC column for the March, 1996 Issue of GIS World
Intergalactic
Geoprocessing Middleware
Lance McKee
Vice president, corporate communications
OGC
The
logo for this column depicts geoprocessing interoperability. Ten years
ago, the circular network backbone in this picture would
have been a straight
line, with a database server below and GIS workstations above, heralding
the promise of hierarchical client/server computing for GIS users.
Now client/server
computing is in its late adolescence and doing well, but it’s
atomizing! Not only can any of the computers in the diagram be both
client and server
to the other computers, but the software and data on and among the
computers are
being packaged in libraries of “objects” which individually
request and/or provide limited, well-defined services and/or data
across their standard
interfaces.
Network diagrams once showed lines for local and wide area networks.
Now more and more network diagrams (and distributed software architecture
diagrams)
show a cloud, sometimes with the word “intergalactic,” as in “intergalactic
software bus” and “intergalactic client/server resources.” The
cloud-connected “galaxies” include any digital computer network or
device. The cloud symbolizes a complex communication system containing the Internet
(or private networks) plus other software, largely “middleware.”
Middleware, very generally, is software that isolates its users from
the details of layers of software below it. More commonly and more
particularly, middleware
describes software that helps clients and servers communicate in
heterogeneous distributed computing environments. Middleware is in
its infancy, but
it
is growing fast, and it will reveal over the next few years why NetScape
stock
is overpriced.
Last May, when HotJava was still in beta test, a researcher attending
an OGIS Project Technical Committee meeting used Mosaic (the NetScape
precursor)
to
visit a Web page that displayed an image of Chicago. He selected
a small region and
downloaded that region’s data along with a HotJava viewing
application that enabled him to select any house lot and show an
image of the house
located on the lot. Anyone with Netscape and Java (on a MacOS, Microsoft
Windows, or
Unix/X Window System platform) could have accessed these images and
geoprocessing resources at that Web site. Pretty neat, indeed, but
just a beginning.
General interoperability whets our appetite for interoperable geoprocessing:
Get into NetScape Navigator and, under Net Search, select Alta Vista,
an index to 8 billion words held in 16 million home pages. Enter
a query string
that
contains solely the word “middleware” and in about three seconds a powerful
server will return the first ten out of 6,000 abstracts. Narrow the search with
AND, OR, NOT, and NEAR. Download and read any of the articles. Can a similarly
powerful index for spatial data (perhaps as part of FGDC’s
Clearinghouse) be far off?
It will take some work. We need a collection of middleware that will
give us a windowing user interface, access to diverse and finely
queryable spatial
databases, and access to geoprocessing tools on some of the database
servers. NetScape is
neat, but all html-based browsers are limited to a hyperlink and
scrolling page mode of operation. They have niether the innate capability
nor
the companion middleware to support the rich windowing graphics we
find so
useful. As an
example
of intergalactic geoprocessing, NetScape (even with Java) points
to the future, but it’s a pointer, and not the geoprocessing
future itself. We will be closer when we have a Java implementation
of OGIS
(likely
to be done by
OGC members)
and/or a mapping between Java and CORBA IDL, which will complete
the Java connection between your desktop and CORBA-based geodata/geoprocessing
servers.
Geodata access middleware is being defined by some GIS and database
vendors as an interface that provides a more open relationship between
*one*
geoprocessing system (with its proprietary geodata model) and multiple
database management
systems. The middleware uses the relational model in the databases
to implement storage and querying of geodata in that particular geodata
model. The products
are useful, but commercial versions don’t yet include OGIS
interfaces that will make them interoperable with other OGIS-enabled
systems.
In the OGIS Project Testbed, programmers working with pre-release versions
of OGIS are constructing interfaces to enable real-time transactions
between dissimilar
software systems. OGIS interfaces will be an essential ingredient in
all kinds of geoprocessing products, including middleware products that
will,
for example,
enable users to use precise queries to view and extract data from many
diverse OGIS-interfaced data servers, perhaps via an encyclopedic spatial
data clearinghouse.
Off the shelf and custom applications will reside on top of such middleware,
giving users just the tools they need to make use of all that on-line
geodata.
OGC and its members are building the bridge between geoprocessing
and intergalactic computing. OGC builds bridges at the human level:
vendor<>vendor, vendor<>user,
GIS community<>remote sensing community, and commercial sector<>standards
community. OGC’s OGIS Project Technical Committee builds *bridge plans*
at the technical level, specifications which OGIS Project Testbed members have
already begun to apply in building software interfaces: application<>database,
application<>middleware, GIS<>imaging, user application<>user
application, site<> site, and Information Community<>Information
Community. By these efforts, your request for a marvelous, specific
digital model of things on the Earth will come through the cloud
as you touch
your keyboard
or remote control, or as you speak to a software resource in your
dashboard or cellular phone.
###