XML Web Services, GIS, and Location Technologies - Part 1

November 20, 2002
Share

Sharing is Caring

With so much attention in the tech media over the last 18 months, one would think XML Web services and Microsoft .NET would be more widely understood. But as with most new technologies, especially those that are 'industry standards', there is often a lengthy adoption period where software vendors plan, architect, and deploy around the new technology.After all, you need a foundation before you build the house.Team this ramp up period with the fact that the low-level nuts and bolts of XML Web services are pretty esoteric, and the confusion compounds.

For many readers, Web services, and the benefits they deliver, may be so abstract that you may not understand their importance in the broad computing industry, let alone the vertical that we all focus on everyday - Mapping and Location Intelligence.Fortunately, there is some good news here.First off, you do not need to understand the nuts and bolts level of XML Web services any more than a technology like COM or the low level kernel code of an OS in order to reap the benefits of connected computing.And even more importantly, the waiting is over - most major vendors now support XML Web services in their software.You may already be realizing the rewards of software systems built with XML Web services, and not realize it!

As you dig into this overview of XML Web services with an emphasis on the implications for users of location technologies, it is important to understand how widely XML Web services are being adopted in the software industry.The largest software vendors such as IBM, Microsoft, Oracle, and Sun have all announced support for Web services, and plans to integrate them into their development tools, operating systems, databases and application servers.This opens the door for hundreds of smaller developers to benefit from Web services in their applications.By embracing XML-based Web services today, you are enabling your software, your services, and your business to participate in the world of connected computing that will define this decade.

This two-part article will clear the air and give you insight into where the state of the art finds us today, and where things are heading.Although XML Web services are tools for developers, you do not have to be a code jock to benefit from reading this article, especially part one.Here we will cover XML Web services, why they are important, how they work, and how you can begin to take advantage of them today.This includes building your own commercial Web services as well as consuming other third party Web services within your applications.We will also set straight a few common misconceptions about XML Web services as we explore their benefits for your business.Part two will make it all real, and is geared towards application developers.Here you will totally understand the benefits of XML Web services as we write 40 lines of code to build a desktop application in Visual Basic .NET that performs international street level geocoding and map rendering! Considering that your completed application will not require you to install map data, a render engine or a geocoder on any workstation we will have accomplished quite a bit.Compare this with the time and expense of developing the same capabilities with traditional GIS development tools, and you begin to see why there is so much excitement surrounding XML Web services.Those readers who are not developers will want to stick around for part two as well, as you will find it eye opening as we reveal just how easy and straight forward building distributed applications with XML Web services is.

PART I - XML Web Services Explained

What is an XML Web service? Is this analogous to .NET?
Before we get into why XML Web services are so important to all of us dealing with location technologies, let's get on the same page by reviewing a few basic definitions.XML (or eXtensible Markup Language) is the universal language for data exchange between machines. XML allows computing machines to share data regardless of the operating system or programming languages used by their peers.At their core, XML Web services are small applications that use XML to share data and functionality amongst themselves across the Internet.As XML is an open standard supported by all major operating systems, development tools, and platforms, XML Web services enable communication between previously disparate systems- A Linux server application can interact with a Windows Server application, a Pocket PC device can programmatically access services hosted by a Solaris server, etc...

