Library Technology Guides

Document Repository

Smart Libraries Newsletter

Ex Libris Sets Strategic Course on Open Systems

Smart Libraries Newsletter [August 2008]

Image for Ex Libris Sets Strategic Course on Open Systems

In the current phase of the library automation industry, open source software has a large following. Some companies that offer products with a closed source licensing model have developed their own ways to respond to the popularity of more open systems. Releasing source code to software is only one of many approaches to give libraries more control of their data and more flexibility to extend the functionality of the software.

Ex Libris specializes in automation products, primarily aimed at academic and research libraries, and has a large base of customer libraries throughout the world. In June 2008, Ex Libris announced that it had launched what it calls an "open-platform program" formalizing and expanding its commitment to deliver its products and services in a more transparent approach.

The route that Ex Libris has chosen involves creating application programming interfaces (APIs) that provide access to the data and functionality for each of its products. This isn't an entirely new effort. The company has a longstanding practice of developing APIs for its major products. This strategic initiative extends and formalizes these efforts and provides an environment for the users of its products to share and collaborate in their use of these APIs.

The company currently offers APIs for many of its products. Ex Libris designed its ALEPH 500 integrated library system to support APIs from its initial design, culminating in an X-Services layer as internet protocols and Web services emerged as the preferred approach for implementing APIs. The company's MetaLib federated search platform and SFX OpenURL link resolver both include XML APIs. DigiTool, Primo, and Verde use SOAP (Simple Object Oriented Protocol), an industry-standard approach for Web services. One of the major features of the recently released Voyager Version 7 involves the creation of a suite of Web services.

Ex Libris isn't the only company offering APIs for its library automation products. Unicorn, from SirsiDynix, for example, has offered a comprehensive API since 1995. (See Library Systems Newsletter November 1995) The Open Platform Program will expand the company's commitment to open APIs, going beyond the APIs for its separate products and working toward a more consistent and comprehensive set of APIs that spans its product family. The program includes a commitment to provide documentation for the APIs. Ex Libris will facilitate their use through establishing the "E L Commons" a site that hosts where developers at customer sites can access the documentation for the interfaces, upload components that they have built using the APIs, or download those created by others.

Tamar Sadah, Ex Libris' director of marketing, will lead this program and coordinate resources from the company and customer sites. Revital Marck, currently Aleph development manager, will guide the company's efforts to offer APIs that expose services across all of its products following a more consistent and comprehensive set of standards. The company states that it aims to instill a culture of openness in the way that it develops and supports its products.

Open APIs versus Open Source

For a company like Ex Libris which has products implemented in thousands of libraries around the world, developing APIs stands as a more practical alternative than opening their systems and moving to open source licensing. Allowing its source code to be changed by anyone might not work effectively as a sustainable strategy for ongoing development.

Ex Libris develops products for complex libraries and may not necessarily be well suited for open source development. The coordination involved in version control and the possibilities for forks in the code base could yield more difficulties than they would solve. A robust set of APIs offers customer sites the ability to access data and extend functionality without providing access to the source code of the core business applications or altering the business terms involved in licensing the products.

The key difference in the open platform strategy as described by Ex Libris and the open source model involves allowing programmers outside of the company's own development staff to work. In the open source model, customer sites gain access to the program code from which the core applications are created.

Open source licensing allows libraries with their own programming staff to inspect the code and make changes that alter its functionality. It also allows other companies or organizations to develop and support the software and possibly create competing versions. It's possible to follow a development model where the core products remain proprietary, while creating APIs that give user software the ability to access the underlying data and functionality.

If a software developer creates an API, others can write their own reports, scripts, or other components to extend or replace the functionality of the original application. Open APIs allow customer sites to write scripts that interact with the product without gaining access to the original source code. Depending on the completeness of the APIs offered, programmers can often achieve the same kinds of results with open APIs more effectively than would be possible by reprogramming the source code, thus altering the core product.

Today, claims of openness abound. It's a challenge for libraries to look beyond marketing claims to the approach that best meets their needs for flexibility. This arms race of openness benefits libraries to the extent that it results in more options and flexibility in their own automation strategies. The open source movement and programs such as Ex Libris' open platform strategy provide competing alternatives with similar goals.

APIs Explained (Sidebar)

Application Programming Interfaces involve a layer of software that allows external systems to gain access to the data and functionality of an application. APIs can be implemented in a number of ways. They can use their own proprietary interface, or they can follow standard protocols such as Web services. Common flavors of Web services include SOAP (Simple Object Access Protocol) and REST (Representational State Transfer). APIs provide hooks into proprietary systems allowing external systems to access data and functionality.

While the availability of APIs provides an additional option for libraries that want to do more with their automation systems, it does not get in the way for those libraries that want to run the software as delivered.

To be useful, the developers of the product must produce documentation for the APIs, which give detailed instructions for programmers regarding what inputs each procedure within the API requires and what results should be expected.

A number of APIs have been defined for library automation products that most automation systems have implemented. These include some of the familiar standard protocols:

  • Z39.50, which provides a standard interface for search and retrieval
  • SRU/SRW, a Web services approach to a subset of Z39.50 search and retrieval functions
  • SIP2 and NCIP which provide access to selected ILS functions related to patrons and items. These protocols were designed to allow third party self-check systems, interlibrary loan and resource sharing systems to interact with library automation systems through a standard interface
  • OAI-PMH (Open Archives Initiative Protocol for Metadata Harvesting) provides a standard approach for the wholesale transfer of bibliographic records out of a given environment. Originally developed for other types ofrepositories, this protocol has recently been proposed for the transfer of data from library automation systems to discovery-layer interfaces.

Although protocols like these provide some degree of access into the functionality and data subsumed within library automation systems, the represent a fairly small portion of the overall data sets and functionality. Support for these protocols provides some openness for a library automation system, but not at a comprehensive level. APIs can fill in the gaps not addressed by the standard protocols.

Ideally, other standard protocols may eventually emerge that address a more comprehensive view of the data and functionality of library automation systems. In the meantime, system developers can create their own APIs that expose data and services.

View Citation
Publication Year:2008
Type of Material:Article
Language English
Published in: Smart Libraries Newsletter
Publication Info:Volume 28 Number 08
Issue:August 2008
Publisher:ALA TechSource
Place of Publication:Chicago, IL
Company: Ex Libris
Record Number:13434
Last Update:2023-01-25 11:33:32
Date Created:2008-08-03 13:45:18