Spatially Enabling the Next Generation Internet


David Engen


This paper presents the results of the research done using Esri tools such as ArcIMS, MapObjects, ArcObjects, and SDE to spatially enable Web Services (GeoServices).  It will discuss the various aspects of two new Internet frameworks Microsoft’s .NET strategy, and Sun’s J2EE.  These results will then be used to help to develop the next generation of Internet Applications.


The historical way of describing the Web as a tidal wave of change, has now given way to the analogy of the Internet being an Iceberg with most of the changes occurring beneath the surface in the infrastructure.  To facilitate these underlying changes the Industry has focused on Web Services as a way to build the Next Generation Internet applications.  Jack Dangermond defines “” as an open and modular architecture that allows subsystems to be independently created and deployed in a distributed and “loosely coupled” Internet environment using standard XML protocols (1).  The goal of this paper is to prove that Web services provide the best method of achieving the goals of “”.

Web Services


Even before the Web was created, distributed applications were being built.  The two most common distributed technologies used to build applications were CORBA and DCOM.  CORBA was created by a large consortium of companies for use amongst many OS platforms, while DCOM was developed by Microsoft for their Windows platforms.  To assist in the complexity of network programming both technologies abstracted away some of the complexity by using an Interface Definition Language (IDL), CORBA had IDL, while COM/DCOM used MIDL.  The idea of a contract defining the interface between the client and the server is still carried forward today in the Web Services Model in the form of the WSDL; described later in this paper.  Any distributed applications built with either of these technologies were notoriously hard to develop, easy to break, and difficult to deploy across a heterogeneous network.

While looking for successful distributed applications note the two most successful global ubiquitous distributed applications ever built.  The World Wide Web (WWW) and e-mail provides the inspiration that Web Services is based on and uses.  Before Web Services, it was possible to build complex distributed systems built using CORBA, or DCOM but they both lack the ability to globally scale, across many different platforms using different programming languages, and be easy to use and understand.

What is it?

Unfortunately, there is no official definition of a Web Service, but there is general consensus of what it does.  For example, Sun Microsystems (SunONE) defines “a Web service exhibits the following characteristics

While IBM’s Web Services for J2EE, JSR 109 defines “for the purpose of this specification, a Web Service is defined as a component with the following characteristics


Microsoft defines “a Web Service as programmable application logic accessible using standard Internet protocols.  Web Services combine the best aspects of component-based development and the Web.  Like components, Web services represent black-box functionality that can be reused without worrying about how the service is implemented.” (7)

Overall, these three major companies, and others seem to agree that Web Services seems to be a way of enabling components across the Web.  A new Universal API with supporting technologies that allows applications to be developed using Internet based methods.  Below is a graphical depiction of the Web Services architecture, which some refer to as a Service Oriented architecture.

From a high level view, the Provider publishes their Web Services in the Registry, where the Requestor can find it.  With the details provided by the registry the Requestor is able to bind to that service offered from the Provider and access the Web Service.


The major advantage of Web Services is based on independence, not being tied to any specific implementation of the following:

Besides being a loosely coupled solution, it solves the scalability issue by relying on the existing Transport Protocols, HTTP for the Web and SMTP used for e-mail.  Another advantage of relying on existing HTTP transportation protocol is Web Services are “XML-based wire protocol, which is thus Web/firewall friendly”. (12)

Companies with Web Services Presence

The follow is a list of companies that have a Web Services presence.  The list is not extensive, but does identify the key major players, and what they offer.


Microsoft is one of the leading Web Services companies in the world today; it originally developed the SOAP spec in 1998 which it later submitted to the W3C in late 1999 and joined IBM to co-develop the SOAP v1.1.  The new MS .NET Framework and is primary development environment Visual Studio .NET have Web Services integrated into its core.  Microsoft also supports it older COM based development environment with the Soap Toolkit.  Microsoft’s first Web Services offered is “MapPoint .NET”, a good example of what competition is providing in Spatial Web Services (GeoServices).  Information about Microsoft’s Web Services can be found at


IBM is also considered to be one of the leading Web Services companies.  IBM has based their Web Services on the Java environment.  For development and testing purposes the Web Services Toolkit is used as a platform for testing new specifications, such as the new WS-Security specification.  The Websphere Studio provides its production development environment, with Websphere providing the production Application server.