Microsoft .NET is a set of Microsoft software technologies for connecting information, people, systems, and devices through the use of XML Web services..NET is infused into the products that make up the Microsoft platform, providing the ability to quickly and reliably build, host, deploy, and utilize secure and connected solutions using XML Web services.The Microsoft platform provides a suite of developer tools, client applications, XML Web services, and servers necessary to participate in this connected world. For a moment, I am going to take the liberty of oversimplifying to state that an XML Web service is merely a remote library of code used by a developer.Here is a real world scenario to illustrate this.As software systems have grown in complexity, developers have learned to share code in libraries so that they do not have to write entire systems themselves.They want to focus on the business problem they are trying to solve, relying on code from third parties to perform well-defined common tasks.Typically, these libraries take the form of DLL's, ActiveX controls, Shared Objects, and the like.If you are building a drawing program that requires the need to convert graphics from one format to another, you do not want become an expert in understanding the differences between the dozens of graphics formats out there.This would consume valuable development resources that could otherwise be applied to adding cool drawing features and getting your application in your customer's hands sooner.Instead, you would license a library of code from a company that specializes in graphics conversion, freeing up developer resources, allowing you to focus on your application.Think of XML Web services as remote libraries of code. They provide discrete bits of functionality and access to data, but they are hosted and distributed across the Internet or your private intranet. Developers use them as they have used code libraries in the past, pulling a number of them together to create their final applications.You're probably starting to see some of the benefits of this distributed architecture:

  • Easy application maintenance.Code libraries typically were required to be installed on each computer or device that needed to use them, in addition to the developer's machine.This requires heavy client side installations as well as maintenance when new versions of a library are ready to be deployed.XML Web services are hosted and have no such requirement.Once your application is built and deployed, any XML Web services that it relies on can be silently updated without interfering with your application.
  • Web Services are discoverable. Universal Description, Discovery and Integration (UDDI) is an associated standard that allows an organization that has created an XML Web service to promote it to the developer community.Like XML Web services themselves, UDDI is an open standard with broad industry support.A developer can use a UDDI search engine to find Web services that meet certain criteria and provide needed functionality, regardless of who is providing the Web service. Once discovered, they can begin using them immediately.Try it yourself - go to https://uddi.ibm.com/ubr/findservice?action=init in a standard web browser.This is a UDDI search engine hosted by IBM.Enter 'map' in the service name field and hit the 'Find' button.You will be presented with a list of XML Web services related to Mapping.Click on any of the services to drill in and see their details.Here you will see a reference to the service's WSDL (Web Service Definition Language) file.The WSDL describes the functionality exposed by the service, which leads into our next major benefit.
  • Web Services are self-describing.Once a Web Service is discovered, the developer can begin using it immediately. All they need is the full URL path to the services WSDL.The WSDL is an XML formatted file that describes every bit of functionality the service supports.Each method, parameter, property, and return value of the service is described in a standard fashion, allowing modern development tools to immediately allow access to the exposed functionality.Visual Studio .NET (Microsoft's Integrated Development Environment) and the AXIS Library for Java are two such development tools.Given a WSDL, they can create proxy classes that communicate with the service.Visual Studio .NET integrates Web Services so well, that once a particular WSDL file has been specified, the Web Service is treated no differently than a traditional local code library such as DLL.There is no software to install on the development machine, code completion and IntelliSense are active, and the developer is immediately productive.Pretty slick.
  • Web Services conceal complexity.Perhaps my favorite benefit, as it solves so many of the problems traditional GIS solutions face in their effort to reach the masses.Let's face it; much of what we do each day in the GIS world IS complex.More so than a non -GIS user will endure to use a typical mapping application, and more than a traditional application developer wants to get involved with to 'just' integrate location technology into their business application.Obviously, we all want to sell our location based applications and services to a broader market, but data management issues, dedicated hardware costs, steep up-front licensing fees, non standard development tools and scripting languages and proprietary API's each offer venerable obstacles to wide adoption. XML Web services can address each of these.Real time data feeds, large seamless data sets, standard programming tools, easy application integration, transaction pricing, and timely updates all become possible.
  • Web Services are very independent.Device independent.Programming language Independent.Platform independent.These are good things for all of us, and the benefit cannot be overstated.Any developer in your organization can utilize the power of location in their applications, not just the dedicated GIS staff.Religious battles over operating systems become a thing of the past.Porting applications from the desktop to the handheld takes a fraction of the time it used to.
  • Smart Clients will change computing. Web Services are nimble and can be used in a lot of configurations.Most typical today is Server to Server.Here a Linux server application could utilize information exposed by an XML Web Service running on a Windows Server, for instance.Think of Company XYZ hosting a Web service to expose real-time inventory information to their customers purchasing systems. But perhaps the most relevant scenario for the average user is Client to Server communications.Smart client computing, made possible in large part by XML Web services, is upon us.Here, applications running on connected devices ranging from a desktop workstation to a mobile laptop or Tablet PC interact with heavy weight Web services to access corporate data and shared code.These are the devices and applications that we commonly use everyday.Very soon, you will see everything from your word processor to your desktop mapping system able to consume Web services.This brings Location Intelligence to the applications you use everyday, when and where you need it.As an example, imagine an Excel user studying a customer database. They would like to populate a field with a score based on the probability that the customer will be interested in a new sci-fi film they are marketing. Historically, this user needs to purchase, configure and install a set of demographics related to the Film industry, a host of mapping and location applications and data, then figure out how to use them in conjunction with their spreadsheet.Smart clients will be able to go out over the Web, utilize a demographics Web service, and answer the business problem they face, right in the application they are working in.
Clearing up those Misconceptions
And finally, before we move on to discuss implementations; let's clear up the two most common misconceptions about Web services.
  • A website is NOT a Web service.Yes, the nomenclature is a bit confusing.Take your favorite website for getting a weather forecast.You go there each day and check the weather in your area based on zip code or some other geographic identifier.You do it on the web, and it provides a service.So, it stands to reason that this is a Web service. But it certainly is not a true XML Web service.Think back to our definitions earlier.It is not programmable, works only in a Web browser, and it is tied to HTML interpreters. If you were building a mobile travel application that ran on PDA's, it would be difficult at best to integrate weather information from this website into your application. However, if the maintainers of this website built an XML Web service providing programmatic access to their weather data, it would allow you to integrate weather in your application with little effort.Once the software vendor has implemented a true Web service, their weather data can be used in ways they probably never imagined.A third party building applications for air traffic control that run on mainframes can now tap into this information to re-route flights based on storm activity for instance.They of course can still keep their Web based portal running in parallel, but now that they have implemented a true XML Web Service, they have opened up revenue streams leveraging their investment in gathering and organizing weather data.
  • Web services are not Just for Web applications. Talk about being typecast.Remember Tom Hank's early work in screwball comedies like Bosom Buddies? He had a lot of potential as an actor, but was confined to movies like Bachelor Party until casting agents realized his talent beyond slapstick.An XML Web service is just as comfortable as an ingredient in standard Windows applications, as it is in a browser-based Web application.Handhelds, in-car telematics, set top boxes, Tablet PC's and any other platform or device that can make calls to a Web service can benefit.It is largely their platform independent nature that makes XML Web services so compelling.Application developers love nothing more than to re-use code they have written and tested over and over.
For more on Web services and .NET, this is a good place to start: http://www.microsoft.com/net/basics/

Why is this important to the mapping industry?
By now, I am sure you see where this is all heading.Armed with a foundation understanding of Web Services, you can see the benefits they bring to your business.It's almost uncanny how the problems we face in the broad deployment of location technologies line up one to one with the benefits of Web services architecture and connected computing.

Let's look at a typical example. You are just beginning version 1 of your Web based travel portal for the United States.You bite the bullet and invest big bucks in two dedicated mapping servers. Of course, what good is a map renderer without map data, so you open your wallet big-time for a license to use nationwide street data on your two servers? To save some money, you shop around and acquire the street network from a different vendor than the Map Servers. You will need to spend some effort getting the street data into a format understood by the renderer.Your users need to be able to enter street addresses, so you shop for a street level geocoding engine.There are a number to choose from, and you go with a vendor offering a good feature set and what looks to be a good price.Oh no, you didn't account for the premium for the ability to run it on a server.Two days later, your lead developer is in your face complaining that the renderer and geocoder have 2 completely different API's and it's going to take longer than expected to learn them both and get them to work together.A few weeks later, you have a prototype running.Hey, why are none of the geocoded points lining up with the street network used for display? You call the geocoding vendor's tech support and after a lengthy explanation, (something about nads and datums) you realize the data in your street network is not compatible with that of your geocoder.Your application finally goes live and is building a solid user base.A common request from users is that they would like your application to cover Canada as well, so you hit the streets and strike a deal to license Canadian street data for your renderer.Of course, you need a geocoder for Canada as well, so it's back to your Geocoding vendor to make another purchase.But 2 days later, your dev lead is back in your face, complaining that even though the Canadian geocoder is from the same vendor as the US geocoder, it has a completely different architecture and API.More delays while his team gets up to speed.That week, a third party travel agency contacts you, stating that they would like to private label your travel portal if you can add driving directions.More sticker shock, more data incompatibilities, more headaches. OK, enough is enough.

Uugh.If you've worked with location technologies as long as I have, this is probably less like an episode of Abbott and Costello Meet GIS, and more like the painful reality of building mapping and location into your applications that you face each day.Could this be the reason that location technologies have not made it mainstream? Remember the section above on concealing complexity? Will the madness ever stop? I will save the challenges you will face when users start requesting your travel service on Smart Phones or your data management team requests an internal Winform application with a map interface for another episode. And we will not talk about the one where each of your data providers for streets, geocoding, and routing, in each of the countries you support, all decide to rev their data at once.It's a real knee-slapper.

Instead, in Part 2 of this Directions Magazine article, we will build an application that utilizes XML Web services to address many of these problems.It will do street geocoding in over a dozen Countries and display interactive street maps.Best of all we will do it in 30 minutes and only write a few dozen lines of code.After a siesta, we may even decide to add driving directions (in nine languages!) and routing to our application with a couple more lines of code.Life is good, but do not thank me...thank XML Web services!

Share

Sharing is Caring


Geospatial Newsletters

Keep up to date with the latest geospatial trends!

Sign up

Search DM

Get Directions Magazine delivered to you
Please enter a valid email address
Please let us know that you're not a robot by using reCAPTCHA.
Sorry, there was a problem submitting your sign up request. Please try again or email editors@directionsmag.com

Thank You! We'll email you to verify your address.

In order to complete the subscription process, simply check your inbox and click on the link in the email we have just sent you. If it is not there, please check your junk mail folder.

Thank you!

It looks like you're already subscribed.

If you still experience difficulties subscribing to our newsletters, please contact us at editors@directionsmag.com