Coordination of distributed resources doesn't have to be hard 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. https://weblog.infoworld.com/udell/2002/12/17.html#a547 2. https://www.drizzle.com/~lostboy/binaries/Spanish.wav 3. https://weblog.infoworld.com/udell/2002/12/10.html#a535 4. https://weblog.infoworld.com/udell/stories/2002/12/11/librarylookup.html 5. /articles/op/xml/02/11/07/021107opwebserv.xml 6. https://weblog.infoworld.com/udell/2002/12/12.html#a537 Software Development