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.
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.
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!