Web Services: Worth Your While?

Beyond the alphabet soup of technological acronyms that make up Web services is a powerful remote computing idea.

• By Mike Gunderloy
• 10/01/2002

While plastics may have been the future in the 1967 film The Graduate, a remake 35 years later might substitute the words "Web services." If you haven't been bombarded with information and hype about Web services, you're living in a different development world than I am. So what's the big deal? Or is there even a big deal? That's the topic that I'll be exploring in this column.

(A bit of full disclosure first: I'm editing a newsletter devoted entirely to Web services these days. Keep that in mind as you read the rest of the column.)

What's a Web Service?
Let's start with a terminology check. Even if you've heard the term, you may not really understand what constitutes a Web service. It's pretty easy to find definitions that don't help much, like this one from Microsoft:

"Put simply, Web services provide a substrate for building distributed applications using software running on different operating systems and devices, written using different programming languages and tools from multiple vendors, all potentially developed and deployed independently."

Well, that's all true — but about as useful as knowing that a dictionary can be printed on many colors of paper using different colors of ink. As a working developer, you may find it simplest to understand Web services as part of a natural progression of distributed objects. Here's how this has worked out in the Microsoft world:

1. If you go far enough back, you'll recall writing monolithic applications under MS-DOS. Though these applications might have been vaguely object-oriented, they generally weren't distributed at all. Every object in the application was implemented in a single executable program.
2. Windows let us split up applications by putting some objects into dynamic link libraries (DLLs). The objects were all still part of the same application, but now they could be split up into multiple files to cut down on memory requirements and to allow modular management.
3. COM changed everything. By adhering to the COM standards, you could use objects that you didn't write (or make your application's own objects available for others to use). With the advent of COM, many developers started really appreciating the difference between interface and implementation. As long as you know the interface of an object, you don't need to care about its implementation. In a COM-based world, your program can interact with a variety of objects from different sources.
4. But with COM, all of the objects are trapped in a single computer. DCOM (and other distributed object-oriented protocols) let you open that trap and free the objects. With DCOM, an application on one computer can call objects that are hosted on another computer. Once you have the plumbing in place, DCOM lets you distribute objects around the network.
5. And finally, here's where Web services come in: When you switch from COM or DCOM plumbing to Web services plumbing, you can distribute objects around the entire Internet. You can call an object on a remote server that you can only reach via the standard HTTP protocol with the same syntax that you use for an instance of a class that's part of your own application.

So, Web services are just a way to continue the natural progression of ever more remote objects. What's the big deal? To answer that question, I need to talk about protocols a bit.

The Alphabet Soup
One of the best things about Web services is that they run on standard protocols that are implemented by a variety of vendors. The big three that you should know about are UDDI, WSDL, and SOAP.

UDDI stands for Universal Description, Discovery, and Integration. The purpose of the UDDI protocol is to let you browse a catalog of Web services to locate ones of interest for your application. UDDI defines messages and responses that can be used to catalog and find Web services (and other resources for online business).

WSDL stands for Web Services Description Language. WSDL gives you a way to find out the details of a Web service's interface after you've discovered it. WSDL messages contain all of the information that you need to call objects and their interfaces through a Web service.

SOAP is the Simple Object Access Protocol. SOAP gives you a standard way to convert objects and their interfaces into messages that can travel across the Web. With SOAP, you can convert an object into a message, send that message to a remote machine and reconstitute the object.

All three of these protocols use XML as their formatting specification and HTTP as their transport mechanism (though alternative transports are possible). XML has two main advantages for formatting Web service messages. First, there are a gazillion XML parsers and other XML tools out there, so working with XML is relatively easy no matter which development environment you're using on your own computer. Second, XML is human-readable rather than binary. If you're not entirely sure what's going on in a SOAP or WSDL message, you can use a simple text editor to take a look at it.