IBM is also very active participant in W3C Web Services Group and has donated SOAP4J to the which is the basis for Apache’s SOAP v2.2.  IBM Web Services information can be found at

Sun Microsystems:

Sun created the Internet programming language Java in the early 90s.  Sun originally positioned their new language for web based client applications based on the applet technology, but is more prevalent today in servers using servlet technology.  Today Java enhancements are developed by the Java Community Process (JCP) where IBM has submitted the JSR 109 Web Services for J2EE.

Sun has a Java Web Services Developer Pack (Java WSDP) which is used for development purposes.  The advantage Sun has with Java is many companies such as IBM with Websphere, BEA with Weblogic, and Oracle with iAS provides a good choice of Java based production Web Services environments.  Sun Microsystems Web Services information can be found at


Systinet, formally called Idoox is a small company that provides a complete Web Applications and Services platform called WASP.  They provided one of the first implementations of a local UDDI registry free for development use called WASP UDDI.


Apache Open Software Foundation has many successful projects ranging from the http web server, to the Tomcat reference Servlet container.  It has a new project called Axis, which is a rewrite of the Apache SOAP, and can be found at  One of the advantages of Axis project is source code is published allowing developers to know exactly what is going on.


Tony Hong posted on the SOAP Builders Newsgroup about interest in starting an interoperability lab in Jan 31, 2001, at  The web site created by Tong and James Hong, also publicly lists available web services and provides various programmatic interfaces such as SOAP, UDDI, WS-Inspection, and DISCO for these services.

The various web services range from an Apache SOAP based eBay Price Watcher, to a FedEx\UPS Package Tracking service.  The reason for bringing attention to this web site is the “PlaceFinder” web service by, one of the first Spatial Web Services found within its expansive list of usable web services.

XML - The Catalyst

XML is one of the main enabler for Web Services.  For the purpose of the paper we will focus on a couple components that are critical to using and understanding Web Services.  Note, these are not the only XML based languages, for example Scalable Vector Graphics (SVG) is a new vector graphics file format based on XML that could be used to render Maps or complex mathematical models described more clearly by MathML.  All these, and more XML based languages can be found in various forms of recommendation at the W3C website at

XML Basics

The Extensible Markup Language (XML) is based on the Standard Generalized Markup Language (SGML) [ISO 8879] developed by the World Wide Web Consortium (W3C) and became a recommended standard in February 1998.  The Structure of XML documents are made up of entities in a markup format that provides the storage layout and logical structure (2).  It is the XML specification that defines the constraints and structure for a XML file.  XML can be thought of a common meta-language used to define other languages.  Tim Bray, co-editor of the XML 1.0 specification stated that “XML is the ASCII of the Future” describing the use of XML to define data being shared between other systems (3).

Unlike HTML; which is a Markup Language to describe layout of a web document, the XML language describes a document’s content.  The best way to understand this principle is to look at an example XML file.  Below is an example ArcXML request.  ArcXML is the protocol for communicating with the ArcIMS Spatial Server (4).

<?xml version=”1.0” encoding=”UTF-8” ?>

<ARCXML version = “1.1”>




                <ENVELOPE minx=”-90” miny=”10” maxx=”-10” maxy=”30” />





Code 1

Take notice that the use of <item> markup and the following <item></item> structure defined in the XML specification.  There is no definition of the <item> or how it is to be rendered.  XML doesn’t set up the <tag> set or define the grammar for the language, it provides the basis for the other XML based languages covered below to be developed.

XML Namespaces

Namespace became a W3C standard in January 1999, and was developed to provide namespaces in XML documents.  There was a “need to fully qualify XML elements and attribute names to prevent from confusing two elements that have same name but mean different things” (8).  As with most XML languages it is easier to provide an example of what a namespace is.  Below are two versions of the same fictitious XML document fragments that contain contact information for a Forest Tenure Licensee.  With the second code fragment adding the namespace constructs.




<name>John Doe</name>

Code 2

<ctc:permit xmlns:ctc=”” xmlns:ts=””>



    <ctc:name>John Doe</ctc:name>













Code 3

