Spatially Enabling the Next Generation Internet

David Engen

Abstract

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.

Introduction

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 “G.net” 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 “G.net”.

Web Services

History

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

A Web service is accessible over the Web.
A Web service exposes an XML interface.
A Web service is registered and can be located through a Web service registry.
Web services communicate using XML messages over standard Web protocols.
Web services support loosely-coupled connections between systems.” (5)

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

A service implementation implements the methods of an interface that is describable by WSDL. The methods are implemented using a Stateless EJB, or JAX-RPC web component.
A Web Service may have its interface published in one or more registries for Web services during deployment.
A Web Service implementation, which uses only the functionality describe by this specification, can be deployed in any Web Services for J2EE compliant application server.
A service instance, called a Port, is created and managed by a container.
Run-time service requirements, such as security attributes, are separate from the service implementation. Tools can define these requirements during assembly or deployment.
A container mediates access to the service.” (6)

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.

Advantages

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

OS Independence: It is not tied to a specific Operating System. A Web Service can be called from any type of client to any type of server. The client and server don’t have to even be the same Operating System.
Language Independence: It is not tied to any specific language. The client could be Microsoft .NET based client calling a Java based server.
Transport Protocol Independence: It is not tied to specific message transport. Today you will find the most prevalent form of transport being HTTP. But it could use ftp, mail (SMTP), or any other type of messaging based protocol.
Application Independence: It is not tied to a specific type of application. For example Office XP includes a toolkit to enabled Web Services so it can call any other Application that provides a Web Service.

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: http://www.microsoft.com

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 http://msdn.microsoft.com/library/default.asp?url=/nhp/default.asp?contentid=28000442

IBM: http://www.ibm.com

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 http://www.apache.org which is the basis for Apache’s SOAP v2.2. IBM Web Services information can be found at http://www-106.ibm.com/developerworks/webservices/.

Sun Microsystems: http://www.sun.com

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 http://java.sun.com/webservices/

Systinet: http://www.systinet.com

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: http://www.apache.org

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 http://xml.apache.org/axis/index.html. One of the advantages of Axis project is source code is published allowing developers to know exactly what is going on.

Xmethods: http://www.xmethods.com

Tony Hong posted on the SOAP Builders Newsgroup about interest in starting an interoperability lab in Jan 31, 2001, at http://www.xmethods.net/ilab/. 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 http://www.geographynetwork.com, 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 http://www.w3.org.

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” ?>

<GET_IMAGE>

</PROPERTIES>

</GET_IMAGE>

</REQUEST>

</ARCXML>

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.

Code 2

<ctc:permit xmlns:ctc=”http://www.gov.bc.ca/mof/tenure” xmlns:ts=”http://www.microsoft.com/tenure”>

<ctc:contact>

<ctc:key>123456</ctc:key>

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

<ctc:address>Anywhere</ctc:address>

<ctc:phone>(123)123-4567</ctc:phone>

</ctc:contact>

<ts:AAC>

<ts:deciduous>

<ts:volume>123456</ts:volume>

</ts:deciduous>

<ts:coniferous>

<ts:volume>45678</ts:volume>

</ts:coniferous>

</ts:AAC>

</ctc:permit>

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 = ”http://www.microsoft.com/tenure” 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=”http://www.w3.org/2001/XMLSchema”>

<xsd:simpleType name = “AddressType”>

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

<xsd:maxLength value=”50”/>

</xsd:restriction>

</xsd:simpleType>

<xsd:complexType name = “contactType”>

<xsd:sequence>

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

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

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

</xsd:sequence>

</xsd:complexType>

<xsd:simpleType name=”deciduousType”>

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

</xsd:restriction>

</xsd:simpleType>

<xsd:complexType name = “AACType”>

<xsd:sequence>

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

</xsd:sequence>

</xsd:complexType>

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

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

</schema>

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=”http://www.w3.org/2001/XMLSchema” 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 http://www.Esri.com/schema/shapefile 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.

SOAP

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

Host: www.gov.bc.ca

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

Content-Length: nnnn

