Jon Udell's LibraryLookup gets xISBNified and more

We now return to our regularly scheduled technology boosterism :)  Now featuring extra jargon!

Jon Udell's LibraryLookup was an inspired idea about "living where your users are" - finding ways to link from online resources your patrons are already using, like Amazon, into your library's holdings.

It was his original work that inspired a lot of the library Web Browser Extensions that are now available.

Before I get into his article, here's a Terminology Watch: workflow is hot.  The ability to compose, or orchestrate services, is an essential element of Service-Oriented Architecture (SOA).  It is a key element of advanced software engineering practices.  (In the context of Web Services, WS-BPEL runs on a controlling server in order to do the orchestration.)

LISnews pointed me to Jon Udell's latest thinking, published in InfoWorld: 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.

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 [problem]. 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.

The blog entry is Further adventures in lightweight service composition.

I normally avoid posting and dissecting code here, but I broke the rule last Thursday and will again today because my latest round of LibraryLookup work highlights interesting opportunities for service composition at the tolerant end of the tolerance continuum. Last week's adventure was a lightweight service orchestration that connects Amazon's wishlist to RSS, by way of the OCLC xISBN service and a local library catalog. Among other things, that composite solved a longstanding problem with LibraryLookup: an ISBN identifies just one manifestation of a work -- e.g., paperback versus hardcover -- not all of them.

The OCLC's xISBN service goes a long way toward solving this problem. Feed it one ISBN, and it returns a cluster of related ISBNs. A couple of years ago, when OCLC first announced xISBN, there was no way LibraryLookup bookmarklets could exploit it directly. An external intermediary was needed. And in fact that's still true, because bookmarklets can't handle multi-step service orchestration.

The RSS notifier I showed last week isn't subject to that constraint. It can be implemented in any general-purpose programming language, and deployed on any machine with Internet access and the ability to schedule periodic batch jobs.

The next logical step was to add xISBN capability to the Greasemonkey-based version of LibraryLookup that's shown (along with wishlist/library-availability notification) in the screencast Content, services, and the yin-yang of intermediation. In theory this should have been a snap. I already had a Greasemonkey script that was calling one service -- the library catalog -- using the keystone of AJAX, XMLHTTPRequest. How hard could it be to add a second service to this application?

Harder than I thought, as it turned out.

...

Anyway, here's the script. If you adapt it for your OPAC, let me know. The coolest way to let me know would be to tag it in del.icio.us (or elsewhere) with librarylookup, greasemonkey, and xisbn. Similarly, if you adapt Thursday's wishlist notifier, it would be cool to tag it with librarylookup, wishlist, and notification. That'll make it easy to collect a range of implementations and consider how best to generalize them.

The wishlist notifier post is Adventures in lightweight service composition.

Three years after I started the LibraryLookup project, people are still regularly discovering and enjoying the ability to automatically broker a connection between Amazon (or another book site) and their local libraries. In a screencast entitled Content, services, and the yin-yang of intermediation I showed a more advanced version of the conventional bookmarklet: a Greasemonkey script that modifies an Amazon page to include a notice about the book's availability in my local library. The screencast ends with a demonstration of another kind of connection brokering. If a book isn't available at the library, I add it to my Amazon wishlist. Then, when it becomes available at the library, it shows up in a special RSS feed that watches my Amazon wishlist.

It's a great example of lightweight service composition. Recently I was reminded that I'd never published the code, so I've included it below. This small Python script orchestrates three different services. First, it queries the Amazon wishlist by way of Amazon's API. Second, it queries the OCLC's xISBN service [1, 2] to convert the single ISBN into a cluster of related ISBNs. Third, it queries my library's OPAC system for each of those related ISBNs.

Previously:
April 28, 2005  library interfaces that live where your users are: handling changes
April 04, 2005  Jon Udell screencasts about library web rewriting