Notice in the second code segment the syntax to declare the namespace is “xmlns:prefix=”namespace” where the short prefix is used to declare what namespace each element or attribute belongs to.  Also notice it is in the format of a web URL.  Unfortunately people get the wrong impression that it must point to a valid address, when it only needs to be a unique identifier.  So the xmlns:ts = ”” is valid, even though Microsoft probably doesn’t have this as a valid address.  “Why namespaces?  They are there to help computer software do its job” (9).  Namespaces enable programs to parse concisely and completely define all elements of an XML file given.

XML Schema

Before XML Schema became a standard, Document Type Definition (DTD) was used to define types and provide a list of legal elements for HTML and XML documents.  The newer XML Schema can be thought of as a superset of DTD which has some advantages over DTD such as, it is a valid XML document and uses namespaces.  XML Schema became a W3C standard as of May 2, 2001.  XML Schema is a very complex specification, broken in to these 3 parts including hundreds of pages of technical specifications for each part. It’s comprised of XML Schema Part 0: Primer, XML Schema Part 1: structures and XML Schema Part 2: Datatypes.  XML Schema is sometime referred to as XSD, Microsoft actually uses .XSD for it schema file extension.

This schema can then be used to validate a group of documents based on this one schema or combined with other schemas through the use of namespaces.  To help understand XSD functionality the following is a simple schema used to define the types, structure and validates the fictional Licensee from the earlier example, Code 3.

<xsd:schema xmlns:xsd=””>

  <xsd:simpleType name = “AddressType”>

            <xsd:restriction base=”xsd:string”>

              <xsd:maxLength value=”50”/>



  <xsd:complexType name = “contactType”>


              <xsd:element name = ”name” type =”xsd:string”/>

              <xsd:element name = “address” type = “AddressType”/>

              <xsd:element name = “phone” type = “xsd:string”/>



  <xsd:simpleType name=”deciduousType”>

            <xsd:restriction base=”xsd:int”>

              <minInclusive value =”1”/>

              <maxInclusive value =”100000”/>



  <xsd:complexType name = “AACType”>


              <xsd:element name =”deciduous” type=”deciduousType”/>



<xsd:element name=”contact” type = “contactType”/>

<xsd:element name=”AAC” type =”AACType”/>


Code 4

Because this schema is a valid XML document.  “This allows any schema-aware validating parser to validate an XML document against an XSD schema and report any discrepancies.” (10)  A couple of points to take notice of the schema are:

         The use of namespace for xsd=”” allows you to short form qualifier of “<xsd:item>” referring to the official W3C schema.

         The schema has changed a lot over the course of its development, so you might see a different namespace that refers to earlier versions of the XML Schema specification.

         The contact structure is defined to be made up of a sequence of elements.

         XML schema allows you to place a restriction of how many occurrences of elements or structures.

         The address string for the contact type has being given a maximum string length of 50 chars.

         The AAC element has being defined to use a range of 1 to 100000.

         A type could be defined to include a pattern, such as one for the telephone number string of (xxx)xxx-xxxx.

Besides clarifying the type and structure for each element, XSD provides validation functionality that has traditional had been done in computer programs and applications.  This separates validation from the individual programs and associates it more closely with data for all programs that use the data.  An example of this could be a fictional schema created for a XML based shape file format that allows for any shape file to be checked against the schema, always providing a way of validating any xml based shape file by any program.

Core Web Services

In the current W3C working draft the Working Group has jointly come to agree on the following working definition for a Web Service:

A Web service is a software application identified by a URI, whose interfaces and binding are capable of being defined, described and discovered by XML artifacts and supports direct interactions with other software applications using XML based messages via internet-based protocols (11).

There is a general consensus that the Core Web Services infrastructure is comprised of SOAP, WSDL, and UDDI.


The Simple Object Access Protocol (SOAP) is based on XML and describes a messaging format for machine-to-machine communication. (13)  The Client crafts a SOAP message that the Server can understand and respond to.  The Server has a manager that listens for requests that translates the request into a form it can understand.  It then runs the correct service based on a list of services it has deployed and sends a response back to the client.  Below is a graphically depiction of the structure of a SOAP message.

         Soap Envelope             mandatory

o       It is the top element that contains the SOAP message.

         Soap Header                optional

o       Provides the ability to extend the functionality with schemas, etc.

         Soap Body                   mandatory