SOAPAction:

<ENV:Envelope xmlns:ENV=”http://schemas.xmlsoap.org/soap/envelope/” >

<ENV:Header>

<xsd:Order xmlns:xsd="http://www.w3.org/2001/XMLSchema" ENV:mustUnderstand="1">

</xsd:Order>

</ENV:Header>

<ENV:Body>

<p:findPlace xmlns:p=”http://www.geographynetwork.com/PlaceFinder”>

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

</p:findPlace>

<ENV:Fault>

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

</ENV:Fault>

</SOAP-ENV:Body>

</SOAP-ENV:Envelope>

Code 5

Binding with SMTP

TO: <dpengen@gems5.gov.bc.ca>

From: <david.engen@telus.net>

Reply-To: <david.engen@telus.net>

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

Message-Id: <EA9B345D8D93E93B7A6E7@telus.net>

MIME-Version: 1.0

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

Content-Transfer-Encoding: QUOTED-PRINTABLE

<ENV:Envelope xmlns:ENV=”http://schemas.xmlsoap.org/soap/envelope/” >

<ENV:Header>

<xsd:Order xmlns:xsd="http://www.w3.org/2001/XMLSchema" ENV:mustUnderstand="1">

</xsd:Order>

</ENV:Header>

<ENV:Body>

<p:findPlace xmlns:p=”http://www.geographynetwork.com/PlaceFinder”>

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

</p:findPlace>

<ENV:Fault>

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

</ENV:Fault>

</SOAP-ENV:Body>

</SOAP-ENV:Envelope>

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="http://schemas.xmlsoap.org/soap/envelope/">

<ENV:Body>

<l:FindPlaceResponse xmlns:l = "http://www.geographynetwork.com/services/v1/PlaceFinder">

<l:findPlace1SoapOut>

</l:findPlace1SoapOut>

</ENV:Body>

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="http://schemas.xmlsoap.org/soap/envelope/" >

<ENV:Body>

<ENV:Fault>

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

</ENV:Fault>

</ENV:Body>

</ENV:Envelope>

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 http://www.w3.org/TR/SOAP

WSDL

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, http://www.w3.org/TR/wsdl. 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.

What are the services offered in your online business?
How can you invoke your business services?
What information do your business services need from the user when he or she invokes your service?
How will the user provide the required information?
In which format will the services send information back to the user? (18)

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.

Types– a container for data type definitions using some type system (such as XSD).
Message– an abstract, typed definition of the data being communicated.
Operation– an abstract description of an action supported by the service.
Port Type–an abstract set of operations supported by one or more endpoints.
Binding– a concrete protocol and data format specification for a particular port type.
Port– a single endpoint defined as a combination of a binding and a network address.
Service– a collection of related endpoints. (17)

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 http://www.geographynetwork.com/services/v1/PlaceFinder.wsdl

Type:

<types>

<schema xmlns=”http://www.w3.org/2001/XMLSchema”

</sequence>

</complexType>

</type>

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:

</message>

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:

</operation>

Code 11

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

PortType:

</operation>

</portType>

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:

<soap:binding style="rpc" transport="http://schemas.xmlsoap.org/soap/http" />

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

<soap:body use="encoded" namespace="http://www.geographynetwork.com/PlaceFinder" encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" />

</input>

</binding>

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:

<soap:address location="http://www.geographynetwork.com/services/v1/PlaceFinder"/> </port>

Code 14

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

Service:

<definitions name="PlaceFinder" targetNamespace=http://www.geographynetwork.com/PlaceFinder

xmlns:soap=”http://schemas.xmlsoap.org/wsdl/”/>

…

</service>

</definitions>

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.

UDDI

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 http://www.uddi.org. 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 http://www.systinet.com/products/wasp_uddi/index.html

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 http://www.geographynetwork.com/services/v1/PlaceFinder.wsdl

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 http://www.geographynetwork.com/services/documentation/public_net.html

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 http://arconline.Esri.com/arcobjectsonline/GettingStarted/IntroDotNet.htm

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:

