The title of this week's column is stolen from an item[1] I've just posted to my Weblog, with apologies to Monty Python[2].
It's been an interesting week. On Tuesday of last week, I began an experiment[3] to coordinate two sets of Web services: online
bookstores, such as Amazon and Barnes & Noble, and online libraries, in particular my own local libraries. The LibraryLookup
project[4], as I'm now calling it, took on a life of its own.
On Wednesday I discovered that a simple bookmarklet would do the job. It can parse the ISBN number from the URL of an Amazon,
or B&N, or isbn.nu, or other book-related site; issue a query to your local library; and open a new browser window onto the
result of that query. I found a list of the addresses of almost 900 libraries that use the same Web-based system that my libraries
do, and blogged the corresponding bookmarklets. At a single stroke, one-click lookup from a central book site to the local
library was made available to potentially millions of users. It was one of those magical Internet moments.
Meanwhile, I was supposed to be writing an article for InfoWorld's special section on disruptive technologies. As my project
unfolded, it became clear I was in the middle of a disruptive event. By Thursday, the vendor of the library software had withdrawn
the Web page on which I'd found the 900 URLs. What had seemed to be an informational Web page had turned out, to the vendor's
surprise, to be a directory of Web services. Oops.
Another, more pleasant surprise came later that day. Online library services didn't need to be explicitly listed in a directory
in order for me to be able to find them. By Googling for the URL signatures of two other vendors' software, I added support
for two additional library systems, and for another 400 libraries that use those systems.
The library bookmarklet meme propagated over the weekend, mutating along the way, and by Monday there were all sorts of
variations being tried. It's delightful to find that such a simple idea can yield such a powerful result. But why are we always
so surprised by these things? We should all expect spontaneous integrations, and take it for granted. Yet (apologies again
to Monty Python) nobody expects the spontaneous integration. I posed three questions on my Weblog, which I'll briefly answer
here.
1. Why was this unexpected?
Because we think coordination of distributed resources has to be hard. The Web keeps showing us how it can be easy, but
we never quite believe that. We invent fancy remote-procedure-call technologies and forget to make them document-oriented
and URI-addressable -- an oversight that is now, happily, being corrected[5].
2. In what environment would it be taken for granted?
In this case, the conditions for easy integration came about purely by accident. Many (but not all) book sites expose URLs
that use ISBN numbers. Many (but not all) online library systems can query by ISBN. In a truly service-oriented world, that
kind of thing won't be an accident. We will all understand, viscerally, that every Web application is also a service. Sometimes
we'll spell out formal protocols, but always we'll consciously use simple affordances (like the ISBN in the URL) with an eye
toward integration.
3. How do we create that environment?
If you're reading this column, you're probably as jazzed about XML Web services as I am. So we would probably agree that
every Web application ought to be built on an XML framework. And that when the user interface is HTML-based, the HTML should
be a transformation of a repurposable XML core. And that the engine powering that core should make its services SOAP-callable
and (where possible) URI-addressable.
But when push comes to shove, we will still tend to fall back on tried-and-true methods: a conventional app server, HTML
templates. That doesn't mean, though, that we can't anticipate and encourage recombinant growth[6]. For starters, use HTML
doctitles wisely. Libraries that futzed this vital bit of metadata missed a chance to be included in an ad-hoc directory.
Design your URL patterns as though you are designing an API -- which, in fact, you are. And here's a great transitional tip.
If you can't offer up self-describing XML content, at least use CSS tags to assign structural names, as well as style names,
to key data elements.
Web apps can't help but be proto-services, whether you plan for it or not. Expect, and encourage, unintended use.
1.
http://weblog.infoworld.com/udell/2002/12/17.html#a547
2.
http://www.drizzle.com/~lostboy/binaries/Spanish.wav
3.
http://weblog.infoworld.com/udell/2002/12/10.html#a535
4.
http://weblog.infoworld.com/udell/stories/2002/12/11/librarylookup.html
5.
http://www.infoworld.com/articles/op/xml/02/11/07/021107opwebserv.xml
6.
http://weblog.infoworld.com/udell/2002/12/12.html#a537
E-mail
Printer Friendly
Reprints
(InfoWorld) - In the litigious world we live in, deploying a unified communications platform in your enterprise could...