o       It is the actual message.

         Soap Fault                    optional

o       It is for error message handling.

As with most things is easier to show an example of a Soap Message.  Below is a fictional example SOAP request message for the Geography Network findPlace Web Service.  As stated earlier, SOAP can use any type of transport protocols.  The first two messages show the different bindings for the same soap message.

Binding with HTTP

POST /Vendors HTTP/1.1



Content-Length: nnnn


<ENV:Envelope xmlns:ENV=”” >


            <xsd:Order xmlns:xsd="" ENV:mustUnderstand="1">




            <p:findPlace xmlns:p=””>

            <arg0 xsi:type=’xsd:string’>Redlands</arg0>



                        <faultstring>Failed to Process SOAP Request</faultstring>




Code 5

Binding with SMTP

TO: <>

From: <>

Reply-To: <>

Date: FRI, 21 Jun 2002 14:00:00

Message-Id: <>

MIME-Version: 1.0

Content-Type: text/xml; charset=utf-8

Content-Transfer-Encoding: QUOTED-PRINTABLE

<ENV:Envelope xmlns:ENV=”” >


            <xsd:Order xmlns:xsd="" ENV:mustUnderstand="1">




            <p:findPlace xmlns:p=””>

            <arg0 xsi:type=’xsd:string’>Redlands</arg0>



                        <faultstring>Failed to Process SOAP Request</faultstring>




Code 6

The SOAP messages between the client and server can have two states, successful or fault.  Below is an example of both types of SOAP messages.

A successful SOAP response, using HTTP binding


HTTP/1.1 Content-Type:"text/xml"; Charset="utf-8"

Content-Length: nnnn

<ENV:Envelope xmlns:SOAP-ENV="">


            <l:FindPlaceResponse xmlns:l = "">





Code 7

A Fault Soap Message, using HTTP binding


HTTP/1.1 500 Internal Server Error

Content-Type: "text/xml"; Charset="utf-8"

Content-Length: nnnn

<ENV:Envelope xmlns:ENV="" >



                        <faultstring> Failed to Process SOAP Request </faultstring>




Code 8

Basically SOAP is a XML specification that defines the mechanism for the defining the structure of the XML documents used by the client to communicate with a server.  Not all details were covered, for complete details on the SOAP v1.1 specification refer to


Almost all distributed systems have an IDL language for describing the interface between the server and the client.  In the Web Service model it is the Web Services Definition Language (WSDL).  It’s pronounced by spelling out the letters or saying “whiz-dell” which nearly rhymes with “diesel”. (16)  The current de facto standard is a W3C Note submitted by Microsoft and IBM,  IBM’s director of e-business standards Bob Sutor predicts “WSDL will be the most widely adopted specification, to describe Web Services.  Web Services will be fundamentally WSDL based.  You have to use WSDL to describe and then build up from there.” (15)

WSDL provides a solution for the following questions that arise in using Web Services.

In most cases Toolkits and Development Environments automatically generate the WSDL for a class to be enabled as a Web Service.

This is considered the most important specification of all three Core Web Services, because it defines the interactions. Because of this importance, the topic will be covered in greater detail than the others in this paper.

A WSDL document is comprised of the following elements as defined in the WSDL Specification.

To provide an example of each of the different elements types we will look at the PlaceFinder Web Service offered by the Geography Network.  The full WSDL for the PlaceFinder Web Service file can be found at



  <schema xmlns=””

<complexType name="LocationInfo">


            <element name="matchType" nillable="true" type="string" />

            <element name="candidates" nillable="true" type="tns:ArrayOfLocation" />




Code 9

The first thing that needs to be defined is all the types used by the Web Services; you can see the types are defined by the XML Schema.  The above segment is just a small section of the PlaceFinder Service WSDL.


<message name="getVersion0SoapIn" />

<message name="getVersion0SoapOut">

<part name="Result" type="xsd:string"/>


Code 10

The actually message is protocol independent; in the above message the getVersion0SoapIn has no arguments where as the response “Result” is returned as a string.


<operation name="getVersion" parameterOrder="">

<input name="getVersion0SoapIn" message="tns:getVersion0SoapIn" />

<output name="getVersion0SoapOut" message="tns:getVersion0SoapOut" />


