Chapter 4: .NET Web Services

Now, a’ together, hear them lift their lesson—theirs an’ mine:
“Law, Order, Duty an’ Restraint, Obedience, Discipline!”
Mill, forge an’ try-pit taught them that when roarin’ they arose,
An’ whiles I wonder if a soul was gied them wi’ the blows.

—Rudyard Kipling, writing on the mental toughness needed to work with
high technology, “McAndrew’s Hymn,” 1894.

Problem Background

The primary user interaction model described so far in this book hasn’t changed since the Web was created at CERN in Geneva for browsing boring physics reports. A human (or, in a famous cartoon, a dog) uses an all-purpose browser program to request a page from a server, the server decodes the request and supplies the page, the browser renders it for human viewing, and the human attempts to stay awake long enough to read it. Improved content (sports scores, pornography, Weird Al Yankovic music videos^[1]) has largely solved the problem with boredom, but the final consumer of the requested data is still a human being rather than a computer program.

The current structure of the Internet is designed to render pages for humans to read, not to provide data for client programs to process.

The great thing about the Internet, though, is that it’s everywhere. Every intelligent device on the planet is connected to it, or soon will be. And intelligence is diffusing into previously dumb devices as well. LG Electronics started selling the world’s first Internet refrigerator in the fall of 2002, soon to be followed by its Internet microwave and a clothes washer and dryer. Users could reap great benefits if Web servers could provide data to programs running on all these devices as easily as they do pages for humans to look at. For example, developers could greatly enhance the user experience by writing an excellent, dedicated user interface that runs on a client machine rather than relying on a mediocre browser interface provided by the server. Think how much easier it is to process e-mail in Microsoft Outlook’s dedicated user interface than it is in Hotmail’s generic browser-based interface. (Of course, we could also screw up this opportunity by writing stupid UIs—death to the dancing paper clip!) The development of dedicated UIs would also improve server performance by moving the formatting of presentations to the client machine, having 1000 clients doing their own formatting instead of one server doing it for 1000 clients. Providing data from the Internet to a range of devices would also allow programs that don’t have any user interface, such as a bank auditing program, to use the ubiquitous connectivity of the Internet without having to divide their program logic into page requests. Likewise, we’d allow the forthcoming generation of non-PC Internet devices, such as a telephone that uses the Internet instead of standard phone lines, to do the same thing.

We could reap enormous benefits if dedicated client programs could use, request, and understand data from the Internet as easily as humans can.

The situation today, with Internet access primarily available through a generic browser program, is similar to the early part of the twentieth century, when electricity first started arriving in United States households. Then, electric motors weren’t usually built into household appliances. Sears, for example, sold a stand-alone electric motor (for $8.75) that you could connect to different appliances, such as your sewing machine, mixer, or fan.^[2] This situation was difficult because you had to connect and configure the motor before you could use any appliance. You could probably afford only one motor, so you had to choose between sewing and fanning if your clothes needed mending on a hot day. And since the motor had to run with all kinds of different appliances, it didn’t serve any of them particularly well. As motors got smaller and cheaper, they were built into individual appliances, to the point that today it’s difficult to buy a toothbrush or a carving knife that doesn’t contain at least one. Modern appliances are easy to use because the motor and its infrastructure (power supply, linkages, and so on) are optimized for each specific task and hidden from you. You don’t think about the motors; you just turn your appliance on and use its dedicated human interface.

Dedicating hardware and software to specific tasks makes them easier to use than a single generic device for everything.

The same sort of seismic shift is just now beginning in Internet programming. Just as motors got built into appliances, so Internet access will soon be built directly into every program anyone ever writes. You won’t use a generic browser except when you feel like browsing generically. Instead, you will use dedicated programs that are optimized for accomplishing specific tasks. You won’t think about the program’s Internet access, as you don’t really think about the motors in your appliances (except when they break, and the same will apply to dedicated Internet access programs). An example of this type of program is Kazaa, (which replaced Morpheus, which replaced Napster), which allows you to search the hard drives of thousands of participating users for music files that meet specified criteria, and then download the ones you like. A screen shot of Kazaa, showing a search for songs freely and publicly released on the Internet by the artists, is shown in Figure 4-1. The dedicated user interface of a multiplayer game is another example of hidden Internet access. And the latest edition of Microsoft Money does a good job of seamlessly blending Web (current stock quotes, latest balances) and desktop content (financial plans you create locally).

Figure 4-1: User interface of Kazaa, an application containing dedicated Internet access.

Easy programmatic Web access would mean that developers could compose their applications from services available on the Web, as they now compose applications from prebuilt components available on their local PCs. The designer of a word processor, which most people today would consider strictly a desktop application, might not provide a spelling checker with the application or might supply only a rudimentary one. For more sophisticated spelling or definition services, the word processor could use the online edition of the Oxford English Dictionary, whose Web site, http:// oed.com, modestly admits that it is “the most authoritative and comprehensive dictionary of English in the world.”^[3] This site charges a subscription fee and is currently available only to humans with generic browsers. If the OED provided seamless access to programs, they’d probably sell a lot more subscriptions. Maybe the word processor vendor could get a cut of the subscription fee. If they were really smart, they’d provide a seamless free trial for a few months so you got dependent on it and then take it away if you didn’t start paying.

Application designers will compose their applications from services available on the Web, as they compose them today from prebuilt components on a user’s machine.

To develop programs of this type, programmers need to be able to quickly and easily (which in turn means cheaply) write code that communicates with other programs over the Internet. The idea isn’t new; any number of techniques exist for this type of communication, such as RPC, DCOM, and MSMQ. Each of these techniques is cool in itself, and they all seemed like good ideas two or three years ago. However, they all share the fatal short- coming that they only work from one similar system to another—MSMQ talks only to MSMQ, a DCOM client only to a DCOM server, and so on.

Most existing communication technologies only work with other instances of themselves.

What we really need is universal programmatic access to the Internet— some way for a program on one box to call a function on any other box written by anyone. This access has to be independent not only of the operating system but also of the program’s internal implementations. (C++ or Basic? Which vendor? Which version? We can barely solve this problem on a single desktop.) And it has to be easy to use, or no one will be able to afford the programming time to take advantage of it.

We need universal, program-to-program, function-based communication over the existing Internet pathway.

^[1]See his hilarious spoof of Star Wars at www.sagabegins.com.

^[2]You can see a picture of this Sears catalog offering on page 50 of The Invisible Computer, by Donald Norman (MIT Press, 1999).

^[3]I am currently trying to get the OED to accept a word that I coined in my Byte.com column of August 23, 1999. The word is MINFU, patterned after the military acronyms SNAFU and FUBAR, which have crossed into general usage. In polite company, MINFU stands for MIcrosoft Nomencla ture Foul-Up, and it happens a lot. For example, referring to in-place activation of an embedded object as “visual editing” (to distinguish it from tactile editing, I guess, or olfactory editing) is a MINFU. The whole COM-OLE-COM-ActiveX-COM nomenclature debacle was and to this day remains a giant MINFU. When I wrote to the OED, they politely said, in part, “...we will be looking for more general currency before we could consider including it in the OED.” So far, I’ve gotten a couple of authors to use it, most notably David Chappell. I hope you’ll all use it in your writing and send me a link to it, which I’ll forward to the OED. You don’t have to credit me, just use it. If I can get it into the Microsoft Press style guide, I’ll have it made.