Web based sevices (WBS)
Tom M. Strickland
Byers Engineering Company
368 Mount Zion Road
Madison, AL 35757
Abstract
Software on a “common platform” is being supplanted with remote invocation using “well
defined interfaces” for interoperability. Web Based Services (WBS), now viable for
deployment, offer capabilities such as translation, projection, generalization, analysis, and
other component services. Emerging standards define how these capabilities will become
ubiquitous within our industry. Issues on WBS discovery, interface techniques, usage costs,
and optimization still exist. WBS is presented from an abstract system concept along with
options and benefits.
Introduction:
In the past hardware could keep up with interactive users, but operations to translate and
manipulate data ran in batch at low priority or off-shift to avoid impacts to users. Hardware
was expensive per user. As a result clients were forced to choose a software vendor and one
version of this software for all users of the data. Software, especially graphics (GIS, AM/FM,
or CAD) was chosen based on compilation of requirements from all users, followed by
issuance of an RFP to identify a package that met all (or most) of these requirements. Quite
often this “generic” software offered hundreds or thousands of commands to access
functionality that most users did not need. If one group of users needed special capabilities
not part of the corporate standard, and they could justify their needs, they typically became an
island where their data could not by used by other parts of the company and vice versa.
Over the years, we in the industry have talked of object oriented techniques and component
architectures. Hardware has evolved to the point of being able to perform in seconds what
once took hours. The network, with remote access and remote invocation, has matured to
where transparency of data location and data manipulation or processing are truly feasible. In
parallel with this, many of us have worked with standards organizations to define how
software would and should communicate and cooperate.
We are entering an age when the question “What is your graphics platform?” is much less
meaningful or important than in the past. There was a time when graphics was tough. It
required special formats, which because of variable length structures, meant it could not be
stored with the rest of the corporate data. Relational databases could not store, query, or
understand how to index this strange information. Today, thanks to the work of the OpenGIS
Consortium (OGC????) in concert with the International Standards Organization (ISO), we
have a standard for how data may be defined, queried, and accessed. We also have
communications standards based on XML for communication of the semantic content of the
data. This can also be stored with the data.
Thanks to implementation prototypes and testbeds, we have more than a standard. We have
proof that the implementations work. Some government agencies, vendors, and universities
have web pages that implement the catalogue standards, such that they offer query access to
their sites to identify data by theme or type of content and geographic extent. These
catalogues and metadata servers offer URLs that may point to other servers or within the
same device to the data. A data server can respond with data or details about data content.
A catalogue server may list more than data set metadata access. It may contain service
access. In this case the metadata defines the service provided, URL to access the service, and
the interface(s) supported. Data servers may offer capabilities such as translation, projection,
scaling, etc. It may be that you have tabular information that you would like to use embedded
information, such as an address to geocode and symbolize the data. Many of the interfaces
for these services are close to becoming standards, based on test results.
By using the discovery techniques available for catalogue access you can search for the
geospatial information you require. You may be able to locate sets of data in the format of
your software platform, in the projection you are using, and the scale you need to work with.
Odds are however that one or more of format, projection, and scale will not match your
criteria. When this happens you have multiple choices. In the past you would have requested
your software vendor update their software to provide the ability to read this format, project
from this coordinate system to your preference, conflate the various data sets together, and
maybe even offer you generalization routines to use to re-scale.
Instead today you can augment what capabilities are available within your graphics software
by using the services available from the web. In fact, rather than use your corporate graphics
software, you may simply view the data on your web browser, with plug-ins that provide
query, display, analysis, and manipulation tools.