Code 11

Notice that you take the earlier defined messages and group them into the input-output messages for the “getVersion” service.


<portType name="PlaceFinderSoap">

<operation name="getVersion" parameterOrder="">

<input name="getVersion0SoapIn" message="tns:getVersion0SoapIn" />

<output name="getVersion0SoapOut" message="tns:getVersion0SoapOut" />



Code 12

The PortType groups all operations together.  In the FindPlace service there are three operations defined, getVersion; as above, and two findPlace with different argument lists.


<binding name="PlaceFinderSoap" type="tns:PlaceFinderSoap">

<soap:binding style="rpc" transport="" />

<operation name="getVersion">

<soap:operation soapAction="getVersion" style="rpc" />

<input name="getVersion0SoapIn">

<soap:body use="encoded" namespace="" encodingStyle="" />



Code 13

The transport binding extensions are SOAP 1.1, HTTP GET/POST and MIME.  The specification also defines a framework to develop any binding extension.  The above example is based on SOAP 1.1 binding, and a transport of HTTP.  There are two style types of SOAP bindings, Document Style and remote procedure call (RPC) based.  Basically the request and response of SOAP message for Document Style are encoded xml message, while the RPC style has input parameters and results send back in encoded response to the call; as defined in the W3C SOAP v1.1 specification, section 5.


<port name="PlaceFinderSoap" binding="tns:PlaceFinderSoap">

<soap:address location=""/>  </port>

Code 14

As you can see the port definition has a unique and specifies a single address for binding.


<definitions name="PlaceFinder" targetNamespace=


<service name=”PlaceFinder”>



Code 15

The definitions element is the root element for all WSDL documents, a place where all the namespaces are fully defined. Finally the service name is for the grouping of all ports associated with a particular service.

It is worth repeating, WSDL is considered the most important specification of all three Core Web Services, because it defines the interactions between the client and server.  It is the document that businesses will physically exchange to enable Web Services.


The Universal Description, Discovery, and Integration (UDDI) project provides the registry for Web Services and is currently composed of over 200 different companies. More information can be found at  If only a few companies were trying to manage Web Services between partners, using a registry is not very useful idea.  It is only when we scale up to the size of the Web in the number of companies and interactions, does the need for the UDDI registry arise.  The UDDI projects attempts to provide an independent open framework for describing, locating, and integrating Web Services based on existing standards, such as XML, HTTP, and SOAP.  One example of a java based free for development and usage, is the WASP UDDI Standard server, which can be found at

To help define the type information found within the registry the analogy of the telephone directory helps to describe the three major types found within a UDDI registry.

White pages

Basic contact information and identifiers about a company, including business name, address, contact information and unique identifiers such as D-U-N-S numbers or tax IDs. This information allows others to discover your web service based upon your business identification. (14)  This is the <businessEntity>.  There is also an entity <publisherAssertion> that describes a public relationship between two businesses.

Yellow pages

Information that describes a web service using different categorizations (taxonomies). This information allows others to discover your web service based upon its categorization (such as being in the manufacturing or car sales business). (14)  This is the <businessService> offered by the company.

Green pages

Technical information that describes the behaviors and supported functions of a web service hosted by your business. This information includes pointers to the grouping information of web services and where the web services are located.  (14)  This is the <bindingTemplate> and <tModel>.  The binding template contains a link to the details of how to get to the Web Service, while the tModel is a link to the actual details for the Web Service.

The UDDI registry can contain optional textual descriptions of the various entities, but its main focus to provide the links (URI) to the actual Web Service details.

The UDDI is comprised of a group of nodes that replicate the registry between themselves.  There is no authentication needed for querying for information, but you need to authenticate for adding or updating information within a registry.  You can query any node for same information, but the actually adding or updating the information is done at the same node that you where authenticated for.  One misconception of UDDI registry is they have to be public.  A group of companies can create there own private UDDI registry or create private registries of Web Services available within a Government.

To actually use the UDDI server, two APIs the Inquiry and Publishing have been specified in the Programmers API as a series of SOAP messages that the UDDI server uses.  Company’s have provide various toolkits to work with UDDI such as Sun with JAXR library that abstracts the details of the registry so it can work with other registries such as ebXML.  Systinet provide a client library that allows you to interact with the UDDI without know details of the SOAP message, and will work with any UDDI server.  Finally you could hand code the SOAP message directly to access the registry.

