ArcIMS 3.0 - An Application Developer's Perspective
By:
Andrew Waxman, Chief Technology Officer, Telemorphic Inc. (1/6/00)
ArcIMS 3.0 is the latest product from ESRI in the arena of internet mapping. It
provides a fair amount of "out of the box" functionality to allow internet neophytes
to deploy their spatial data. The production release became available in June of
2000, and many questions still exist about its capabilities. The author has
deployed two custom applications with this product for two different
organizations, and will use this paper as an opportunity to share his experiences
and observations.
ArcIMS has a complex architecture and the author might gloss over some the
details in the interest of clarity. It should be noted that any reference to a server
means a software application that responds to client software requests. For
example a web server (apache) responds to client web browser (Internet
Explorer) request for a specific web page.
Product History (Based on some fact and some speculation, but isn't it all?)
ArcIMS 3.0 appears to be the consolidation of two existing ESRI internet
technologies. The first is IMS 1.0, though never released for public sale; this
product was the software behind the ESRI data hound. This server sends
streaming binary data to ArcExplorer 1.0 (and now ArcExplorer 2.0) clients.
ArcExplorer 1.0 also allowed users to save the remotely viewed data locally to
their hard drives for later use. The other technology is MapObjects IMS.
MapObjects is an ActiveX control that allows application developers to "place
maps in their apps". ESRI developed a DLL that could be registered with a web
server, and leverage the capability of a MapObjects application. A MapObject
IMS application uses a window (or form to Visual Basic developers) on the server
machine to render a map. Next it exports the map to an image file that is then
served to a client web browser. An application could be as complex or simple as
the developer's knowledge of the rapidly evolving technologies of Cascading
Style Sheets, HTML, and JavaScript. Later versions of MapObjects IMS could
be setup as a server for ArcExplorer 1.0 clients as well. One other short-lived
ESRI internet product was ArcView IMS. This product used a similar DLL to
communicate between and an open ArcView project and a web server.
Server Architecture
The main software piece of the ArcIMS architecture is the application server,
which handles all the spatial related operations. A user wishing to deploy their
spatial data builds map services (configuration files), and registers them with the
application server for use by connector applications. The application server is a
stateless machine therefore a map service is always in the same state (layer
visibility, layer order, layer representation, etc) as when it is defined in the
configuration file. The result of this design is that clients be they web browsers or
other applications must always define the desired state in their requests. The
application server exposes three public servers to requesting clients; they are
extract, feature, and image. An extract server responds to a request by creating
a Zip file containing shapefiles, and makes it available for download. The feature
server responds to a request by delivering a binary stream of data to the
requesting client. The image server responds to a request by creating an image
file that can be displayed in a web browser. Communication between the
application server and clients are composed in ArcXML, an ESRI flavored
version of XML. Currently there are four server-side connectors that are able to
make requests to the application server; they are the ActiveX connector, the Cold
Fusion connector, the Java servlet connector, and the WMS connector.
Default Connector
The default connector for ArcIMS is the Java servlet connector. The servlet
passes ArcXML requests from a calling application, usually a web browser, onto
the application server and returns the ArcXML response. The servlet connector
is not able to process or modify the request/responses at all! It simply acts
as a conduit. All clients to the servlet connector must be able to compose and
parse valid ArcXML requests and responses. The servlet connector MUST be
used in order to deploy spatial data with the feature server. Some time in the
near future ESRI plans to release an SDK, software developer's kit, for the
servlet connector. This will allow Java developers to extend the capabilities of
the servlet, and allow more server-side processing.
(NOTE: The author is aware of AxlDOM, written by Nianwei Lui. These Java
classes DO NOT extend the servlet connector, instead they can be included in
another Java program for constructing ArcXML strings, and then call the servlet
connector.)
ActiveX Connector
The ActiveX connector is a set of COM objects that expose interfaces to the
application server. Some of the interfaces can be used to construct, pass, and
process ArcXML requests/responses to the application server, others can simply
act as a middleman like the servlet connector. The ActiveX connector offers a
lot of capabilities for people who are committed to the Microsoft platform. The
one drawback is that it is unable to take advantage of the HTML Viewer client
delivered with ArcIMS 3.0 (Client Viewers are discussed later.)
Cold Fusion Connector
The Cold Fusion connector is similar to the ActiveX connector, in that it allows for
some of the processing to be moved off the client web browser, and onto the
server, but the author has no experience with this product. Cold Fusion is
available for both the UNIX and Windows platforms.
WMS Connector
The WMS connector is a collection of additional Java classes that work with the
default servlet connector to allow ArcIMS to be compliant with the OpenGIS Web
Mapping Specification 1.0.0.
Client Architecture
ArcIMS 3.0 is delivered with two "out of the box" clients, the HTML Viewer, and
ArcExplorer 3.0. Both of these are designed to work with the Java servlet
connector.
HTML Viewer
The HTML Viewer consists of almost 10,000 lines of JavaScript code that are
able to construct and parse ArcXML requests and responses. It provides many
of the familiar map tools that allow users to interact with geospatial data within a
version 4.x web browser. The HTML Viewer can handle responses from the
image and the extract servers. Only a single image server can be displayed at
any time, and any additional functionality required must be written in JavaScript
within the context of the existing code base. The biggest drawbacks to the HTML
Viewer are: It is slow when parsing large responses during which time it does not
provide any feedback to the user that it is even doing anything; frequently the
browser simply appears to be locked. The level of interactivity for certain
operations such as measuring or selecting by shape is kludgy at best. (Each
mouse click on the map requires a complete request and response cycle to the
application server.) If the request/response cycle is broken for any reason,
usually due to user impatience while using the interactive tools or the user
presses the back or refresh buttons on the browser, then the page must be
completely reloaded. (Frequently this requires closing and restarting the web
browser.) JavaScript is not the best language for developing large complex
systems, since it is interpreted (slow), loosely typed, variable declaration is not
required, undeclared variables automatically become global, and is not uniformly
supported across all web browsers.
ArcExplorer 3.0 and the Java Viewer
ArcExplorer 3.0 is a Java application that is able to act as a client to both the
image and feature servers. When ArcExplorer 3.0 is deployed in the context of
a web page it is referred to as the Java Viewer. It can be downloaded from sites
deploying it or from ESRI directly. It is approximately 12 megabytes, and
requires the Java 1.2 run-time environment (5 megabytes) from Sun. The
advantage of ArcExplorer 3.0 is its ability to connect to a feature server. When a
connection is established all the vector data in the defined extent is downloaded
to the client. Therefore further requests to the server are no longer required
dramatically increasing client performance. ArcExplorer 3.0 can connect to
multiple image and feature servers simultaneously, although its behavior with
image servers is the same as the HTML Viewer. (Requiring a request and
response for every action.) Clients using ArcExplorer 3.0 can also display
shapefiles on their local hard drives and connect to SDE enabled relational
databases. When ArcExplorer 3.0 is deployed in a web page it is only available
for web browsers that are able to script Java 2 applets. At this time, this can only
be done in Internet Explorer 4.x+ and will not be supported by Netscape 6. A
number of methods are exposed on the applets that comprise the web page, this
provides capability for developing custom functionality. JavaScript is used to
interact with the applets, but the desired functionality must fall within the scope of
what is provided by ESRI. In this manner customizing the Java Viewer is very
similar to developing in the ArcView/Avenue paradigm, if the desired functionality
falls within the scope of the existing object model then it can be implemented
quite simply, and if not it is impossible.
A Developer's Options
As in all projects, the priorities determine the course of action. Can half the
browser community be dismissed in order to provide the more responsive Java
client? One thing to keep in mind is users who are familiar with desktop mapping
products such as ArcView, might never be satisfied with a browser-based
application. By the same token, ArcExplorer3.0 and the Java Viewer might seem
overwhelming or too map-centric to neophytes and others (like senior
management). Frequently, a one size fits all solution is acceptable to no one.
Another issue to keep in mind is future developments coming from ESRI, the
entire ArcGIS 8.1 product suite is able to be a client to ArcIMS servers, and the
same is true for MapObjects 2.1. Perhaps it might be better to wait for these
products when designing custom applications that are going to be deployed to
seasoned GIS professionals. The other issues include server operating system
and web server software.
One Developer's Opinion
First of all I do not believe that any internet based application can be successful if
it is unable to work in one of the two most popular web browsers. Therefore I do
not consider the Java Viewer to ever be an option while this is the case. It is also
my opinion that the HTML Viewer is too heavy (requires too much code and is
too slow) a client for practical deployment, more processing needs to be moved
back to the server-side. Hopefully, when it is released, the Java servlet
connector SDK will provide enough functionality to allow developers to create
robust server-side applications in a platform independent environment. Until that
time I think the best solution is to use the ActiveX connector to create a custom
server application. Such an application would be able to perform the more
complex and time consuming operations, and lighten up the client browser. With
a well designed and implemented server-side application, multiple browser
clients could be developed; a pure html form based solution for older browsers, a
frames based html solution that is similar but more responsive than the current
HTML Viewer, and finally a Java applet which would support more dynamic
interactivity.
About Telemorphic, Inc. -- Telemorphic, Inc. (Oakland, CA) provides innovative on-line mapping products
and services by leveraging rapidly convergent communications and computing
technologies (C3T) to improve functionality, reduce costs, and add value for our
customers. Through the integration of technologies such as wireless
telecommunications and internet, handheld devices, GPS, satellite remote
sensing imagery, and digital map information, we offer enhanced mobile and
desktop geospatial products and services to businesses, consumers, and
governmental/non-governmental organizations.
About Andrew Waxman -- Mr. Waxman has over seven years experience using and developing geospatial
applications. He has developed applications in Arc Macro Language (AML),
Avenue, C, Java, JavaScript, Perl, PHP, Map Basic, and Visual Basic. Mr.
Waxman has extensive experience both as a developer and user of the following
products: ArcIMS, ArcInfo, ArcView GIS, Erdas Imagine, MapInfo Professional,
Map Objects, and the ObjectFX SpatialX product suite.
(c)2001, Unauthorized distribution or reproduction of this article without the consent of The GeoCommunity and
the author is prohibited
All trademarks or service marks mentioned in this article are
property of their respective owners.
|