Proceed to GeoCommunity Home Page

SpatialNewsGIS Data DepotGeoImaging ChannelGIS and MappingSoftwareGIS JobsGeoBids-RFPsGeoCommunity MarketplaceGIS Event Listings
HomeLoginAccountsAboutContactAdvertiseSearchFAQsForumsCartFree Newsletter

Sponsored by:

Today's News

Submit News

Feature Articles

Product Reviews


News Affiliates



Email Lists


Editor's Corner

SpatialNews Daily Newswire!
Subscribe now!

Latest Industry Headlines
Orbit GT and Geosense, South Africa, sign Reseller Agreement
TC Technology Announces MIMS 2017
Public-Private Partnership to Open Geodata Access for African Resource Development
CoreLogic Launches SkyMeasure Mobile App for Roofing Industry
TCarta Marine to Introduce Gulf of Mexico Streaming Basemap Service at Esri Petroleum Conference

Latest GeoBids-RFPs
Cartography Training-VA
A & E Services-OR
Remote Sensing-UT
Surveying and Mapping-WA
GPS Locators-MN

Recent Job Opportunities

Recent Discussions
DEM to DTM in Inroads
GZ File
LiDAR-derived DEM
space syntax
DEM data for Israel
* Telemorphic
* ArcIMS from ESRI
* Browse ArcIMS Sites
* WebMapping Channel

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.
Start a discussion about this Article

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.

Sponsored by:

For information
advertising rates
Click Here!

Copyright© 1995-2014 MindSites Group / Privacy Policy

GeoCommunity™, Wireless Developer Network™, GIS Data Depot®, and Spatial News™
including all logos and other service marks
are registered trademarks and trade communities of
MindSites Group