Why would a library systems vendor (like Talis) want to help produce an open source toolkit to enable library systems to present data as web services? In short, we believe the following:

Systems should be open to their users.

Talis recognises that library system technicians want to be able to access the data in their LMS/ILS on their terms. Many organisations have in-house developers who are acutely aware of their organisation's requirements, and need to be able to integrate LMS/ILS data with internal systems (e.g. portals, intranets). Traditionally, library systems have provided this facility at a price (e.g. buying an add-on web services module), or provided only minimal, primitive tools for accessing library data (e.g. text file dumps).

Where web service APIs exist for a product, they are often difficult to invoke (e.g. requiring knowledge of SOAP), and return data in arcane or proprietary formats. This makes it difficult to build client software, and difficult to integrate data across systems.

The aim of Jangle is to help standardise user-friendly APIs for library web services: both for the format of requests to those services, and the format of responses. Talis has pioneered simple, usable web services with the Keystone product, and is using the TalisSOA framework behind this product to seed Jangle.

Talis also stands to benefit from this, as we frequently work with other vendors on integration projects. By standardising library APIs across systems, we hope to make integration tasks less costly for ourselves and our clients.

Activity

Jangle project activity will proceed on two fronts:

1. Producing an approachable framework for fronting an ILS with RESTful web services, delivered over HTTP. We make this deliberate simplification (no alternative transports, no SOAP) to make writing your own Jangle Connector as easy as possible. Although Jangle is written in Ruby, we also aim to provide a framework for integrating other languages with Jangle (e.g. ways to wrap Java classes so that they are accessible via Jangle's REST components, ways to front other web services, ways to integrate with scripting languages, ways to incorporate batch imports of data).
2. Producing discussion, schemas and documentation for real-life, generic, usable XML output formats for RESTful responses. We want library APIs to standardise around some core schemas which capture the data common to any library system, so we can start to move away from vendor-specific formats. At the same time, we want Jangle to be able to transform those standard, generic formats to industry standard ones (if they emerge), if and when this is required.