When I first started working on the web and developing websites, the Web Service was a new concept that was still being developed. Today, whether you realize it or not, websites all around the world use web services to distribute and receive data. In this article we will take a look at what web services are and the basic concepts on how they are implemented and used.
The XML Foundation
In a nutshell, Web Services allow you to receive and/or distribute data via a web-based platform independent manner using XML (eXtensible Markup Language). Simply put, that means that whatever technology you choose to build your web applications in (ASP, PHP, etc.), you can use web services to communicate with applications that use different technologies. This is possible because Web Services are based on technology neutral XML.
So, what does the XML look like? Let's take a look at a real world example. Say I have a website that has famous quotes and I want to create a Web Service that allows anyone to get my "quote of the day" and display it on their website. My Web Service might then distribute the quote, the name of the author of the quote and a link back to my website so that I can use this service to build traffic to my website. In this case my Web Service would generate a different quote each day, and that XML might look something like this:
<Quote> The greatest lesson in life is to know that even fools are right sometimes.</Quote>
<Author>Sir Winston Churchill</Author>
The beauty of XML is its simplicity and readability. It's easy to see at a glance what information in being passed along. This also makes it simple for applications to interpret the well organized data.
Clean Communication with SOAP
Given the solid XML foundation, you now need a method or protocol for communicating that XML across the web. Currently, this is primarily done using SOAP (Simple Object Access Protocol). Like XML, SOAP is designed to be technology agnostic and work with different operating systems, technologies and programming languages. In short, SOAP is the piece that allows your application to talk to a Web Service and then for that Web Service to then in turn talk back to your application.
There are different development environments and tools available that handle most of the heavy lifting when it comes to configuring SOAP for your Web Services. There are also multiple flavors of SOAP which have subtle but important differences. In order to give you an idea of how the XML would look for a SOAP 1.1 request that includes the domain name we require before we respond with our daily quote, take a look at this example:
It's easy to see, even in this simple example, why you need a server application to handle all of your SOAP requests and a development tool that allows you to easily configure your Web Service. Imagine if we required 20 instead of 1 input value.
WSDL While You Work
The third basic element of the Web Service is WSDL (Web Services Descriptive Language). This is the part that tells exactly what your Web Service requires and returns. It wouldn't do much good for you to create a Web Service that web applications couldn't figure out how to use. That is where WSDL comes in. Like all other pieces in the Web Service puzzle, it too is XML-based. An example of part of the WSDL piece (.wsdl file) using our example service above would look like:
The example above only shows part of what the WSDL file contains. If would also contain definitions on how to handle the response output, i.e. send our daily quote, author and website address. Because of space constraints I elected not to show you a complete WSDL file example but the portion above should give you an excellent idea of how large and involved a WSDL file can become.
UDDI, Have You Seen My Web Service?
Lastly, there is the optional Web Service piece known as the UDDI (Universal Description, Discovery and Integration). This is a platform-independent framework that is designed to provide a directory where Web Services can be discovered. Think of it as a bulletin board for posting Web Services. It uses SOAP for communication and WSDL to provide the information about each Web Service. While this is by no means a requirement for creating or using a Web Service, it does offer a convenient way to find and consume Web Services in your own applications.
As with all technology, Web Services are an evolving technology that may undergo some significant changes over the next several years. However, the root concept of a technology independent platform for the requesting and receiving of data from disparate applications over the internet will likely be with us for the foreseeable future. There are several companies now that already put a lot of time, money and effort into developing and advertising their Web Services. Amamzon.com Web Services is a prime example of this kind of effort. If you want to learn more about XML, SOAP or even WSDL, a great source for introductory tutorials can be found on the W3C website.