The Internet is evolving towards a service infrastructure: a network of rich, robust, and often professionally maintained services that are conveniently accessible to people through the web. However, the fact that these services rely on the web to present their content effectively restricts their users to be human; the lack of structure and well-defined types in web content makes it all but impossible for computer programs to interact with most Internet services, despite the obvious benefits of being able to do so (such as service composition, richer search and information access services, etc.). Several recent efforts have attempted to introduce such structure and typing to the web, such as the WIDL [12] and WebL projects [16], or the ongoing W3C XML developments [6].
The UC Berkeley Ninja project
is pursuing a complementary path to
these efforts: we are building an infrastructure for supporting fault
tolerant, highly available, scalable services composed of a number of
well-circumscribed components, each of which exports a strongly-typed,
programming-language level interface [10] accessible
using RPC-like mechanisms [4]. Explicitly exposing service
interfaces and making use of strong typing has a number of benefits,
including forcing authors to carefully design the boundary between their
services and the rest of the world, making those services accessible to
programs, and allowing the composition of services by infrastructural
elements. We believe that when a large number of such services are
deployed, a network-externality effect will occur, causing the power of an
individual service to be greatly enhanced by interaction with the many
other available services.
In this paper, we describe one such service: the Ninja Jukebox. The Jukebox allows a community of users to collaboratively build a distributed music repository out of both music CDs and MP3 files stored in local filesystems, and to use simple collaborative filtering to allow individual users to filter their music preferences according to other community members' explicit and implicit recommendations. In section 2, we discuss the design rationale that went into the Ninja Jukebox, and reflect on how the Ninja project's service philosophy influenced this design. Section 3 describes our Java-based Jukebox implementation and how we smoothly evolved it, and section 4 presents some of the limitations of our implementation and the lessons we learned while building it. Finally, in section 5, we present related work.