Frameworks and Toolkits

Microsoft .NET Framework & Visual Studio .NET

Microsoft released the .NET Framework late last year, as a next generation platform for building Web Applications and Web Services.  The ASP.NET framework serves as a platform for XML Web services in managed code.  To differentiate XML Web services from regular ASP.NET pages, XML web services uses the .asmx extension. (20) When you create an ASP.NET Web Service project in Visual Studio, it automatically creates the necessary files and references to support an XML Web Service.  To deploy an XML Web Service, you simply copying the .asmx files and any assemblies created by XML Web Service to a virtual directory on a IIS Web server.

To use a Web Service within Visual studio you simply use the “Add Web Reference”.  To use the PlaceFinder Web Service from the Geography Network add the URL

com.geographynetwork.www.PlaceFinder placeFinder = new com.geographynetwork.www.PlaceFinder();

com.geographynetwork.www.LocationInfo locInfo = placeFinder.findPlace("Redlands");

com.geographynetwork.www.Location loc = locInfo.candidates[0];

Console.Write(loc.description1 + " is located at (" + loc.x + "," + loc.y + ")");

Code 16

Above is some example console based C# code using the Web Service taken from

As you can see Microsoft has gone to great length to make it easy to create and use Web Services within their Visual Studio Development Environment.  Testing and Research were done with the Beta 1 ArcObjects Developer Kit for .NET at

MS SOAP Toolkit

The ASP.NET solution is geared to managed code, but a lot of COM based code exists today and will not be going away any time soon.  To use COM based code Microsoft provides the SOAP Toolkit.  The Toolkit includes:

-         Client side component used to invoke a Web Service defined by WSDL.

-         Server side component that maps Web services operations to COM object method calls

-         Components to process SOAP messages.

-         WSDL/WSML files generator tools.

This toolkit was used to test Web Services enhanced MapObjects COM based solutions.

Apache Axis

The Apache Axis project is a complete rewrite of the Apache SOAP, originally based on IBM’s donated Java code base from SOAP4J.  It is still in development stage, but is expected to be completed later this year.  When complete, Axis will:

It is all the above mentioned points that make it worth while to use the beta code.  Below are some simple Web Service and a client examples.  Notice that the code is clean and doesn’t contain any of the extra constructs needed to support SOAP with early versions.  It closely follows the C# example given

public class HelloServer


    public String sayHello(String name)


      System.out.println("sayHello(String name)");

      return "Hello " + name



Code 17

<%@ WebService Language="C#" Class="HelloServer" %>

using System.Web.Services;


public class HelloServer {

    [ WebMethod ]

