Web Services Demystified

Web services: they’re the latest buzzword on the block. If you believe what you read in the glossy trade press, not to mention Microsoft’s $200 million .NET advertising campaign, Web services are (in no particular order):

• Your new best friend
• The saviour of your business
• The doom of your business
• The next generation of the World Wide Web

None of this really tells you how they work or what they do for you, though. To make matters worse, Web services come with a plethora of snappy acronyms that don’t mean a whole heck of a lot at first glance either:

• SOAP: Simple Object Access Protocol
• WSDL: Web Service Description Language
• UDDI: Universal Description, Discovery, and Integration
• XML: Extensible Markup Language

…and those are just the most important ones!

Web service technology is a lot like the Wizard of Oz. Everyone will tell you it’s important and great, but no one can tell you exactly why. In this article, I’ll throw back the curtains and show you the man pulling the levers. This should enable you to decide how Web services figure into your future as a Web developer, if indeed they should interest you at all!

What Are Web Services, Really?

Okay, let me start with a straight answer: a Web service is a network interface to application functionality, based on standard Internet technologies (see Fig. 1).

Let’s say that a program on your computer (the Client Program in Fig. 1) needs spell checking functionality. Instead of doing the spell check itself, however, it might make use of a Web service to do so. Whenever it needed to perform a spell check, the program would send a request to a Web service to do it. The Web service would do the spell check, and respond with the results. From a programming standpoint, Web services can be thought of as functions that you can call over the Internet.

The neat thing about Web services is that they’re based on standard protocols that serve to ensure that any Web service can be accessed by any client program, no matter what language they’re written in and no matter what platform they’re running on. So a Java program can access and use a Web service written in VB.NET and deployed on a Windows server just as easily as a Windows program can use a Web service written in Java and running on a Linux Web server.

Because of this flexibility, several companies could produce competing spell checking Web services, and you could sign up for any one of them for your program to use. As long as they all support the same interface, the program can use any of them interchangeably. Perhaps different services might check different languages!

Although a bustling market for spell checking Web services won’t erupt overnight, some areas where Web services are expected to spread quickly include stock quotes, currency exchange rates, and inventory searches. But don’t let those expectations limit your imagination!

How Do They Work?

Web service technology has evolved around a stack of five technologies: Network, Transport, Packaging, Description, and Discovery. Each of these technologies sits on top of the ones before it (e.g. without a Network to build on, there could be no Transport).

Fig. 2 shows this stack of technologies on the left along with the most common choices for each of these layers on the right. Allow me to explain each of these layers from the top down to help you understand how together they make Web services as described in the previous section possible:

• Discovery: For a program to use a Web service, it must first be able to find it. A linked network of servers that provide a global directory of Web services, the Universal Description, Discovery, and Integration (UDDI) project is the current standard means for Web service discovery.
• Description: Before you can create a directory of Web services, there must be a way to describe a single service. The Web Service Description Language (WSDL) is an XML-based language that describes the various functions that a Web service is capable of (its public interface). Once it has a WSDL description of a Web service, a program has everything it needs to make use of it.
• Packaging: Since Web services must permit access from any program written in any language on any operating system, requests (such as “spell check this document”) and responses (like “the 3rd word is misspelled”) must have a standard format that is platform-independent. The Simple Object Access Protocol (SOAP) is an XML-based language that lets you package up function calls and documents as Web service requests.
• Transport: Once a request is packaged up (for example, as a SOAP message) you need a way to send it to the Web service. In turn, the Web service needs a way to send its response back to you. Web service technology is flexible enough to use almost any protocol — Microsoft is introducing a number of services over instant messaging, and even email is conceivable as a transport mechanism — but Hypertext Transport Protocol (HTTP), the protocol used by Web browsers to request and receive Web pages, is by far the most common.
• Network: And finally, to send and receive requests and responses between computers, a network of some kind must be available. In the vast majority of cases, the Internet is that network — or some other internal network based on TCP/IP (Transmission Control Protocol/Internet Protocol).

So with this structure in mind, let’s think about how our spell checking Web service might work. For simplicity’s sake, we’ll assume the client program has already found a particular Web service to use to perform the spell check.

The steps (illustrated in Fig. 3) are as follows:

1. The client program bundles up the document to be spell checked into a SOAP message.

This SOAP message is sent to the Web service by sending it as the body of an HTTP POST request.

The Web service unpacks the SOAP request and converts it into a command that the application can understand. The application checks the spelling of the document, producing a list of mistakes in the document.

Next, the Web service packages up that response into another SOAP message, which it sends back to the client program in response to its HTTP request.

The client program unpacks the SOAP message to obtain the results of the spell check.

Now this may all sound well and good in theory, but how difficult is it to get working in practice?

What Do I Need To Learn?

At this stage of learning about Web services, I was thinking something along the lines of “UDDI, WSDL, and SOAP… that sure is a lot of stuff to learn to do something that sounds so simple and elegant in theory!”, so I don’t blame you if you’re feeling similarly overwhelmed.

The nice thing about Web services is they are getting a lot of support from the makers of programming tools and Web servers alike. For instance, the Apache Software Foundation (ASF) has created a product called Apache SOAP that allows you to deploy standard Java programs as Web services. Similarly, Microsoft’s Visual Studio .NET provides many tools to easily deploy and write programs that take advantage of Web services.

Apache SOAP handles all the details of converting SOAP requests into Java method calls, and converting the results of those method calls into SOAP responses. It even creates WSDL descriptions of your Web services, and helps you deploy them on any Servlet-enabled Web server such as Tomcat. Apache SOAP also makes it easy to write Java programs that take advantage of Web services by handling all the details of converting Java method calls into SOAP requests and sending them to a Web server by HTTP. The ASF is now working on a follow-up project called AXIS, which makes it even easier to develop, deploy, and use Web services.

Microsoft Visual Studio .NET provides the same kinds of facilities that Apache are developing in AXIS. Visual Studio .NET makes it incredibly easy to create and use Web services, though it is specialized to work with the .NET platform. If you already use Microsoft Internet Information Services, however, Visual Studio .NET provides the ideal platform to develop Web services.

Other Web services toolkits exist for other programming languages, as well. For instance, the SOAP::Lite module lets you easily create Web services in Perl.

Summary

In this article, I took you on a tour of Web services technology. Hopefully I’ve been successful in my attempt to remove the hype surrounding this up-and-coming type of software product. At the same time, I’ve given you a few starting points to work from to learn how to develop and use Web services on your platform of choice.

No doubt, Web services are much less sexy and exciting than you expected them to be. As this article revealed, what Web services really come down to is a set of technologies that standardize communication between programs over the Internet. Microsoft has bet the farm on Web services by making them a major component of the .NET platform, and is investing $200 million to promote it. Unless I’m very much mistaken, $200 million can make anything sound sexy.

But just because Web services aren’t sexy doesn’t mean they’re not important, or exciting! The idea that any program, on any platform, written in any language can make use of a vast range of Web services is certainly an exciting one! If the development community embraces Web services as a concept (and at this stage, it’s not looking bad!), the Brave New World of software development that blossoms out of it should be quite a thing to behold.

In future articles, I’ll show you how to develop and use Web services as part of your own software projects. That’s when things will really start to get exciting!