The browser as orchestrator

It’s been a busy week for my LibraryLookup project, which first 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 catalog. 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.

Free IT resource Open Source Business Conference (OSBC) May 22-23, 2007 Sponsored by OSBC Free IT resource Virtualization Insights from Top Experts - Learn how virtualization gets real! Sponsored by Dell

LibraryLookup’s failures were equally instructive. As are other kinds of Web apps, library catalogs 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 catalog vendors provide one, there are a number of others that still don’t.

The information architecture of the book world was another cause of failure. ISBNs 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 catalog. On my blog, I wished for a service that would unify these variants, and about a year ago, the Online Computer Library Center 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 back burner 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 catalog 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 Weblog. Here, I’ll just summarize 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.