It’s been a busy week for my LibraryLookup project, which was launched in December 2002. In its original and still most widely deployed incarnation, LibraryLookup is a JavaScript bookmarklet that connects an Amazon book page to the corresponding record in a library catalogue. The success of this technique got me thinking about themes I’ve pursued ever since: the dynamics of user-driven innovation, the protean flexibility of RESTful (Representational State Transfer) web applications and the dynamics of lightweight service orchestration. LibraryLookup’s failures were equally instructive. Like other kinds of web apps, library catalogues weren’t (and mostly still aren’t) designed for this kind of integration. It doesn’t require much, just an unencumbered search URL. Although some catalogue vendors provide one, sereral still don’t. The information architecture of the book world was another cause of failure. ISBNs (international standard book numbers) don’t uniquely identify books; there’s one for each hardcover and paperback edition, so the ISBN number in your browser had to match the one you looked up in the catalogue. On my blog, I wished for a service that would unify these variants and about a year ago the Online Computer Library Centre granted my wish. It deployed an experimental service called xISBN that maps a book’s ISBN to the whole set for that book. Although a bookmarklet can splice a pair of services together, it can’t combine three or more services without relying on some kind of external orchestrator. That was more than I wanted to build and support, so the project was relegated to the backburner for a while. This week, however, I recalled that I already had one kind of orchestrator in place. It connects my Amazon wish list to my RSS reader, by way of a library catalogue lookup. If a book isn’t available in the library when I’m visiting the Amazon page, but later becomes available, I’m notified via RSS. The orchestrator in this case is just a Python script that’s scheduled to run daily. It was easy to extend it to use xISBN, so I did. I had earlier shown this RSS notifier in a screencast about client-side intermediation. There I also showed a Greasemonkey script that rewrites an Amazon book page on the fly when it finds that book in the library. Could the Greasemonkey script also be extended to orchestrate a collection of services? Yes, and you can find the gory details on my blog. Here, I’ll just summarise my conclusions. First, I’m bullish on client-side intermediaries and orchestrators. For me, at least, this is the AJAX (Asynchronous JavaScript and XML) endgame. Service composition in the browser can, and will, nicely complement service composition in the cloud. I’ve done it at the WS-Light end of the tolerance continuum; Tibco General Interface shows it can be done at the WS-Heavy end as well. AJAX and BPEL aren’t in bed together yet but mark my words, it’ll happen. Second, I’m cautiously optimistic about the future of the kinds of advanced web standards that can make this stuff really sing. The latest W3C APIs all worked well in Firefox 1.0 and they work even better in 1.5. Meanwhile the once-frozen Internet Explorer has thawed and is on the move again. I don’t know how far Microsoft will allow IE to go, but the Windows Live initiative gives me hope that the full power of the standards-based web client may yet be unleashed.
Web-to-library interfacing: the hard facts
It's not as easy as it looks, says Jon Udell