Web Services in Radio: Important Develpoment

Web services aren't new. We've been talking about them for a couple of years now. Some companies have touted them as part of their packaged offerings. Microsoft has been describing them in various terms almost from the outset, seeming to me at least to grok them pretty well and to see how the concept would fundamentally change how we think about and use the Web.

What Are Web Services?

A Web service is simply an application that can be run remotely over the Web that produces something that can be displayed in your browser. As a rule, Web services are written as scripts or applets that run on one server and that are intended for use by other servers or by end users interacting with them through browsers. A Web service very often produces HTML or XML output that the requesting browser uses to update a display.

Last year, before the dot-bomb, my colleague Laurence Rozier and I developed a series of Web services on the now-defunct WeTalkSports.com Web site I had set up and was running as part of the company I had founded and where he headed up the technology effort. These services allowed anyone who could write a little simple JavaScript to retrieve from our discussion board the latest hot topics, by category, either with just headlines or with some or all of the text. I demonstrated these at a conference and people got it. In some ways, these Web services weren't so different from straightforward syndication calls. But because they allowed the calling browser to add parameters which were then used in calling the services scripts on our server, they were customizable in ways that RSS feeds for syndication are not.

Why Are They Important?

There are a lot of reasons to consider Web services important. I want to focus on a couple that are important to me because of my point of view on all this Web content stuff.

First and foremost, they are Webby. By that, I mean they not only take good advantage of the essence of the Web (which is collaboration) but also extend that Webbiness in a direction that is promising and helpful. As Web sites become dynamic, sharing simple content among sites becomes more challenging. If my page can't simply "scrape" HTML from your site and display it in my page, then we can't share equally. And if your site runs a database behind the scenes, I can't execute a query against that database from my browser without going to your site. That means that what I can do with the data you seem perfectly willing to share is limited by your vision of my need. In a world where your users are anonymous and their needs hard if not impossible to predict, that is the 21st Century equivalent of creating islands of functionality. What we want are a bunch of deeply intertwingled islands. We can each have a toll bridge or a filter or a nozzle, but those things should in many cases focus rather than limit the information you can obtain from that sub-set of my site's content that I am willing to share. And you should be allowed and able to get that content in the form that is most usable to you.

Second, and on some level at least an extension of the first, is that Web services are the next stepping stone to an agent-to-agent (A2A) Web, a concept my good friend and colleague Laurence Rozier coined and is quite busy developing these days. As the vast quantity of "stuff" available on the Web continues to explode and as our individual abilities to know about and deal with all of it decreases in the face of its sheer volume, we are going to encounter needs for which an intelligent agent is the only viable solution. But agents need some measure of predictability in what they encounter in their explorations of the Web space. Web services are at least an answer to this need. If my site offers Web services and permits a visiting user or user agent to determine what those services are and how they work and respond to being called, we can fairly quickly have a nice, comfortable medium of information exchange that need not interfere with my site's need to be dynamically generated.

I see some interesting applications for this stuff, some of which I'm developing and some of which I will postulate about over time.

What's Important About This Radio Development?

For Web services to become really useful, they have to become as close to ubiquitous as possible. Hopefully we'll even see some quasi-standards emerge for how we describe, name, and return results from these services so that meta-services and seriously intelligent agents can be created.

By making Web services available in the easiest-to-use Web publishing tool I've seen yet, Dave Winer has significantly extended the audience of those who can implement and use these tools. Inventive Users (my term for people who want to do more with their computers than those systems do out of the box, will learn to script if necessary to accomplish that, but whose primary job is not scripting or programming) want and need to develop Web services of all kinds even if they don't yet know it. Since Web services by definition run on the server, this can be a daunting task given the relative paucity of accessible server-side scripting languages. By taking this UserTalk macro approach, Dave has taken a major step toward letting people who are not programmers but who are technically savvy users in on the Web services game.

I applaud Dave once again for his foresight here. I encourage you to work through his tutorial and see if you can get a handle on how this stuff works and why it's important.

Last update: 11/13/02; 2:12:33 PM.