    public string sayHello(string name) {

        return "Hello " + name;



Code 18 HelloServer.asmx

To deploy the Java class as a Web Service you simple copy the java file to the server and rename the file extension from .java to .jws and it automatically generates all the supported files such as the WSDL for the class.

IBM Web Services Toolkit

IBM provides WebSphere Studio Application Developer and WebSphere Server to provide production quality Web Services Tools.  The Web Services Toolkit is positioned as a place where IBM tests new Web Services and technologies, such as

It is this toolkit with its inclusion of new specification WS-Security, WS-Inspection and Apache Axis that testing was done with Map Objects Java Edition to test build Spatial Web Services.


One of the main reasons that Web Services is flourishing compared to the previous distributed solutions, is the promise of interoperability across a heterogeneous environment.  Unfortunately the reality of this new technology is still far from being completely interoperable.  IBM's director of e-business standards Bob Sutor believes the Web Services Interoperability Organization (WS-I) will help clear-up confusion over the remaining specifications. WS-I will help to ensure interoperability between vendor’s implementations of standards. (15)  The organization was created in Feb, 2002 to promote interoperability across platforms, operating systems, and programming languages.  It can be found at  Beside the WS-I is the SOAP Builders Newsgroup which provided the original interoperability testing between groups in 2001, as described early in this paper about the Xmethods website.

To provide proof that even Microsoft is co-operating in the interoperability issue; it has created a group of “How To” documents describing how to integrate Web services using various clients and server SOAP and WSDL implementations.

Microsoft’s Developers Network, MSDN XML Web Services Interoperability Resources can be found at

Today’s Interoperability issues can be grouped into 4 categories, with some examples of what the problems are:

  1. Transport Problems – HTTP header issue with SOAPAction with some client not able to send a null value.
  2. XML Problems – XML Schema complex constructs are difficult to implement, therefore it is best to keep your types simple.
  3. SOAP Problems - For instance, SOAP specifications state that if you receive a SOAP header with a mustUnderstand attribute set to "1," you must understand it, or fault. Many implementations didn't do this at first. (16)
  4. WSDL Problems – Some frameworks; such as .NET, generates multiple WSDL bindings, so you need to fully qualify which binding to use.

As new versions of Frameworks and Toolkits are developed, the issue of working around interoperability issue will start to disappear.

Enhancing Esri Products

An implementation of can be comprised of ArcGIS, ArcSDE and ArcIMS. (13)  An example of is the Geography Network found at which an example of a Web Service called PlaceFinder can be found; more Web Services needs to be added, and managed properly through a UDDI service.


The ArcGIS suite was developed using the ArcObjects.  Esri has very recently released an ArcObjects Developer Kit for .NET that extends the ArcObjects Developer Kit released with ArcGIS 8.2 with .NET assemblies, documentation and samples for use within Microsoft Visual Studio .NET.  The following description is from

This release of ArcObjects for .NET is intended to support developers developing desktop GIS solutions. These solutions can be contained within one of the ArcGIS applications: ArcMap, ArcCatalog and ArcScene, or within a standalone application. The ActiveX controls released at 8.2 (MapControl and PageLayoutControl) are also supported. Typically a developer creates components that extend the ArcObjects architecture; Commands, Tools, Layers, Renderers, Extensions, etc. This release of the ArcObjects Developer Kit for .NET, like previous releases of ArcObjects, does not support the creation of server-based GIS solutions – these include Internet Map services, Web services, etc. No technical support can be provided for server developments; in addition such developments are in violation of your License Agreement. (19)

Note that enabling ArcGIS as a Server is not allowed, but using Web Services within an ArcGIS client is.

ArcView 3.x

The ArcView desktop mapping software has the Avenue scripting language.  If Web Services were added to Avenue, ArcView could then be enabled to use any Web Service.  For example, a Web Service for temperature could be added to a view allowing temperature information to be displayed real-time.

ArcIMS v4/MetaServer

The ArcXML is the XML based protocol used to communicate between the client and the ArcIMS Server. A solution is to enhance ArcXML with Web Services standards would enable the ArcIMS Spatial Server to understand Web Services requests from any client.

Besides the enhancing the ArcIMS Server, the enhancement of the Metadata Server is needed.  The Metadata Server is the perfect place to put a UDDI registry, allowing querying for Web Services besides the metadata.


Adding Web Services to ArcSDE could be done by enhancements within the existing client APIs of C and Java.  RDBMS vendors have already starting to incorporate Web Services within their products which could be used.

Map Objects COM/Java

Map Objects can be used with Web Services applications today.  Map Objects is just a programming library that can be combined with other libraries to develop spatial applications.  In the case of COM based development you can use MS SOAP Toolkit v2.x, and any variety of Toolkits from Sun or IBM for the Java based development.

ArcReader/ArcGIS Publisher

To enhance ArcReader with Web Services is a little different in the fact the Web Service would have to be embedded into the published map files (PMF).  The ArcGIS Publisher would have the Web Service enabled on ArcIMS to serve the Web Service.  An enhanced version of the MetaServer (UDDI enabled) could provide a listing of Web Service available for that map extent.  An ArcReader Map could then tie into real time information such as, lightning strikes for a time given, or current temperature for an area of interest.


The free ArcExplorer data viewer could also be enhance in similar fashion to the ArcReader solution as given above.


The mobile solutions can also be Web Services enabled through wireless technologies such as Bluetooth, or 802.11 based solutions.  Another advantage of Web Services is the enabling of smaller form factor devices that might not be meet the requirements to run ArcPad, such as the RIM Blackberries, Palms, or Cell phones.  The heavy lifting can be done on the ArcIMS server with the results be sent back to these devices.

Future Web Services

There is a lot of activity taking place in the Web Services area of interest. “IBM’s director of e-business standards Bob Sutor predicts between 20 and 25 XML – based specifications for web services”. (15)  The good thing is you will not have to implement or use all specifications, to provide a Web Service solution.  Some specifications will not be adopted, while others will be replaced with other specifications.  Here are a couple of the newer specifications that will be important soon.

To coordinate the Web Services standards the W3C ( ) has created the “Web Service Activity” which is composed of one Coordination Group and three Working Groups, to be completed by February 1, 2004.

IBM is leading the Web Services for J2EE, Version 1.0, a Public Draft v0.3 as of April 15, 2002 and can be found at and should be available near the end of the year.  Bob Stutor says “This year you will see people build on last years specifications like SOAP and by the end of 2002 people will use WS-Security.  Next year transactions and workflow will be added to.” (15)

Microsoft is creating the Global XML Web Services Architecture (GXA) based on the following specifications:

One if the newest areas of interest for Web Services are in P2P – Peer Systems.  A Peer to Peer Network is where clients group together in some fashion and collaborate on solving problems.  At the 17th Esri European User Conference, I will be presenting a paper on “Spatially Enabling Peer Systems” and providing examples of how Models and Simulations can be integrated into Peer Systems using Web Services.


The goal of this paper was to prove that Web Services provide the best solution for achieving the goals of “”.  Web Services provide unprecedented interoperability through both Microsoft .NET framework and Java based solutions.  A Java client can talk to a .NET server or vice versa.  Currently, Microsoft’s .NET provides the best, widely deployed client solution; while the Java based Severs from BEA, IBM, SUN, and Oracle provide better server solutions.

The Next Generation Internet Applications are just starting to be built, such as Microsoft MapPoint .NET, the first Spatial Web Services offered.  If the Esri product suite were Web Service (GeoServices) enabled, it would provide a powerful solution to Spatially Enabling the Next Generation Internet.


(1) – A New GIS Architecture for Geographic Information Services

Jack Dangermond

April 23, 2001


(2)Extensible Markup Language (XML) 1.0 (Second Edition)


(3) XML: The ASCII of the Future?

Steve Land, Senior Developer

May 1999


(4) Introduction to ArcXML


(5) Sun Open Net Environment (Sun ONE) Software Architecture

An Open Architecture for Interoperable, Smart Web Services

February 2001


(6) Web Services for J2EE, Version 1.0

JSR 109, Public Draft v0.3 April 15, 2002

Specification Leads

Jim Knutson

Heather Kreger


(7) A Platform for Web Services

Web Services Technical Articles

Mary Kirtland

Microsoft Developer Network

January 2001


(8) Understanding XML Namespaces

Yasser Shohoud


(9) XML Namespaces by Example

Tim Bray



(10) XSD for Visual Basic Developers

Yasser Shohoud


(11) Web Services Architecture Requirements

W3C Working Draft


(12)Axis: The next generation of Apache SOAP

Tarak Modi

January 2002


(13)What is An Esri Technical Paper

March 2002


(14) UDDI: Universal Description, Discovery, and Integration Part 1

O’Reilly Network

Tyler Jewell and David Chappell


(15) IBM Web services guru predicts WSDL future

By ComputerWire

posted 16/05/2002


(16) Examining WSDL

Rich Salz


(17) Web Services Description Language (WSDL) 1.1

W3C Note 15 March 2001

Authors (alphabetically):

Erik Christensen, Microsoft

Francisco Curbera, IBM Research

Greg Meredith, Microsoft

Sanjiva Weerawarana, IBM Research


(18) IBM developerWorks: Web services: Deploying Web services with WSDL: Part 1

Bilal Siddiqui

November 2001


(19) ArcObjects Developer Kit for .NET


(20) Getting Started with XML Web Services in Visual Studio .NET

MSDN Visual Studio .NET Technical Articles

Rob Caron

February 2002


(21) Axis: The next generation of Apache SOAP

Tarak Modi

January 2002



David Engen

Manager, Tenure Data

Research Tenure and Engineering Branch

Ministry of Forest, B.C., Canada

1450 Government Street, 3rd Floor

V8W 9C2


Telephone:        (250)387-8630

Fax:                  (250)387-6445

Work e-mail:

Home e-mail: