Web Services: Worth Your While?
Beyond the alphabet soup of technological acronyms that make up Web services is a powerful remote computing idea.
There's a great future in plastics. Think about it. Will you think
— Mr. McGuire to Benjamin Braddock
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
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
"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:
- 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.
- 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.
- 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.
- 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.
- 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
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
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
- 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 =
AsinRequest asinSearchRequest1 = new AsinRequest(); asinSearchRequest1.asin
asinSearchRequest1.tag = "webservices-20";
asinSearchRequest1.type = "heavy";
asinSearchRequest1.version = "1.0";
ProductInfo asinSearchRequestResult =
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
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
- 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
- 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
Mike Gunderloy, MCSE, MCSD, MCDBA, is a former MCP columnist and the author of numerous development books.