Support SOAP 1.1, just as Apache SOAP 2.2 does. For example, Axis will completely support the SOAP concept of mustUnderstand headers. Axis's final release will have a few SOAP 1.2 features as well as partial support for pluggable XML protocols.
Likely prove much faster and more resource efficient than Apache SOAP, since it uses SAX (Simple API for XML) instead of DOM (Document Object Model). SAX allows lazy parsing of XML documents, which in many cases is more efficient -- especially when the entire XML document does not need to be parsed or kept in memory for long time periods.
Have a clean and simple abstraction for designing transports -- i.e., senders and listeners for SOAP over various protocols such as SMTP (Simple Mail Transfer Protocol), FTP, message-oriented middleware, and so on. Also, the engine's core will be completely transport independent.
Automatically generate WSDL (Web Services Description Language) from deployed services. The Axis alpha 2 version also comes with the wsdl2java tool for building Java proxies and skeletons from WSDL documents. Thus, you not only get the WSDL for an Axis-deployed service, but you can also build stubs and skeletons from the WSDL for extremely easy client code development. Note that the WSDL that feeds into the wsdl2java tool can originate from any source as long as it adheres to the WSDL specification. I'll show you an example of using this feature later.
Support EJB (Enterprise JavaBeans) deployment as services. This resembles a feature provided by some application servers, such as BEA WebLogic Server.
Feature improved deployment support and the ability to drop Java files into a deployment directory and expose the classes as services. I'll show you an example of this later.
Better interoperate with Microsoft's SOAP implementation and .Net services. Over the past year, Apache and Microsoft have undergone several iterations of their SOAP implementations; with each iteration, they become more interoperable with each other. For details, see the summary of the last Apache/Microsoft interoperability meeting. (21)

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 HelloServer.java

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

using System.Web.Services;

[WebService(Namespace="urn:HelloServer")]

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

WS-Security
WS-Inspection
WSFL WorkFlow
Apache Axis

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.

Interoperability

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 http://ws-i.org. 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.

Q307324 HOW TO: Integrate a .NET Client with an Apache SOAP 2.2 XML Web Service
Q307318 HOW TO: Integrate a SOAP Toolkit Client with an Apache SOAP 2.2 XML Web Service
Q307279 HOW TO: Integrate an Apache SOAP 2.2 Client with a SOAP Toolkit XML Web Service
Q308438 HOW TO: Integrate a PERL/SOAP Lite Client with a SOAP Toolkit or .NET XML Web Service
Q308466 HOW TO: Integrate an Apache SOAP 2.2 Client with a .NET XML Web Service

Microsoft’s Developers Network, MSDN XML Web Services Interoperability Resources can be found at http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnsvcinter/html/globalxmlwebsrvinterop.asp

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

Transport Problems – HTTP header issue with SOAPAction with some client not able to send a null value.
XML Problems – XML Schema complex constructs are difficult to implement, therefore it is best to keep your types simple.
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)
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

G.net

An implementation of G.net can be comprised of ArcGIS, ArcSDE and ArcIMS. (13) An example of G.net is the Geography Network found at http://www.geographynetwork.com 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.

ArcGIS

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 http://arconline.Esri.com/arcobjectsonline/GettingStarted/IntroDotNet.htm

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.

ArcSDE

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.

ArcExplorer

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

ArcPad

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.

WS-Inspection: was created to allow people to discover Web Services. It was not to replace UDDI, but as an addition to allow discovery at the server. It is meant as a replacement for the proprietary DISCO solution from Microsoft .NET framework.
WS-Security: is a new specification released in April 2002 by IBM, Microsoft and Verisign to provide security to Web Services.

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

Web Services Architecture Working Group.
XML Protocol Working Group.
Web Services Description Working Group.

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 http://www.ibm.com/webservices/pdf/websvcs-0_3-pd.pdf 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:

WS-Inspection
WS-License
WS-Referral
WS-Routing
WS-Security

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 17^th 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.

Conclusions

The goal of this paper was to prove that Web Services provide the best solution for achieving the goals of “G.net”. 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.