The main advantage of HTTP as a transport mechanism is its ubiquity. HTTP messages can get most anywhere on the Internet — at least, anywhere that there's a Web server. Early Web services PR emphasized the "blasts right through firewalls" aspect of HTTP, but that's a less-popular selling point now. Because many system administrators are less than happy with the notion of random objects crossing their firewalls, a new generation of firewalls is springing up that's SOAP-aware. SOAP messages from untrusted sources can be blocked at the firewall, just like anything else.

You'll notice that there's nothing in any of this plumbing that's operating system specific. That's the big deal. As long as you can parse XML messages and implement a few specific message types, you can play in the Web services world. The pool of available objects just got a lot bigger.

As a Practical Matter…
Still a bit confused? How about an actual example to cut through the fog?

As with many other things, Amazon.com has a Web services presence. In July they released a Web services API for the databases backing the Amazon.com Web site. Using Web services defined by Amazon, you can do all sorts of things, including:

• Search for books, music, or most anything else that Amazon sells.
• Retrieve basic or comprehensive product information.
• Add items to an Amazon shopping cart.

With the right language and development environment (I happen to like VB.NET or C# inside of the Visual Studio .NET IDE, but then, I've been using Microsoft tools for quite a while) doing any of these things is simple. For example, here's a bit of C# code to take an Amazon Stock Inventory Number (ASIN) and return the sales rank of the product the ASIN specifies:

public static string GetSalesRank(string asin)
{
  AmazonSearchService amazonSearchService =
    new AmazonSearchService();
  AsinRequest asinSearchRequest1 = new AsinRequest();   asinSearchRequest1.asin = asin;
  asinSearchRequest1.tag = "webservices-20";
  asinSearchRequest1.type = "heavy";
  asinSearchRequest1.version = "1.0";
  ProductInfo asinSearchRequestResult =
    amazonSearchService.AsinSearchRequest(asinSearchRequest1);
  return asinSearchRequestResult.Details[0].SalesRank;
}

OK, so they're not the most inspired variable names ever. The point is that any developer who understands objects can work with a Web service. In this particular case, it only took me a couple of hours from downloading the details of this particular Web service to build a little application that will show me the sales ranks of my own books. (If you'd all run out and buy copies, the numbers would make me much happier, but that's another column).

Closing Thoughts
This is where I should offer a single conclusion that tells you everything you need to know about Web services. But I'm not quite that confident that I can predict the future. Instead, how about a few things to ponder:

• My little experiment with Amazon's Web services API was probably not something that they anticipated. They were probably hoping I'd use it to buy lots of books. When you let other people use your objects, you don't control how they're used. And any experimentation uses up your computing resources, too. So if you're going to expose some part of your own organization's functionality through a Web service, be prepared to argue to the beancounters that the benefits are worth the potential hassles.
• While the bubble won't be as large as the original dot-com mania, many things will be offered as Web services without any reasonable economic model. Almost all of these will vanish within a year or two.
• Of the major Web services protocols, I'm not convinced that UDDI is all that important. There are two reasons I feel that way. First, if you go look at the public UDDI registries, you'll see that they're full of junk; anyone can (and does) add garbage to a UDDI registry. Second, I believe the most productive uses of Web services will be between business partners that already work with each other. There's no need for a discovery protocol in that case; you can just send your programmers to do lunch with their programmers.
• Universal interoperability, while closer than ever, will remain a goal rather than a reality. The standards don't specify everything, and vendors ignore standards when it suits them anyhow.

But despite these caveats, I'm still excited by Web services. In the scenarios where they make sense, they really make sense. A lot of e-commerce and information retrieval applications stand to benefit from Web services, and the tools are making this stuff easier all the time. So if you plan to continue your development career for a few more years, pay attention to this stuff; it's likely to affect your job sooner rather than later.

Or is it? Have I been drinking the Microsoft Kool-Aid for too long again? Did you try Web services and run into roadblocks in the real world? Write and let me know. I'll use the most interesting comments in a future issue of Developer Central.