Opening Up Library Systems Through Web Services and SOA Hype, or Reality?. 9780838958063, 0838958060

Citation preview

MEET THE NEW! FACE OF ALA TechSource Online Ć
Access a growing archive of more than 8 years of Library Technology Reports (LTR) and Smart Libraries Newsletter (SLN) Ć
Read full issues online (LTR only) or as downloadable PDFs Ć
Learn from industry-leading practitioners Ć
Share unlimited simultaneous access across your institution Ć
Personalize with RSS alerts, saved items, and emailed favorites Ć
Perform full-text searches

Library Technology R

e

p

o

r

t

November/December 2009 vol. 45 / no. 8 ISSN 0024-2586

s

Expert Guides to Library Systems and Services

www.alatechsource.org

a publishing unit of the American Library Association

FREE SAMPLES @ alatechsource.metapress.com

LIBRARY TECHNOLOGY UNCOVERED, EXPLORED, ONLINE

Subscribe to TechSource Online today! alatechsource.metapress.com

Your support helps fund advocacy, awareness, and accreditation programs for library professionals worldwide.

ISBN 978-0-8389-5806-3

9 780838 958063

Opening Up Library Systems through Web Services and SOA: Hype, or Reality? by Marshall Breeding

Library Technology R

e

p

o

r

t

s

Expert Guides to Library Systems and Services

Opening Up Library Systems through Web Services and SOA: Hype, or Reality? Marshall Breeding

www.alatechsource.org Copyright © 2009 American Library Association All Rights Reserved.

About the Author

Library Technology R

e

p

o

rt

s

American Library Association 50 East Huron St. Chicago, IL 60611-2795 USA www.alatechsource.org 800-545-2433, ext. 4299 312-944-6780 312-280-5275 (fax)

Advertising Representative Brian Searles, Ad Sales Manager ALA Publishing Dept. [email protected] 312-280-5282 1-800-545-2433, ext. 5282

ALA TechSource Editor Dan Freeman [email protected] 312-280-5413

Copy Editor Judith Lauber

Administrative Assistant Judy Foley [email protected] 800-545-2433, ext. 4272 312-280-5275 (fax)

Marshall Breeding serves as the Director for Innovative Technology and Research at the Vanderbilt University Libraries in Nashville, Tennessee. He has authored several previous Library Technology Report issues: “Electronic Se­curity Strategies for Libraries,” “Strategies for Measuring and Implementing E-Use,” “Integrated Library Software: A Guide to Multiuser, Multifunction Systems,” “Wireless Networks in Libraries,” “Web Services and the Service-Oriented Archi­tec­ ture,” and “Open Source Integrated Library Systems.” Breeding is also a contributing editor to Smart Libraries Newsletter, published by ALA TechSource, and has authored the feature “Automated Systems Marketplace” for Library Journal for the last six years. His column “Systems Librarian” appears monthly in Computers in Libraries magazine. A regular on the library conference circuit, Breeding frequently speaks at Computers in Libraries, Internet Librarian, and other professional gatherings throughout the United States and internationally. He is a regular panelist on the LITA Top Technology Trends panel at the ALA Annual and Midwinter conferences. Breeding created and maintains the Library Technology Guides Web site at www.librarytechnology.org. For more information or to contact the author, see http://staffweb.library.vanderbilt.edu/ breeding.

Production and Design ALA Production Services: Troy D. Linker and Karen Sheets de Gracia

Library Technology Reports (ISSN 0024-2586) is published eight times a year (January, March, April, June, July, September, October, and December) by American Library Association, 50 E. Huron St., Chicago, IL 60611. It is managed by ALA TechSource, a unit of the publishing department of ALA. Periodical postage paid at Chicago, Illinois, and at additional mailing offices. POSTMASTER: Send address changes to Library Technology Reports, 50 E. Huron St., Chicago, IL 60611. Trademarked names appear in the text of this journal. Rather than identify or insert a trademark symbol at the appearance of each name, the authors and the American Library Association state that the names are used for editorial purposes exclusively, to the ultimate benefit of the owners of the trademarks. There is absolutely no intention of infringement on the rights of the trademark owners.

www.alatechsource.org www.alatechsource.org Copyright ©2009 American Library Association All Rights Reserved.

Abstract Over the last few years, Web services and the service-oriented architecture (SOA) have become dominant themes in IT across many industries. Web-based computing, serviceorientation, and cloud computing increasingly displace the client/server approach favored by libraries in the past. In library automation, one major trend involves evolving or rebuilding automation systems to adopt this new approach to software. Purveyors of both open source and proprietary library automation products increasingly emphasize the ways in which they embrace openness, support application programming interfaces (APIs), or implement Web services. Libraries increasingly need to extract data, connect with external systems, and implement functionality not included with the delivered systems. Rather than relying on the product developers for enhancements to meet these needs,

Subscriptions For more information about subscriptions and individual issues for purchase, call the ALA Customer Service Center at 1-800-545-2433 and press 5 for assistance, or visit www.alatechsource.org.

Table of Contents Chapter 1—Introduction

5

Scope Intended Audience of This Report Why Should Libraries Care about Application Programming Interfaces? Possibilities Abound Basic Concepts API Implementation Models What Is an API? Proprietary APIs APIs and Open Source Standards as Open Interfaces API Security Terms of Service With Power Comes Responsibility and Cost No Universal Expectation for APIs

Chapter 2—Vendors and Products   Case Studies and Customer Responses Ex Libris Duke University Libraries Broome Community College University of Tennessee National Library of Australia Evergreen The Library Corporation Innovative Interfaces Koha Polaris SirsiDynix Talis VTLS Notes

Chapter 3­—API Hype and Reality Conclusions

Resources

6 6 6 7 8 9 11 12 12 13 13 13 14 14

15 15 18 19 20 21 21 23 25 28 29 31 34 36 37

39 41

42

Abstract (cont.)

libraries increasingly demand the ability to exploit their systems using APIs, Web services, or other technologies. The demand for openness abounds, particularly in libraries that exist in complex environments where many different systems need to interact. As libraries develop their IT infrastructure, it’s imperative to understand the

extent to which their automation products are able to interoperate and thrive in this growing realm of Web services. This report aims to assess the current slate of major library automation systems in regard to their ability to provide openness through APIs, Web services, and the adoption of SOA. 3

Chapter X 1

Introduction

Abstract

I

n the current phase of library automation, we’ve become inundated with the language of openness. Open source integrated library systems (ILSs) have emerged, promising to give libraries more control over their software than has been possible with proprietary, closed-source products. Companies that produce and provide service for proprietary products have redoubled their efforts to offer more flexibility, openness, and interoperability through Web services and other application programming interfaces (APIs). A new front has developed in the competition among library automation alternative vendors, who are racing to open up software and allow libraries more access to their data and internal functionality. This new emphasis on openness can be a great benefit to libraries to the extent it that it actually offers new capabilities otherwise not available. Still, as implied by the title of this issue, it’s often difficult to distinguish products that fully embrace openness from those where the claims don’t quite match reality.

Opening Up Library Systems through Web Services and SOA: Hype, or Reality?  Marshall Breeding

Library Technology Reports  www.alatechsource.org  November/December 2009

In recent years, companies involved with both open source and proprietary integrated library systems (ILSs) have made a concerted effort to increase the openness— that is, the degree of flexibility and interoperability— that their products offer to librarians and programmers. This chapter of “Opening Up Library Systems through Web Services and SOA: Hype or Reality” explores this dynamic in the current ILS market. By taking a general look at what characteristics and functionality librarians seek in their software and defining key terms, this chapter sets the stage for an in-depth exploration of the modern ILS trend towards APIs, Web services, and the service-oriented architecture.

In today’s environment, systems that are perceived as being “closed” have diminished appeal. It sure sounds better to characterize an automation system as “open” and flexible, but what do the terms really mean? We will explore some of the techniques that provide increased access to data and internal functionality, focusing especially on Web services and other application programming interfaces. Many libraries might say that they do not want a “black box” system that restricts users to the functionality in the interfaces provided by the vendor, with no access to the internals of the system. Yet many libraries need a turnkey system that helps them carry out their work without the need for any local programming or intervention. We should emphasize that APIs offer additional opportunities for those that want to do more with their software, but do not impose any technical requirements for libraries that choose not to use them.   When it comes to the purveyors of proprietary software, claims of openness are also everywhere. The emphasis on openness may have been accelerated by the open source movement, but it has been a steady theme for many years. Press releases and product literature gush with the language of openness. The means to this openness are the adherence to standards and Web services and other application programming interfaces. This report aims to take a close look at the major ILS products on the market and describe the approach that each offers in delivering open access to its data and functionality. Of particular interest are the APIs that each system offers to the libraries using its product. We will describe and evaluate their scope and comprehensiveness and observe the extent to which each product offers these APIs through Web services, the preferred approach in the current phase of information technologies.

5

Libraries have varying expectations when it comes to what they want from their automation products. Many simply want the system to function as documented, using the interfaces and reports delivered with the system. Some ILS products target libraries that expect basic functionality without the expectation of local programming. The products in this category serve a vital role in the library automation arena. Libraries expecting to work with their systems through local programming should be clear on which products offer this capability and which do not.

Library Technology Reports  www.alatechsource.org  November/December 2009

Scope

6

This report focuses on integrated library systems, the core business application used to automate the work that takes place in libraries and to provide access to their collections and services. Libraries make use of many different software components, such as discovery interfaces, link resolvers, federated search tools, digital collection management systems, and institutional repository platforms. Although many of the same questions apply to other genres of software, those lie outside the scope of this report. We further narrow the scope to the ILS products widely used in the United States by the kinds of libraries likely to have an interest in extensible systems. The types of libraries in this category would include large research libraries, municipal and large public library systems, and national libraries. The specific systems examined will include those from Ex Libris, Innovative Interfaces, SirsiDynix, VTLS, Polaris, and The Library Corporation, as well as Koha and Evergreen, which are widely adopted open source ILS products. Even though Talis does not market its ILS in the United States, it has been an active proponent of this approach and warrants inclusion.

Intended Audience of This Report This report aims to provide useful information to anyone involved with automation products in a library context, especially those involved with defining or implementing technology strategies. Library administrators will find information, presented in clear, nontechnical language, that will help them understand some of the options to extend and enhance their automation environment. These extensions relate to extracting and manipulating data in ways that will support management decisions, allowing the library’s computer systems to work together more efficiently and to better connect with the information systems of the broader organization. For library administrators and other nontechnical professionals, this report will provide information and context to help understand the claims and counterclaims of open source and proprietary software proponents.

Developers and other technical staff may already be familiar with many of the concepts explained in this report, but should find the examinations of how different APIs have been implemented in particular products to be of interest. Systems librarians, Web developers, and others ready to extend their activities to include programming with the library’s ILS or other key infrastructure components will learn basic concepts and the realm of tasks that can be accomplished using these interfaces. Developers outside the library industry who may be involved with libraries will find important information on the integration capabilities offered by the major library automation products. Librarians and other library workers not directly involved with technology will benefit from understanding the concepts involved since this is an area of technology that has a direct impact on the information environment of the library and the information and functionality that supports their work. The ability to work with library automation software through an API benefits some types of libraries more than others. Those involved with larger and more complex library organizations will have more opportunities to take advantage of the APIs and other integration technologies covered in this report. The key target organizations include academic libraries of all sizes, large and medium-sized public libraries, special libraries supporting large organizations, and national libraries. These libraries generally operate a variety of information systems within their enterprise networks, with interdependencies that often cannot be realized by out-of-the-box functionality. The libraries require custom programming to get what they need out of their software. Smaller libraries tend to use automation products as delivered by their developers, increasingly as a hosted service, and may have fewer needs that require programmatically extending the functionality. Smaller libraries are also less likely to have the technical staff to implement these capabilities.

Why Should Libraries Care about Application Programming Interfaces? The integrated library system, or ILS, provides the essential automation infrastructure for a modern library and represents one of the largest technology-related investments that a modern library makes. Libraries select from a variety of major products on the market, including both proprietary and open source flavors. Each library brings a unique set of expectations and requirements to the table as it implements its ILS. Through a careful selection process, the library will identify the system best suited to its fundamental requirements. Yet no prepackaged automation system will completely satisfy

Opening Up Library Systems through Web Services and SOA: Hype, or Reality?  Marshall Breeding



Interoperability. For many libraries, a key concern lies in their ability to make the ILS communicate effectively with other computer systems. The more that a library exists within an organization that makes use of multiple information systems, the more that it needs an ILS that can interact with those other systems. In such a context, an ILS that cannot interoperate with other systems functions as an isolated silo that may not support the library’s organizational and business needs. To a large degree, interoperability can be achieved through adherence to applicable national and international standards. Yet standards do not necessarily address every possible aspect of the way that a library might need its ILS to interact with other business or information systems. APIs pick up where standards leave off, allowing libraries to create interoperability that cannot be achieved in other ways.



Extensible. An ILS embodies a specific set of fea-

tures and functions that are needed to automate the internal operations of a library and provide its users with access to its collections and services. The set of features in a given ILS will continue to evolve over time in response to the ongoing enhancement requests that emerge from the libraries that use the software and from the development agenda of its developers. Many libraries have specific automation needs not fulfilled by their ILS. These needs may not be shared by other libraries that use the software, making them unlikely candidates for the normal enhancement process. An extensible system allows the ILS to enhance its functionality without the intervention of the programmers that created it. APIs provide one of the most important vehicles for extending an ILS according to the needs of a given library.

Vendor independence. The presence of a robust API can help reduce a library’s dependence on the organization that created and supports the ILS. With a closed system, only the vendor can make changes to the system to extend its functionality. An API provides a library with the ability to create customized functionality without the intervention of its developers. This capability enables the library to have more flexibility; it is less hampered by an unresponsive vendor and can accomplish tasks with its own staff that otherwise might require paid custom programming from the vendor. The degree of independence gained by the ability to take advantage of an API isn’t absolute. The library continues to be dependent on the product’s developers to maintain the product. If the company goes out of business or withdraws the product, the programming invested may or may not be transferable to another ILS.

Possibilities Abound To help readers visualize why it’s important for an ILS to offer an API, some of the tasks that can be accomplished might include:

OPAC replacement or enhancement. One of the

ma­-jor trends today involves the transition from traditional online catalogs to new-generation discovery interfaces. These new products often come from sources other than the developer of the ILS, but thoroughly rely on the ability to extract data from and communicate in real time with the ILS. It’s through APIs that it becomes possible for a third-party discovery interface to work seamlessly with the ILS.

Opening Up Library Systems through Web Services and SOA: Hype, or Reality?  Marshall Breeding

Library Technology Reports  www.alatechsource.org  November/December 2009

all of the nuanced needs of every library. Equipped with an API, libraries with their own programmers have the option of creating functionality that fills in the gaps between the system as delivered and their specialized requirements. Library automation systems increasingly operate within a broader context of information systems. Espe­ cially in larger organizations, the ILS needs to communicate with a variety of other business applications. Any ILS comes as a complete package designed to present a broad set of features and functionality through the user interfaces delivered with the system. These user interfaces, whether presented through a Web browser or implemented through a graphical Windows, Java, or Macintosh interface, allow human users to interact with the software, searching for resources, performing transactions, extracting reports, or carrying out other business functions. In selecting a system, a library measures the completeness of that system in terms of what can be accomplished through these user interfaces. The user interfaces provided with the ILS are the products of the people who develop the system. While some aspects of the user interface can be adjusted by the configuration options selected by the library, the basic functional capabilities cannot be altered except by those involved in the development of the software. While many libraries find the functionality delivered with the ILS to meet their automation needs, others benefit from the ability to perform tasks beyond that of the delivered software. A robust and well-documented set of APIs empower the library to perform tasks with the ILS and the data it manages that go beyond the delivered system. APIs associated with an integrated library system enable interoperability, make its functionality extensible, and empower the library to be more independent of the organization that created the software:

7

Many libraries need to enhance their existing online catalog in ways beyond the standard configurations that are offered. The display of book jackets, summaries, or reviews can be layered onto catalog pages using an API. It’s of increasing interest to embed library content and services in external Web pages and portals. A flexible set of APIs in the ILS, especially in the form of Web services, will help support these capabilities.

Connectivity with self-check and automated materials handling equipment. The ability to take

advantage of self-service and other external automation systems may be enhanced through APIs. Much of this connectivity is addressed in SIP2 and NCIP protocols, but libraries may also be able to enable additional efficiencies if they are able to supplement these protocols through other APIs.

Library Technology Reports  www.alatechsource.org  November/December 2009



8

Single sign-on and authentication services. A key

problem that many libraries face involves how their users sign in to their various applications. Given the multitude of systems, it’s important to have some means of consolidating the function that controls how users sign in. It may involve configuring the ILS to rely on an external authentication service, or it may mean the ILS functioning as an authentication service for external application. Either way, the ILS must support the APIs associated with authentication, such as LDAP, ActiveDirectory, Kerberos, or Athens.

Financial system integration. Many libraries need

to be able to exchange financial information with other business systems in their institution. Procurement and fund management tasks that take place in the acquisitions module of the ILS often need to be transferred to an enterprise resource planning (ERP) program (a genre of software that large organizations use to manage their financial data across different units) or other accounting systems for payment. In academic libraries, fees incurred in the library may need to be transferred to a bursar’s office for collection through the student’s institutional account. Some libraries may want to offer online payments though through their own or though their institution’s site using third-party e-commerce products.

Detailed reporting. Although all ILS products come

with reporting modules that generally include the ability to produce customized reports, they may not have the ability to address all aspects of data managed within the ILS. Many libraries are able to use an API to extract data in ways not possible through standard reports.

These tasks represent only a few of the possibilities. Equipped with a well-developed API, a library should be able to respond to a wide variety of needs that arise involving some aspect of information managed within its ILS.

Basic Concepts This report focuses on techniques for providing libraries more open access to their core automation systems. The key approach that we will explore is the application programming interface, or API. In today’s technology environment, the preferred implementation of an API is through Web services, which takes advantage of the protocols, structures, and technologies that support the Web. Systems formed entirely out of Web services and that follow a particular set of organizational principles can be said to follow a service-oriented architecture, or SOA. One of the most important concepts to understand about an API is that it involves computer-to-computer interactions. Not to be confused with the user interface offered for humans, the applications programming interface involves allowing one computer system to interact with other computer systems. As an application programming interface, it involves programmers. Those libraries lacking technical staff capable of at least some software programming will not work with the APIs directly. Libraries without programming staff may benefit indirectly through capabilities executed on their behalf by third parties. Some systems may have internal APIs designed for the developers of the system, but these APIs may not be packaged in a way that makes them accessible to the personnel in the libraries that use the system. The presence of APIs within the internal system framework designed for use by the software engineers that program the application itself may not be palatable platforms that will help the personnel in the libraries that use the software customize it and maximize its capability. While the use of internal APIs reflects modern software design, we’re primarily concerned with APIs designed to be used by the libraries that implement the software. It’s these customerfacing APIs that directly benefit libraries using the software, more so than the APIs that are geared more for use by those involved with developing the application itself. A customer-facing API needs to be largely abstract from the internal workings of the underlying system. It should offer high-level operations that do not require detailed knowledge of the internal programming conventions within the ILS. The API should be independent of any given programming language or operating system. Most importantly, it must come with detailed documentation that provides the library programmer with adequate information on the requests supported by the API, the protocols and syntax involved, and the form of the expected response.

Opening Up Library Systems through Web Services and SOA: Hype, or Reality?  Marshall Breeding

API Implementation Models

Application Based on Internal Proprietary Programming

Delivered Interfaces

Core Software

Data Stores

Figure 1 Proprietary programming without API.

Opening Up Library Systems through Web Services and SOA: Hype, or Reality?  Marshall Breeding

Library Technology Reports  www.alatechsource.org  November/December 2009

As we approach the realm of application programming interfaces, let’s think of applications that lack this architecture and step our way through progressive levels of support. Figure 1 illustrates the most closed approach to programming. This type of application is completely selfenclosed. The software has exclusive access to any of the data involved. Whether the databases used are proprietary or based on standard relational database management systems (RDBMS) products, the customer has no access to them other than through the interfaces delivered as part of the software application. All of the functions of the software likewise cannot be accessed except through the interfaces delivered with the application for staff access or public access, or through a reports module. Whether or not an application offers an API has little to do with its completeness of functionality, sophistication, or scalability. While ILS products that target small libraries tend to be more self-enclosed, some of the legacy systems serving larger libraries might also fall into this category. The point of distinction here involves the nature of the application as entirely self-enclosed with no programmatic access to its internal data or functionality. The extent to which a system offers APIs relates, to a certain extent, to its vintage. Products designed more than five years ago may not have originally incorporated APIs in their design. As these products evolved, most have come to include APIs that expose functionality through a modern programming interface that may depend on internal proprietary programming. Any major software application developed today would be programmed in a way that would naturally involve APIs. The prevailing preferred approach to software development involves the service-oriented architecture (SOA), which fundamentally embraces the concept of

APIs in the form of reusable services. These services implement small units of work that form the building blocks of larger applications. The services may be used within the application at hand or exposed externally. Although any new automation system created today would surely be service-oriented, most applications available in the library arena predate the emergence of this approach and have to be retrofitted with service layers or APIs. The history of library automation is dominated by products that have evolved through many different cycles of software architectures; few systems built from scratch with new architectures of the prevailing age have emerged and survived. Equipping these evolved systems with APIs, especially in the form of Web services, represents one of the major factors in their forward progression. Those that fail to adapt to this expectation may find themselves less competitive as the library automation market moves forward. One of the first steps forward out of the purely proprietary programming arena was for developers to take a more abstract approach to database access. Early automated systems managed data with proprietary methods. They stored, indexed, and retrieved data in the most expedient and efficient ways possible, usually involving database functions created by the developer of the application. Since almost all applications involve various aspects of data management, the idea of continually creating this layer of functionality within the application gave way to the use of third-party database management systems. The use of a third-party database management system allowed applications developers to focus more of their resources on creating higher-level functionality and less on reinventing lower-level data-access routines. The transition from database access routines written for specific applications to third-party RDBMS products often introduced a higher level of system overhead requiring more additional memory, disk storage, and processing power. These RDBMS products offered much more advanced functionality and scalability. The use of a third-party RDBMS comes with cost implications. Products such as Oracle require a separate software license from the application software. When a library implements an ILS that uses a commercial RDBMS product, it must either purchase the level of license required or take advantage of existing site license that its organization may have acquired. The ILS vendor may also bundle the RDBMS license into its cost package. The use of proprietary databases continues to some extent in library automation systems. Two of the major ILS products, Millennium from Innovative Interfaces and Symphony from SirsiDynix, were initially developed using proprietary databases. In both cases, the company offers its system with an option to use Oracle or another major RDBMS. For libraries that do not require Oracle for other reasons, many sites choose to use the proprietary database. This option avoids additional licensing fees

9

Library Technology Reports  www.alatechsource.org  November/December 2009 10

associated with Oracle.  The proprietary databases can often deliver faster performance since they avoid much of the computing overhead associated with high-end database platforms like Oracle. The emergence of these third-party database management systems gave organizations a much more powerful way to deal with information across many different applications. An organization could assemble a set of applications for each of its business needs, each based on the same underlying database management system. This arrangement would allow the organization to perform report generation, data mining, and other tasks that span multiple software applications, even applications created by different vendors. It also would allow the organization to hire a single expert, or database administrator (DBA), to manage data across many applications. A DBA will have very specialized training in the database management platform used throughout the organization and will optimize database performance, develop data integrity and disaster recovery procedures, and provide support to other programmers and system administrators in using, extracting, and manipulating data across all the applications. Figure 2 illustrates an application where database access has been abstracted from its core business logic. The separation of the lower-level RDBMS though an API provides multiple advantages. To the extent that the application itself consistently operates through the API and avoids proprietary database-access methods, it becomes possible to support different RDBMS platforms. The database and the application can use standard connectivity protocols such as ODBC (open database connectivity) or JDBC (Java database connectivity) that allow programming code to be written independent of specific database products. Once one of these standard connectivity layers is in place, programmers can access the underlying data using SQL (structured query language), widely supported across all major database platforms. Application with Abstract Database API

Delivered Interfaces

Core Software

Data Stores Figure 2 Application with RDBMS API.

Database programming involves tradeoffs between maintaining database independence and performance. Each database offers its own APIs to take advantage of features that boost performance and extend functionality. But when an application programmer codes to these vendor-specific extensions, the code becomes tied to a single database product. As with other product categories in the tech sector, the RDBMS arena has seen massive consolidation. Many database products, such as Ingress, Sybase, Pick, Interbase, dBase, and others, have fallen away, leaving Oracle and Microsoft SQL Server as the primary database platforms used by library software. IBM’s DB2 continues to see much use in the larger business arena, but has not been a major player in library software. In the open source ILS arena, MySQL and PostgreSQL find wide use. We should note that Sun Microsystems purchased the open source MySQL product in January 2008, and database giant Oracle acquired Sun in April 2009, leaving the most widely deployed open source database in the hands of a company primarily involved with proprietary software. The abstraction of the database layer from the applications layer of the ILS provides a great opportunity for a library to gain access to data in ways not limited by the software provided by the vendor. As long as the software vendor provides the customer library access to the schema of the databases involved and minimal documentation, the library should be able to, at a minimum, extract data and create reports in any way needed. As shown in Figure 3, it is possible to expose the database API outside of the application itself. It’s also possible to modify and add records in a database though this method. These tasks require much more care, expertise, and knowledge of the software. An ILS is a very complex business system, with many interconnections among data elements. If the library modifies data in ways that interfere with any of the higher-level software, major problems can ensue. Software vendors may restrict these database operations outside their own software that change the databases. It’s also possible to have an abstract API with a proprietary database. But in practical terms, APIs tend to be used as tools for customer access to data primarily with the major industry-standard database products. A variety of products are available to help programmers and librarians make use of data held in a RDBMS. Crystal Reports, for example, allows an organization to produce custom reports with many analytical features across any of their business applications. This type of reporting tool provides sophisticated access to data sets for those with a lower threshold of programming expertise. For organizations with experienced database programmers, one can write custom software to extract or analyze data. While this approach provides the capability to access the underlying data through the APIs or other data access

Opening Up Library Systems through Web Services and SOA: Hype, or Reality?  Marshall Breeding

Application with Abstract Database API

Figure 3 Customer access to database API.

Delivered Interfaces

Core Software

Data Stores

Application with API Abstraction Layer

Delivered Interfaces API Abstraction Layer Core Software

Data Stores Figure 4 ILS with internal API.

services made available through an application programming interface. This tiered approach has come into favor in recent years and is consistent with the service-oriented architecture. As applied internally within the application, having a presentation layer interfaces operate through a set of APIs to gain access to the underlying functionality and business logic provides many advantages, including the ability to rework user interfaces without having to reprogram the entire application. Although an internal layering of software reflects good software design, it does not offer users of the software a direct benefit unless the APIs are made available to external applications in addition to their support for the vendor-supplied interfaces. Figure 5 illustrates a hypothetical system where the ILS follows a nicely layered design, with this important addition: the APIs that provide access to all of the data and services of the application have been published for use by the library. These published APIs might be accessed through scripts created by library programmers, through other applications that reside on the library’s network, or through authorized applications beyond the local network. We’ll explore some of the specific tasks that might be enabled through these APIs below. Figure 6 describes a hybrid model, which corresponds more closely to real-world ILS products. This approach includes proprietary programming used internally within the application, but also includes a set of APIs that expose functionality to external resources. Applications that evolved from a legacy of proprietary programming may continue to use that code internally. Still, a subset of functionality is made available through APIs.

What Is an API? An application programming interface involves a set of commands to which a piece of software will respond in a predictable manner. APIs live in the realm of computer-toOpening Up Library Systems through Web Services and SOA: Hype, or Reality?  Marshall Breeding

Library Technology Reports  www.alatechsource.org  November/December 2009

routines associated with a RDBMS, it has limitations. It provides access to the raw data, but does not interact with the higher-level functionality of the automation product. Offering APIs associated with the higher-level functionality of the ILS itself provides much more powerful capabilities. We’re familiar with all of the features of an ILS offered through the staff and public interfaces. An ILS embodies hundreds, if not thousands, of business processes related to the operation of a library. The business logic of an ILS includes transactions for charging, renewing, or discharging materials; calculating circulation periods; loading records of all types; performing validation routines; purchasing materials; and performing search and presentation routines, to name just a few. As software applications have evolved from monolithic proprietary designs to structured layered architectures, it has become common to use application programming interfaces internally. Figure 4 illustrates an ILS where the staff and public user interfaces as well as the reporting module do not access the business logic of the application through proprietary programming but only through the

11

Application API Exposed to External Applications

Delivered Interfaces API Abstraction Layer Core Software

Data Stores

Figure 5 Exposed API services.

Application API Exposed to External Applications Delivered Interfaces Use Proprietary Programming

Library Technology Reports  www.alatechsource.org  November/December 2009

Core Software

12

ate through a Web services model. Web services take advantage of the infrastructure developed for the Web to support computer-to-computer communications. Services and requests will be expressed in some flavor of XML and will use http as the networking protocol to transport the messages. Some environments use a more complex messaging system such as SOAP (simple object access protocol) to deliver requests and responses; others use the more simple REST (representational state transfer) which issues a request through a standard uniform resource identifier (URI). Continue to keep in mind that even when using Web technologies, these APIs operate behind the scenes. While one might be able to test a Web service implemented through REST, the actual use takes place between software programs. Any application that supports an API will implement a responder that continually listens for requests, submits those requests to the underlying software components, and delivers the response.

Proprietary APIs Data Stores

Figure 6 Mixed proprietary and API model.

computer interactions. The word interface in this context does not mean a user interface intended for humans, but rather mechanisms for one computer program to make a request from another. APIs operate through requests and responses. The request might be a simple data lookup, or it might be a complex business transaction. In order for a programmer to know how to use the API, its creator must make available detailed documentation that describes each request supported, the syntax that must be followed, any mandatory or optional qualifiers, and the exact form of the expected response. Equipped with the full documentation of the API and its required transport mechanisms, a programmer will be able to write scripts, configure an external application, or perform other technical tasks that make use of the API. It’s also important to know what kind of communications protocols the API uses. Modern APIs will likely oper-

The concept of application programming interfaces has been around for many years, predating many of the modern conventions for implementing them today. In the ILS arena, we see examples of products that offer an API, but use a vendorspecific command language rather than the protocols and conventions more commonly used today, such as Web services delivered through REST or SOAP. These proprietary APIs provide many useful capabilities to extract data and extend functionality, but may be limited in their ability to support computer-to-computer interactions. Fortunately, the systems offering proprietary APIs (such as SirsiDynix Symphony) have also begun implementing APIs through modern transport protocols.

APIs and Open Source Open source software has attracted great interest in the library automation sphere. At least two open source ILS products have become major contenders in the market, Evergreen and Koha. Open source software comes with the ability to view, modify, and redistribute its source code. This contrasts with proprietary software, where the

Opening Up Library Systems through Web Services and SOA: Hype, or Reality?  Marshall Breeding

Standards as Open Interfaces National and international standards play a vital role in the way that libraries use their ILS. Most standards are implemented as a particular kind of API. Their presence in an ILS is a given; libraries must insist that any ILS they acquire adhere to the full complement of standards that apply to library automation. Any ILS should include support for standards such as • MARC21: formats for bibliographic, holdings, and authority records • Z39.50: search and retrieval • SRU/SRW: search and retrieval of Web services

• OAI-PMH: open archives initiative protocol for metadata harvesting • OpenURL: context-sensitive linking • SIP2 and NCIP: protocols for circulation and patron data As a point of clarification, in this report we look beyond the given standards as examples of API implementation. Library standards do not address many aspects of the data and functionality managed within an ILS. We’re interested in APIs capable of accessing any aspect of the ILS.

API Security It’s important to prevent APIs from compromising the security of an application. The same level of control must be enforced when performing tasks on the system through an API as would be expected for an interface operated by a human. An expected part of interacting with an API will include authentication and authorization mechanisms. Any access to the parts of the system involving personal or financial data must be controlled through appropriate security, including the use of encryption before it is exposed to the network. There may be some API requests that might be made freely available without restrictions. Some portion of the work handled by an API involves information that can be made publicly available, particularly in the open source ILS environment. Most libraries want the information in their catalogs to be accessed by any interested party. Another aspect of concern relates to regulating the volume of requests that might be presented to the API responders. In order to prevent the deterioration of performance for the system’s primary users, it’s important to have security routines that throttle incoming requests to protect the system from misbehaved scripts or intentional denial-of-service attacks.

Terms of Service One of the most important characteristics of an API has nothing to do with technology, but relates to its legal and business conditions. Any use of an API must be done with explicit permission. The terms of service specify details like who may access the API, any costs associated with its use, what they can do with any data they obtain, and any limitations on the distribution of intellectual property associated with the API or its underlying software. A library using a proprietary ILS may need permission from the ILS vendor to enable the API. Some ILS vendors require that the library pay a separate license fee to make use of the API, some require that libraries using the API undergo specific training, and some require both.

Opening Up Library Systems through Web Services and SOA: Hype, or Reality?  Marshall Breeding

Library Technology Reports  www.alatechsource.org  November/December 2009

source code remains under the sole control of the organization that created it. An open source ILS allows anyone to work directly with the source code of the application to fix any problems encountered, enhance existing functionality, or add new features. A key challenge to the maintenance of open source software involves governance issues that coordinate the work of a distributed group of programmers to ensure system coherence, consistent coding practices, and elimination of software bugs. Open source ILS products benefit from customer-facing APIs as much as proprietary ones. Libraries using an open source system should not have to be constrained by the functionality of the delivered interfaces any more than those relying on proprietary systems. Nor should they have to become involved with advanced applications programming involved in the core of the application in order to gain access to data not addressed in the user interfaces. Following an open source licensing model does not necessarily mean that an ILS is inherently more interoperable than a proprietary system. An open source ILS that does not offer support for standard industry protocols and a robust set of APIs will not be more inherently able to communicate with other library and nonlibrary infrastructure components than a proprietary system. Although an open source ILS might enable the library to develop the APIs needed for a given scenario that requires interactions with another application, such a development effort involves a much higher level of investment than being able to take advantage of existing service layers. For these reasons, the same questions regarding the availability of APIs that apply to an open source ILS apply to the proprietary products. Like the proprietary versions, it may be the case that a given open source ILS product finds use primarily in the types of libraries that do not necessarily require this capability. As open source ILS products reach into larger libraries and more complex automation scenarios, their ability to offer this capability will become more critical.

13

Library Technology Reports  www.alatechsource.org  November/December 2009 14

Vendors that assume a certain level of responsibility for the performance of the system and the integrity of its data may be reluctant to turn over access to an API that gives the library the ability to work with the system in ways that might lead to unintended consequences that require major intervention. Some vendors justify an additional license fee for access to the API since it is a feature used by only some customers that requires ongoing development and support. Another area of concern for vendors of proprietary software involves revealing specific details to competitors. The documentation of the API, and even programs that make use of the API, may fall within the terms on nondisclosure expressed in a software license. It’s common for libraries within the community of users of a given product to collaborate and share scripts that make use of an API but to be restricted from sharing those scripts more broadly. Programming done with the API of a proprietary ILS may also fall under terms of nondisclosure. While a company may be willing to provide its existing customers full information regarding the internals of its system, it may not want that information to be made available to noncustomers or competitors. Open source ILS products do not have restrictive terms on any APIs associated with the system. Since the software itself is available without license fees and the source code is readily available, the issues relating to license fees and redistribution of intellectual property do not apply. The second level of permission deals with how the library controls access to its system through the API. It might, for example, open up some API requests without restriction. Catalog search requests, availability of items, and other information that the library routinely makes freely available on the Web through its traditional user interfaces might fall into the kind of requests that would likewise be unrestricted through the API. Requests involving patron data or involving the financial records of the acquisitions module, however, would need to be controlled and limited to trusted business partners.

With Power Comes Responsibility and Cost Adding a layer of APIs to a system that gives a library true access to the data and functionality of the ILS gives the library a great deal of power to work with its system. This power can be a mixed blessing. Once a library has the ability to read, and especially to write, into the data structures that underlie the ILS, extreme care has to be taken not to interfere with the normal operations of the system or to accidentally corrupt data.

The use of customer-created programming has implications for the support provided for the system by a vendor. If support agreements involve service-level agreements that guarantee high availability and expected time frames to respond and resolve problems, some caveats may have to be made when the customer has the ability to change data in the system in ways beyond the software delivered by the vendor. The creation of an API introduces costs for its development, testing, and documentation and for support issues. It’s common for vendors to offer training programs, custom programming, or consulting services related to customer use of these APIs. Like any other system component, once a vendor creates a set of APIs, the vendor must maintain it through each new release and attend to ongoing bugs and security issues. Since the creation and maintenance of APIs add cost and complexity to the system, vendors take different approaches to managing those costs. For some ILSs, especially those designed for large, complex libraries, the API may be considered expected functionality, and its cost may be folded into licensing or support fees. Other vendors take a more a la carte approach to API availability and support. Especially when only a minority of libraries make use of the API, a company may choose to charge a separate license and support fees for that feature. Some ILS products may opt not to provide an API in order to offer low-cost products that can be more easily supported. APIs fall into a much lower priority level than affordable systems that can be used as delivered, particularly in the small to mid-sized library arena. For ILS products targeting this segment of the market, an API may not be an essential feature.

No Universal Expectation for APIs The vast majority of libraries may have no expectation to work with their ILS through an API. Rather, they expect the system to provide for them a complete package of the functionality that they require to automate their work. Most libraries do not have the technical staff that would be needed to produce local extensions to the software using the API. A reasonable degree of openness can be accomplished in other ways. An ILS with a full set of customization features should allow the library to adapt the software to its local preferences. All operational policies will be set; the presentation of online catalog should be malleable enough to adapt to the color schemes, logos, and other visual requirements held by the library.

Opening Up Library Systems through Web Services and SOA: Hype, or Reality?  Marshall Breeding

Chapter 2

Vendors and Products

Abstract

I

n this section we will take a look at some of the major integrated library systems and explore the extent to which they offer APIs. Each vendor was contacted with a request to respond to a set of questions that elicit information about the APIs offered by the systems that they support. The responses received from each product representative are presented as received.

Ex Libris Ex Libris, based in Israel, specializes in providing automation software to research libraries and consortia, with a customer base that includes some of the largest libraries in the world. The libraries that use this company’s products fall well within the profile of those that expect to extend or adapt the software. These libraries tend to have very complex automation requirements that may not be met by any off-the-shelf solution. By the nature of the

Ex Libris www.exlibris.co.il

Opening Up Library Systems through Web Services and SOA: Hype, or Reality?  Marshall Breeding

Library Technology Reports  www.alatechsource.org  November/December 2009

This chapter of “Opening Up Library Systems through Web Services and SOA: Hype or Reality” takes an indepth look at what is currently available on the ILS market, what services are offered in terms of APIs and customizability, and how users have reacted to the products and services. Vendors covered in this chapter include Ex Libris, The Library Corporation, Innovative Interfaces, Polaris, SirsiDynix, Talis, and VTLS.

demographics of its customer base, Ex Libris faces a very high demand for extensible systems. Ex Libris offers a variety of automation products. The company developed the Aleph ILS in the early 1980s and has advanced this product through several generations of technologies. Aleph has been deployed throughout the world, primarily by academic and national libraries, but also by consortia that include public libraries. Voyager, developed by Chicago-based Endeavor Information Sys­ tems, was acquired by Ex Libris in 2006. Voyager finds use primarily in academic libraries in the United States, the United Kingdom, and Australia; it is the automation system used by the Library of Congress. Other products offered by the company include the SFX OpenURL link server; MetaLib, a federated search product; Verde for electronic resource management; the Primo discovery interface; and most recently, Rosetta, a digital preservation system. Given Ex Libris’s clientele, the company faces the challenge of offering not only products with sophisticated functionality, but ones that can be extended to handle complex and specialized library automation scenarios. One of the primary approaches that the company has taken to satisfy these requirements has been an evolving set of APIs. Ex Libris offers a diverse set of products, created over a long time frame that spans many different cycles of technology architectures. Aleph, for example, traces its roots to the early 1980s as a mainframe product written in COBOL. This long history has allowed it to steadily accumulate new functionality, growing into one of the most sophisticated and feature-rich ILS products on the market, capable of serving the world’s largest and most complex libraries. While it has been completely reworked over its long history, vestiges of technologies from past

15

Library Technology Reports  www.alatechsource.org  November/December 2009 16

ages remain. Voyager, created in the mid-1990s as a client/server automation system, embodies a significantly different architecture and programming style. SFX, the company’s OpenURL link server, was originally created at the University of Ghent in Belgium. Though it has been largely rewritten, its codebase differs substantially from the company’s other products. MetaLib, the company’s federated search platform, and DigiTool, a digital asset management system, though developed somewhat more recently, still predate current service-oriented software. Throughout its corporate history, Ex Libris has taken at least some measures to give its customer libraries the ability to work with its products beyond the user interfaces delivered with the system. Each of these products has offered a set of APIs appropriate for its technical heritage. While each product offers APIs in some way and to varying extents, when APIs are considered across the individual products, they are disjointed and inconsistent. While libraries might appreciate that each application offers some flavor of APIs, they may be less than delighted at the complexities of programming against each product in a different way. In the last year, Ex Libris has articulated a strategic direction of technology based on a more thorough and consistent delivery of APIs. This strategy involves exposing a more comprehensive array of functionality in its products through APIs and delivering them more consistently. As the company develops new versions of its current products as well as entirely new products, it will work toward creating a more uniform and coherent set of APIs, delivered through a consistent and modern Web services approach. In June 2008, Ex Libris announced its “open-platform program,” which stated that its corporate strategy was to develop open interfaces to its products, to provide full documentation for its APIs, and to evolve the APIs across all its products to a more consistent and unified structure. The program specifies that forward development will emphasize a service-oriented architecture. Oren Beit-Arie, Ex Libris chief strategy officer, has been one of the guiding forces behind the company’s support of open APIs; Tamar Sedeh, director of marketing, has been given responsibility for the open-platform program.1 As part of the fulfillment of its open-platform program, Ex Libris created a workspace called “EL Commons” as the focal point for programmers involved with Ex Libris products. EL Commons includes a repository to gather together and make available any programs or scripts that make use of the APIs associated with any of the Ex Libris suite of products, documentation for the APIs associated with each of the products, and forums to facilitate enquiries and discussion surrounding their use. At the of this report’s publication, Ex Libris restricts access to EL Commons to its direct customers, but intends to open its access to noncustomers in the near future to accommodate those involved

with other organizations that want to develop interoperable applications with Ex Libris products.2

Survey Responses3 Describe, in general terms, the APIs that your company offers for your primary ILS and other library automation products.

Ex Libris offers open interfaces for all of the company products, enabling libraries to customize our products, extend them by adding locally developed or third party functionality, and integrate entire products or parts of them with other systems in the library. We divide the open interfaces into several categories:

Application Programming Interface (API). Web

services (wrapped in SOAP), X‑services, and RESTful services. The first APIs that we developed a decade ago for the Aleph integrated library system, X-Services, were http/XML API. X-services are available for most other Ex  Libris products as well, and serve an important role in initiatives such as David Walker’s Xerxes system, developed as an open source system using metasearch functionality through MetaLib X-services. The next generation of APIs was developed as Web services wrapped in SOAP, and today new APIs are developed as representational state transfer (REST) services. For example, the DLF-DI services are now being implemented as RESTful services. All APIs (X‑Services, Web services wrapped in SOAP, and RESTful services) are available on the EL Commons collaborative Web site, which will be described later in this document, and enable customers to use them in whatever programming language they wish to use.

Plug-ins. Routines provided by Ex Libris that

interact with our applications in a predefined way determined by our applications, to provide a specific function. Institutions or a 3rd party can modify our plug-ins to create new capabilities. For example, by modifying the out-of-the-box “enrich indexing” plug-in, Primo customers can enrich the records that they harvest with information such as reviews, book covers, and tables of contents from the external resources that are relevant to them.

Adapters. Routines developed by Ex Libris to bridge between our applications and 3rd party applications and allow applications to interoperate even when having incompatible interfaces. For example, the Deep Search adapter enables Primo to search in a remote resource using the API of

Opening Up Library Systems through Web Services and SOA: Hype, or Reality?  Marshall Breeding

that resource. Another example would be a MetaLib external program that enables MetaLib to send a search request to an information resource that does not support standard protocols and obtain the results returned by that resource. Customers can modify our adapters and develop their adapters as well, based on our adapters. Deep Links. URLs that point to a specific HTML page, such as result list or the full display of an item. Reporting Schema. A set of Oracle views that provides read-only access to the data, for reporting purposes.

We provide comprehensive documentation, including examples, for all interfaces. In some cases we provide additional programming tools such as utilities and libraries of functions or classes that together form a software development kit (SDK). What is the business model for your APIs? Is access to the APIs included with the base product, or is it an extra-cost option?

Today all open interfaces are offered as part of the core product and we do not charge any license fees for them. Do you publish documentation for your APIs? Is it available only to licensed customers, or to third-party developers as well?

Does the API operate through REST or SOAP Web services, or does it use proprietary mechanisms for transmitting data and requests?

As explained above, Ex Libris provides APIs of three types, all transferring data over the Web. X-Services are based on simple http/XML data transfer, whereas the other APIs are either wrapped in SOAP or adhere to the REST network architecture.

The open interfaces enable the full spectrum of func­ tionality, including the creation and the modification of data. Describe any case studies where one of your customers has been able to perform interesting work with your system through the use of APIs.

There are many examples on the EL Commons Developer Zone, where customers post their code and enable it to other customers. Most code contributions are developed to extend the Ex Libris solutions by adding functionality. A few recent examples: • OPAC spelling suggestions using Yahoo! Web service *JSON* (Aleph; Mark Watmough, Napier University, UK) • ticTOCs and embedded SFX services in OPAC (Aleph; Daniel Forsman, Jonkoping University, Sweden) • WebVoyage 7 (Tomcat) Addition of OCLC “Cite This Item” Link (Voyager; Laura Guy, Colorado School of Mines, USA) • Patron History Browser (Voyager; Rhoel Gerona, Bay of Plenty Polytechnic, New Zealand) • i-Phone view (Primo; contributed by Ex Libris) • Add Primo tags from an external source (Primo; John Osborn, University of Iowa, USA) • doSFXTransfer (SFX; Charlie Ambrose, Aarlin, Australia) • OCLC’s OpenURL Resolver Registry as SFX Target (SFX; Inga Overkamp, Max Planck Society, Germany) • MetaLib Automatic Monthly Statistics Gathering Script (MetaLib; Ere Maijala, National Library of Finland) • EZproxy Authentication Adapter for PDS (MetaLib; Ere Maijala, National Library of Finland) Some projects are on a larger scale. Most notorious examples: Xerxes—a metasearch system developed by David Walker of Cal State and Jonathan Rochkind of Johns Hopkins University, using X-Services to offer the full spectrum of MetaLib functionality. Livetrix, (also known as PurpleSearch) another metasearch system, developed at the university of Groningen by Bart Alewijnse and André Keyzer, relying on MetaLib X-Services in a way similar to that of Xerxes Umlaut, a link resolver front end, developed by Ross Singer while being at Georgia Tech and Jonathan Rochkind from Johns Hopkins University, relying on the SFX APIs

Opening Up Library Systems through Web Services and SOA: Hype, or Reality?  Marshall Breeding

Library Technology Reports  www.alatechsource.org  November/December 2009

Comprehensive and consistent documentation of the open interfaces across all products is available on a collaborative Web site—EL Commons—that serves as a communication channel among Ex Libris community members (library developers and Ex Libris developers). The EL Commons Web site consists of two parts: a wiki, defined and administrated by the customer user groups (IGeLU and ELUNA), and the Developer Zone. The documentation of the open interfaces is available on the Developer Zone, along with contributions posted by customers and Ex Libris. By default, contributions are open source and are assigned BSD license; however, contributors can change the license as required. The EL Commons Web site is available to all Ex Libris customers, regardless of the product they deploy. Parts of the site will be open to all by October 2009. We enable access to third party developers if requested by our customers.

Can the API create and modify data, or is it read-only?

17

Xerxes http://xerxes.calstate.edu

Livetrix http://purplesearch.ub.rug.nl/help.docs

Umlaut http://wiki.code4lib.org/index.php/About_Umlaut

In what way do you consider your system one that embraces the service-oriented architecture?

Library Technology Reports  www.alatechsource.org  November/December 2009

Our newer systems adhere to service-oriented architecture principles, and as we move forward we are putting more emphasis on modularity and on developing our solutions as components that interact through open interfaces. A good example is the way we implemented the inclusion of OPAC functionality in Primo version 3.0 to be released at the end of 2009: we developed a suite of RESTful services for Aleph and for Voyager, and applied the functionality in Primo relying on the interfaces included in these suites. The development of open interfaces is defined within our design and coding practices.

18

Are there any other issues regarding APIs that you would like us to be aware of as we develop this report? Are there other approaches that your company supports instead or in addition to APIs for providing end-user access to system data and functionality?

First, I’d like to stress that we at Ex Libris attribute much importance to the openness of our systems. We realize that despite the rich functionality and the flexibility of our solutions, we cannot satisfy all needs of all customers cost-effectively and in a time frame that fits all. We believed in open systems years ago, but in the last 15 months we went through an extensive process in the company, examining our practices and setting in place a framework for defining, developing, and supporting open interfaces. Furthermore, rather than developing these interfaces only so that customers can extend our systems, we rely on them when we develop our systems and we make sure to develop functionality that is relevant to more than one system as a separate module, interoperable through open interfaces. Our open interfaces cover rich functionality that is not limited to end-user access to the system. In May 2008 I was appointed to lead the open-platform program and now have an overall responsibility for the program within the company. To carry out the program we went through organizational alignment, nominating one of the senior development staff members to head the open-platform program from the development side, and a focal point in every development team. We built the Developer Zone of the EL Commons Web site and we rearranged our documentation of open interfaces so that

all of it is available in one place and in a consistent format. We regularly communicate with customer developers and conduct meetings during user group meetings. In addition, we hold two annual Developer Meets Developers meetings. Up to now we had held two such meetings—one at the Company’s headquarters in Jerusalem in November 2008 and the other at the Company’s North American R&D center in Chicago in March 2009. The meetings enabled customer developers and Ex Libris developers to communicate and discuss technical and other matters. We believe that the active community of developers is a key component in the open-platform program and we are inspired and impressed by their ideas. Another thing that I’d like to point out is that the openplatform program enables libraries to enjoy the benefits of commercial products—stability, regular enhancements and upgrades, professional support, rich functionality from the outset, and a clear, committed roadmap—as well as the flexibility and agility of open source. Libraries do not have to commit to one way or another, and can start their innovation at the point that suits them best. For most libraries, engaging in big development processes is not a desired task for several reasons. For example, many libraries do not employ professional software engineers and hence lack the human resources to commit to long and complex development cycles that, in some cases, may not yield the expected results in the time frame set. Therefore, libraries prefer to invest their effort in adapting existing systems to their needs by sophisticated customization and addition of functionality that they develop or acquire. Our openness and tools enable such a process in the best possible way. And last but not least, the open-platform program enables all libraries, regardless of their size, budget or IT resources to benefit from the creative work done by all developers. That is, libraries that are more limited in their capabilities to develop code can use code written at other institutions or collaborate with others to carry out projects they could not perform themselves.

Case Studies and Customer Responses

Duke University Libraries4 Ken Mitchell, IT analyst at Duke University Libraries, provided the following response to the questions regarding the APIs offered by Ex Libris: Just as an overview of how we’re using vendor APIs for our library systems, we are currently using a catalog interface that primarily uses Endeca as the searchand-retrieval system, with various hooks into ALEPH for services that are not provided by the Endeca

Opening Up Library Systems through Web Services and SOA: Hype, or Reality?  Marshall Breeding

application (e.g., live circulation statuses, hold-request functionality, course-reserves, etc.). Where possible, we are using web-service/API services for both Endeca and ALEPH (we had to develop our own XML-based web-services layer for Endeca, as the version we are using only provides API services for Java, ASP, and ASP.NET). We are also using Ex Libris APIs for our MetaLib and SFX applications, and have developed a full in­ter­ face replacement for MetaLib using those APIs (similar to David Walker’s Xerxes project, but with a focus on developing an “integrated” application interface for our catalog/article/databases/etc. services).

Do you feel like you can pretty much do anything you want with the system, or do you feel constrained?

We are definitely constrained in the ALEPH system. The “X-Services” API layer provides access to some important functions, but it also:

Are the APIs offered able to address all the data and functionality within the ILS?

No. Not even close. The ALEPH “X-Services” API does not provide the range of functionality required to replace the application’s OPAC. Some missing features: holdrequest processes (both on the query level [to determine requestability] and on the request level), browse/authority list search-and-retrieval processes; complete item-level information in a single call, etc. On the flip side, do you feel like your ILS is too closed?

No. ALEPH does have an API library (as quirky as it is), and many schools have opted to perform direct database calls to gain access to data and/or functionality that is not accessible through the APIs.

We have developed both automated scripts and interface applications taking advantage of the APIs, primarily using Perl, PHP, and Python (often layered under the Django framework), and often using XSL for the presentation components of these applications. What level of programming proficiency is required: systems librarian with scripting languages, software development engineer, or something in between?

Depending on the purpose of the application, either level of expertise is adequate, since the APIs themselves are accessible via simple URL calls. In general, though, in our environment we are using the skills of software development engineers to develop most of our scripts and/or applications. What’s on your wish list? What kind of APIs would you like to see incorporated into your current or next ILS?

As we look more towards abstracting out the discovery layer and process from our ILS, the primary features we would like to see in our ILS are: (a) on-demand harvesting mechanisms (OAI-PMH services; MARC-record delivery systems) (b) full-featured holdings/circulation data services (circulation statuses on title and item-levels; hold-request functionality [query and request services]) (c) specialized/personalized data services that fall outside of routine discovery services (e.g. library patron account information; course reserves data access)

Broome Community College Mike Curtis, systems librarian at Broome Community College, one of the State University of New York libraries that uses Aleph 500, responded to inquiry regarding ILS APIs, reporting on his experience creating an entirely new OPAC interface using the APIs available with Aleph. I also used it create RSS feeds for search results. That is demonstrated on the search results page. The API has a lot of functions for doing circulation transactions, but I haven’t used them. Basically, the staff client works just fine for circulation/cataloging procedures. When it doesn’t it usually seems that SQL is the answer, or that the system suffers from poor configuration.

Do you find the APIs offered by the developer of the ILS to be well documented?

Yes. There are occasional typos, and some undocu­mented bugs/features for the APIs, but overall ALEPH has a reasonably well-documented set of APIs.

Broome Community College www.sunybroome.edu/library/x/ccl.php

Opening Up Library Systems through Web Services and SOA: Hype, or Reality?  Marshall Breeding

Library Technology Reports  www.alatechsource.org  November/December 2009

(a) Leaves out a wide range of functions (e.g. no “browse”/authority search features, no ability to de­ter­mine an item’s requestability, etc.); (b) Has crippled functionality for many of its services (e.g. a hold-request service that does not allow for specifying a pickup location; patron-information services that do not provide sufficient information for identifying local patron credentials, etc.); (c) Does not appear to have been road-tested in any meaningful way (e.g. no item-status calls that can provide the appropriate range of item information in a single call; mysteriously hard-coded values in API calls that do not appear in OPAC or GUI routines, etc.)

What programming languages or other tools were you able to use to take advantage of these APIs?

19

Library Technology Reports  www.alatechsource.org  November/December 2009 20

Figure 7 Broome Community College replacement OPAC for Aleph 500.

So I wouldn’t try API programming to replace the staff client. But the API worked great for replacing the Aleph Web OPAC.5

University of Tennessee Mike Rogers, a computer systems specialist at the Uni­ versity of Tennessee Libraries, provided a response re­gard­ing that institution’s experiences with the ALEPH 500 system from Ex Libris: The University of Tennessee Library uses Aleph 500 as our primary ILS system. Apart from the “out-of-thebox” system (which for us includes the Cataloging, Acquisitions/Serials, Circulation, and Course Reserves modules) we have successfully programmed a number of custom services to meet the needs of students, faculty, and staff.

In general, I have found the Aleph system to be a very open and flexible system. With Aleph, it is possible to embed custom programs within the individual GUI modules and configure them so that staff can run them on an as-needed basis. It is even possible to define permissions so that certain staff can run them. Aleph also has a scheduler which can run the custom programs on a regular basis (hourly, two or more times per day, weekly, monthly, etc.). An example of Aleph’s openness: Aleph utilizes an Oracle database which contains a significant amount of data. In lieu of purchasing third-party reporting software, I have written a number of SQL queries that extract data from the various tables. Depending on the type of report, these custom reports are embedded within the GUI modules and serve as sort of a home-grown reporting center. Another example involves custom Perl and PHP programs. These

Opening Up Library Systems through Web Services and SOA: Hype, or Reality?  Marshall Breeding

University of Tennessee New Items feeds www.lib.utk.edu/whatsnew/newtitles

National Library of Australia The National Library of Australia, an Ex Libris Voyager site, gave the following responses:7 Do you feel like you can pretty much do anything you want with the system, or do you feel constrained?

Very constrained.

There are no real APIs with current version of the ILS that we are on. Do you feel like your ILS is too closed?

Yes, definitely too closed. Do you find the APIs offered by the developer of the ILS to be well documented?

Again, there are no real APIs with current version of the ILS that we are on. With latest versions there are some APIs/Web services, but the documentation is poor. What programming languages or other tools were you able to use to take advantage of these APIs?

As no real API is available, what work we have done has been connecting straight to the Oracle database using Perl, screen scraping or using its bulk program to wrestle MARC records What’s on your wish list? What kind of APIs would you like to see incorporated into your current or next ILS?

On our wish list would be an API (Web services or other similar technology) that exposes the full functionality of the ILMS system. Everything that the OPAC shows you, everything that the call slip client lets you do, everything you can do with the cataloguing client, should be able to be performed using the API as well. The system should expose as its API the exact same interfaces used by its own modules.

Evergreen Evergreen is an open source ILS developed originally for the PINES consortium of public libraries in Georgia. Following its successful implementation in Georgia, it has attracted the interest of many other public library consortia. The original developers of Evergreen launched a company named Equinox Software in 2007 devoted to its ongoing development, marketing, and support.

Evergreen www.open-ils.org

While it has also seen a few implementations by single libraries, the majority of interest in Evergreen has been through consortial efforts. In addition to the original PINES consortium, some of the consortia using Evergreen now include the British Colombia SITKA consortium, Evergreen Indiana, SC Lends in South Carolina, and Michigan Library Consortium, with others expected to come online in the near future. The first group of academic

Opening Up Library Systems through Web Services and SOA: Hype, or Reality?  Marshall Breeding

Library Technology Reports  www.alatechsource.org  November/December 2009

too can be embedded within the GUI modules and configured so that only certain staff members have access to run them. In summary, we have a need for our back-end users to run SQL queries, Perl/PHP programs, etc. but we do not want to allow the users to have direct access to the server. However, the Aleph “custom services” option gives us the ability to meet that need. Another example of custom programming in Aleph involves a set of RSS feeds for new items: I wrote these with SQL, which writes the output as XML in RSS format. The XML is converted to HTML using a PHP script. All of this runs automatically once a week on our Aleph server. Another example of custom programming is a recent service developed for our offsite storage facility. In Aleph, we took advantage of some OPAC functionality that allows patrons to place requests for items. One request that patrons can submit is a “photocopy” of an item. Given Aleph’s flexibility, we converted the Photocopy Request functionality into a PDF scan request. This way, patrons can place requests via the Web for PDF scans of items in storage. Some additional programming (shell scripts, SQL, and PHP) automatically sends the patrons a PDF attachment via email once the files are placed on the server. Additional programming alerts patrons of items not found or items having incomplete/bad citations. We have also been successful in programming Aleph to extract/manipulate data that can in turn be uploaded to the university’s financial system (SAP/ IRIS) and the bursar system. Aleph also integrates well with our binding system (ABLE). I feel in many ways that we have done quite a bit with programming Aleph to meet our needs, but then again feel like we are only scratching the surface. Some things we are considering for the future include sending SMS text message notifications to patrons, utilizing the Aleph X-server for Web services, adding dynamic stacks locater maps for items in the main library, etc.6

Are the APIs offered able to address all the data and functionality within the ILS?

21

libraries, the Conifer consortium in Ontario, Canada, began production use of Evergreen in August 2009. Evergreen, given its status as the most recently created library automation system available, is one of the few systems created in the area of service-oriented software. One of the key components of Evergreen is an underlying services layer called OpenSRF, based on Jabber as the messaging protocol. This design makes the software inherently more able to support APIs. Since Evergreen is an open source ILS, developers have the option of working directly with the source code of the software rather than programming through an abstract API layer. In a service-oriented application like Evergreen, this distinction is more subtle than with proprietary applications, where the only avenue for interacting with the software is through an API. Because the application is built on a services framework, application programming primarily involves coding against the OpenSRF API. The libraries that have adopted Evergreen so far are not necessarily the types of libraries that have a high demand for APIs. The APIs provide a good foundation for the forward development of the system but tend not to be used by the end-user libraries. Equinox Software, the primary firm providing support for Evergreen, fielded the survey questions.

Library Technology Reports  www.alatechsource.org  November/December 2009

Equinox Software

22

www.esilibrary.com

Survey Responses8 Describe, in general terms, the APIs that your company offers for your primary ILS and other library automation products.

The basic programming of the Evergreen application takes place through calls made to the underlying OpenSRF API. This API provides access to all of the underlying data structures. What is the business model for your APIs? Is access to the APIs included with the base product, or is it an extra-cost option?

All Evergreen APIs are available at no cost out of the box. Do you publish documentation for your APIs? Is it available only to licensed customers, or to third-party developers as well?

We document the APIs used by Evergreen, all of which are available for use by third-party developers, on the project wiki, in the Evergreen documentation project, and in blog posts. In addition to wiki-based, blog, and traditional documentation of the various APIs, there is a built-in introspection service for the core API.

Does the API operate through REST or SOAP Web services, or does it use proprietary mechanisms for transmitting data and requests?

There are some portions of the API available through a RESTful interface, and the entire API is available through XML-RPC. There are also Evergreen-specific libraries which implement http and XMPP bindings for the full API. Describe the technical architecture of the API.

Evergreen is constructed as a set of loosely coupled ser­ vices which consume standard data object and provide business logic for implementing specific functions which are required for library workflow. At the heart of Evergreen is the OpenSRF (Open Service Request Framework) network, a programming language agnostic communication backbone that pro­ vides an abstraction layer for inter-service service requests. In addition, OpenSRF provides transparent Load Balancing and High-Availability to an application such as Evergreen. Adding processing capacity to an application built on OpenSRF is as simple as procuring and provisioning an additional low-cost commodity server, and configuring it to connect to an existing OpenSRF network. By providing a simple internal API for use by application developers, adding and changing functionality of an OpenSRF application is a simple as defining the input, output and logic of the desired method. There need be no consideration made of potential network topologies, client programming languages, session and transaction semantics, or even external integration. All of these concerns are handled by OpenSRF itself, and the developer of an OpenSRF application can focus strictly on the specific task at hand. Additionally, by using OpenSRF, Evergreen can be made to scale from the very tiny—say, a rural, single branch library with less than 10,000 items—to the enormous. No code changes are necessary; only a single configuration file specifying which services to run on each node in an OpenSRF network. Are your APIs able to perform the following types of transactions? (I’ve provided some examples of some specific activities that libraries may want to accomplish, but there may be others that you support that you may want to mention.) Bibliographic records—ability to extract or update metadata on a field-by-field basis, beyond the capabilities of standard protocols such as Z39.50.

Modification of bibliographic records is per­formed atomi­ cally, by updating the record as a whole. Item/holdings records—ability to respond to realtime requests for availability, circulation status, etc.;

Opening Up Library Systems through Web Services and SOA: Hype, or Reality?  Marshall Breeding

ability for external applications to execute circulation transactions for checkouts, returns, holds, etc.

The API provides methods for both aggregate and individual availability information for items, and can be used to perform all transactions involv­ing items. Patron records—personal details, demographic data, au­thentication credentials, materials charged or requested, etc.; real-time synchronization with external authoritative repositories of user populations.

Evergreen can perform batch imports and updates of user records from an external, authori­­tative source, but does not directly integrate with such sources for real-time authentication. Circulation transactions/history—detailed usage data for collections, user categories, etc.

Evergreen allows retention of full circulation data, as well as supporting the retention of circu­lation data stripped off of personally identifiable patron information. All retained data can be explored and reported on using standard database techniques including use of the built-in reporting engine. Acquisitions and financial data—ability to interact with external accounting or ERP systems.

Can the API create and modify data, or is it read-only?

The OpenSRF provides access to all functionality defined in the application. Describe any case studies where one of your customers has been able to perform interesting work with your system through the use of APIs.

Using the Evergreen APIs, production customers built various tools that fall outside the scope of an ILS which leverages their data. Among others, there are contributed, non-core projects for automated outbound telephony, captive portal authentication and a standalone new-books list. All of these use existing Evergreen API calls with no new code required on the ILS side. Customers have also created entire customized OPACs to replace the stock OPAC that ships with Evergreen. In what way do you consider your system to embrace the service-oriented architecture?

In order to create a scalable solution, Evergreen was designed from the beginning as a loose federation of cooperating services that depend on one another and create a fabric of methods that are programming language, location, data, and server independent. Each

Case Studies and Customer Responses No responses were submitted from libraries that have implemented Evergreen that make use of its API.

The Library Corporation The Library Corporation (TLC) offers two different ILS products, with a new system in development. Carl.X finds use in large library organizations, especially municipal libraries and consortia; Library.Solution is a popular choice for small to medium-sized public libraries. Both systems have been implemented primarily in public libraries. A specialized version of Library.Solution has been developed for K–12 school districts. Special and academic libraries represent a small portion of TLC’s customer base.

The Library Corporation www.tlcdelivers.com

Carl X has a long legacy in the library automation arena, tracing its roots to at least the early 1980s. The software was designed originally to operate on Tandem hardware, noted for its extremely high reliability. Carl finds use primarily in large-scale implementations, including consortia and municipal systems. The Library Corporation acquired the software in August 2000 and has evolved the system into Carl.X, which relies on a new technology platform based on UNIX and Oracle. As a system implemented by large library organizations, it fits within the realm where APIs and Web services have a high level of interest. Library.Solution was developed by The Library Cor­poration and introduced in 1997. This system was designed for small to medium-large public libraries. As a system that appeals to libraries with limited resources, Library.Solution does not fall within the profile of products where APIs would be in great demand. TLC has begun development of a new ILS platform named LS2. The initial module of the system, the LS2

Opening Up Library Systems through Web Services and SOA: Hype, or Reality?  Marshall Breeding

Library Technology Reports  www.alatechsource.org  November/December 2009

While acquisitions functionality is currently under develop­ ment, Evergreen does currently support interaction with external systems through EDI (EDIFACT) file inter­ change.

service provides a specific set of functionality, and each can be tuned, modified or upgraded without affecting the rest of the system. This is the very heart and spirit of SOA—that a loosely bound group of services depending on one another for specialized tasks is greater than the sum of its parts. This is a technical, founding principal we use in developing Evergreen.

23

PAC, can be used as a public interface with either Carl.X or Library.Solution. LS2, consistent with modern programming practices, has been created in a more serviceoriented model and will have more capabilities for delivering APIs that can be accessed by customer libraries than was possible with the company’s legacy products. The development of the LS2 platform transitions from legacy products to modern service-oriented software; the LS2 PAC, used in conjunction with TLC’s older ILS products, makes their data and services more available through Web services. 9

Survey Responses

Library Technology Reports  www.alatechsource.org  November/December 2009

Describe, in general terms, the APIs that your company offers for your primary ILS and other library automation products.

24

of help and support. Our customers have found that the public catalog can be modified in any way that they choose, all within the limits of the code it’s written in. The system has been open, although not necessarily through a large-scale API. In the future, we expect to find libraries that will have a reason to access our API, and they have the ability to do that for anything regarding our public catalog and Web circulation in the LS2 API that works with both Library.Solution and CARL.X. It has been TLC’s long-held conviction that our customers’ data belongs to them and we’ll give them access to it however possible. We look forward to working with libraries to make sure that we balance the need to have an open API with TLC’s ability to rapidly innovate the product.

Both of our integrated library systems, Library.Solution and CARL.X, are exposed primarily through the LS2 platform, which was designed specifically with access to open APIs in mind. Up to that point, we had a variety of examples where we made data available through these ILS systems, either with old-fashioned protocol methods such as NCIP, Z39.50, or SIP2; through on-demand API required by vendors such as AquaBrowser, where we made our bibliographic data, shelf status, and various items in the catalog available; and finally (and most extensively), for our CARL.X system, Chicago Public Library used API for its public catalog and acquisitions/selections interfaces, all via Web services with different front ends designed by third-party companies. Of course, we would also include our links to multiple other vendors—Student Information Systems (over 30 brands), EnvisionWare, Tech Logic, Unique Management, Talking Tech, NoveList, Cognos, Syndetic Solutions—which allow integration in both directions between our systems and theirs for sharing or exporting/importing data.

Do you publish documentation for your APIs? Is it available only to licensed customers, or to third-party developers as well?

What is the business model for your APIs? Is access to the APIs included with the base product, or is it an extra-cost option?

Are your APIs able to perform the following types of transactions? (I’ve provided some examples of some specific activities that libraries may want to accomplish, but there may be others that you support that you may want to mention.)

We have only provided API access extensively for CARL.X. The business model for open APIs with LS2 has not yet been used. However, that doesn’t mean we don’t have a business model for openly retrieving and using this client data from our traditional systems. Because we offer flexibility in our public catalog interface with open access to the HTML and the services within it, we had libraries linking up to book jackets from Amazon.com in 1999. We’ve been connecting with about 30 student information systems for the past 10 years through our Library.Solution for Schools product, which updates student information via user-defined fields. All of our modules include user-defined fields for things such as statistics, book cataloging, serials, acquisitions, and circulation for a greater degree of flexibility in terms

With CARL.X, we did publish documentation for our API and confined it to licensed customers and third-party developers. We wouldn’t give it to an unrelated third party. It’s not a shareware product. Does the API operate through REST or SOAP Web services, or does it use proprietary mechanisms for transmitting data and requests?

We use SOAP (Simple Object Access Protocol) and the more “modern” JSON (JavaScript Object Notation) in LS2. Can the API create and modify data, or is it read-only?

The API is CRUD (create read update destroy). Describe the technical architecture of your API.

We use DWR (Direct Web Remoting) to create JSON. We use Axis 2.0 for the Web services.

Bibliographic records—ability to extract or update metadata on a field-by-field basis, beyond the capabilities of standard protocols such as Z39.50.

Available in LS2 via SOAP and JSON. Item/holdings records—ability to respond to real-time requests for availability, circulation status, etc.; ability for external applications to execute circulation transactions for checkouts, returns, holds, etc.

Real-time requests for availability are available in LS2 via SOAP and JSON. Ability to execute circulation transactions for checkouts, returns, and holds is offered in LS2 PAC and Circ via SOAP and JSON.

Opening Up Library Systems through Web Services and SOA: Hype, or Reality?  Marshall Breeding

Patron records—personal details, demographic data, au­thentication credentials, materials charged or re­quested, etc.; real-time synchronization with ex­ternal authoritative repositories of user populations.

Personal details are available in LS2 PAC via SOAP and JSON. Authentication creden­t ials mate­rials charged or requested are available in LS2 PAC via SOAP and JSON. Real-time syn­chroni­zation with external authoritative repositories of user populations in near real time is avail­ able with ActiveDirectory. Circulation transactions/history—detailed usage data for collections, user categories, etc.

No, only via reporting. Acquisitions and financial data—ability to interact with external accounting or ERP systems.

No. Vendor records—synchronization with external ERP.

No.

Innovative launched Encore, a new-generation discovery interface in 2006. Encore also provides a new technology platform for Innovative, developed with current-day technologies more amenable to APIs and Web services. Encore also functions as a service layer into Millennium data and functionality. The customer base of Innovative spans a wide range of types and sizes of libraries. It provides automation for many large and complex libraries. Its products are used in many regions of the globe. Innovative’s customer libraries include many large research libraries (thirty-nine ARL members), municipal and large public library systems, and others that fall within the profile of libraries with advanced needs for interoperability and data services.10 At the same time, Innovative serves a vast number of libraries that expect fully managed turnkey systems and that do not expect to perform local programming. This heterogeneous customer base presents a challenging environment and provides some perspective on the company’s business model of offering its APIs as separately licensed options. 11

Survey Responses

Describe, in general terms, the APIs that your company offers for your primary ILS and other library automation products.

No responses were submitted from libraries that have implemented TLC products that make use of APIs.

Our practice has been to develop needs-based APIs with direct input/direction from our customers. As a result, we tend not to have theoretical models, but practical implementations that solve specific and real needs. For example, rather than have a “Patron Record” API, we offer a “Patron Update” API, a “Fine Payment” API, and a “My Account” API—we target specific tasks. Several of our products offering API functionality in­clude Millennium, Encore, Content Pro, and INN‑Reach.

Innovative Interfaces Innovative Interfaces ranks as one of the largest and most long-standing library automation vendors. Its Millennium ILS has been adopted by thousands of libraries throughout the world. Innovative’s ILS has been evolving for over twenty years and has made the transition through several generations of technology. The current system, Millennium, was introduced around 1997.

Innovative Interfaces www.iii.com

Innovative offers a number of APIs to its customers, mostly packaged into discrete product offerings. In general, the company does not offer a one-size-fits-all system, but rather a system where it licenses a customized set of modules and components that meet the needs of each library. With this approach to pricing, each library pays for the functionality it uses, and does not pay for capabilities that might be available that it does not need. Innovative offers a fairly wide selection of APIs, offered as separately licensed components, consistent with its general pricing strategy.

What is the business model for your APIs? Is access to the APIs included with the base product, or is it an extra-cost option?

API sets are optional functions within Millennium. De­pending on the initial needs of the particular library, the Millennium system may be initially configured with the appropriate API functions that the library needs. If so, the price of those functions (as with other functionality) is bundled into the initial price. If a library decides to add this functionality to an existing Millennium system, there is an optional fee. For Encore, the Query API is a module that is priced separately. Do you publish documentation for your APIs? Is it available only to licensed customers, or to third-party developers as well?

Technical documentation is available to customers and third-party developers. Techdocs, Innovative’s Technical Documentation site, provides information to libraries that

Opening Up Library Systems through Web Services and SOA: Hype, or Reality?  Marshall Breeding

Library Technology Reports  www.alatechsource.org  November/December 2009

Case Studies and Customer Responses

25

have purchased one or more of Innovative’s Web interface products, such as the Patron Update Web Service, Fine Payment Web Service, My Account Web Service, or Millennium Enterprise Backup. In addition, Innovative has a separate website, Vendordocs, for the purpose of distributing information important to joint development with vendor partners. More importantly, our online documentation provides Perl and/or JavaScript scripts. Our experience has shown that this is the best way for our partners to explore the functionality of the various APIs. Innovative provides libraries with a downloadable Patron Web Services Development kit. Does the API operate through REST or SOAP Web services, or does it use proprietary mechanisms for transmitting data and requests?

vative returns all the information in the patron record. Examples of use of this API include patron authentication by eBook vendors and the ability to validate a PIN.

My Account Web Service (read-only). The My Ac­count Web Service allows access to patron circulation information about checkouts (including due dates), items available for pickup, status of outstanding holds, booking information, and fine information. This API would allow libraries to integrate information into an enterprise portal, for example.



Patron Update Web Service (read/write). This API allows 3rd parties to create new patron records and update patron information programmatically. Use it to streamline patron registration and upkeep. For example: patronFields—An array of Patron record fields that can be changed upon update [see figure 8].



Fines Payment Web Service (read/write). This API

All of Innovative’s modern APIs operate through SOAP, and utilize Perl and JavaScript. Legacy APIs use http:// mechanisms. Can the API create and modify data, or is it read-only?

accesses patron fine information from Millennium. It is primarily used by 3rd party self-check vendors to enable e-commerce functionality. Innovative’s Fines Payment Web Service provides an API that allows you to access Innovative data and functionality through a website or Webenabled application. The Fines Payment Web Service follows the standard Web services model, that is, users of the service request data through XML over http or SOAP and the service returns data as an XML-formatted stream of text.

See specific API descriptions provided below.

Library Technology Reports  www.alatechsource.org  November/December 2009

Are your APIs able to perform the following types of transactions? (I’ve provided some examples of some specific activities that libraries may want to accomplish, but there may be others that you support that you may want to mention.)

26

Provided below is a representative set of APIs offered by our products:

Patron API (URL, read-only). Delivers patron infor­--

mation to a requesting service. This URL-based API sends all the patron information to the requester in a single “dump.” Uses might include exporting a URL to a patron photo for printing on a library card, and working with workstation booking and print control software. SSL encryption is an option. The vendor sends an HTML request to a reserved URL on the Innovative system. Inno-



Inventory Express (read-only). Inventory Express

communicates with each vendor’s Web service using a SOAP request tailored to that vendor’s specific protocol. The library then receives inventory information and brief records from these vendors in real time. Library staff may interactively choose a vendor with the title in stock during the

Figure 8 Details of data elements involved in Innovative Interfaces Patron Update Web Service. Opening Up Library Systems through Web Services and SOA: Hype, or Reality?  Marshall Breeding

new-order creation process. Once the vendor is chosen, data provided by the vendor is used to create the bibliographic record. Vendors offering this service include Baker & Taylor, Amazon.com, Coutts, Midwest Tape, and BWI.



Item Status API (read-only). The Item Status API permits both Millennium Circulation and the Express Lane product to interface with a third party RFID system. It enables support of the RFID “pad” that allows checkout/checkin of multiple items at once. It also sets the RFID chips appropriately to allow the item to pass through the security gates.



agement includes a configurable Web service, which connects to specified vendors on a librarydetermined schedule to harvest usage statistics provided in the COUNTER format. This harvesting process follows the SUSHI protocol, and both SUSHI 0.1, 1.0 and 1.6 compliant statistics may be harvested.

Enterprise Backup API provides “hooks” to prepare the library’s Millennium system data files for backup so that the library can choose a preferred method to backup the files from disk.



Veritas Networker Client Interface. This provides similar support for Veritas as Legato, which is described above.

The following are interfaces that allow Millennium to interface to external APIs:



LDAP. Innovative’s External Patron Verification product gives Millennium patrons the ability to selfvalidate on the external LDAP server. This product is designed to permit the system to first verify the patron against a more authoritative database for the institution, and then if the patron is in good standing with the institution, to continue with the transaction within the Millennium system and the patron’s record. Patron data held within Millennium can be accessed by third-party systems using URL-based or Web services–based APIs. Single Sign-on. Innovative’s Single Sign-on prod-

uct allows patrons to use authenticated services hosted by various servers on campus while requiring they authenticate only once per session. This eliminates the need to constantly re-key credentials as different participating servers are accessed.



Content Pro API. OAI-PMH Server: Content Pro and Symposia are data providers, and as such, are fully compliant with the current OAI Protocol for Metadata Harvesting. Service providers (e.g. OAIster, Google) can harvest metadata presented in the expected format.



NCIP. The INN-Reach Consortial Borrowing system employs NCIP to transmit circulation transactions to participating non-Millennium ILS systems.

Describe any case studies where one of your customers has been able to perform interesting work with your system through the use of APIs.

Opening Up Library Systems through Web Services and SOA: Hype, or Reality?  Marshall Breeding

Library Technology Reports  www.alatechsource.org  November/December 2009

Legato Networker Client Interface. This product provides support in the Innovative application for the use of third party Legato NetWorker client software. This allows the Innovative server to participate in an enterprise backup scheme using the Legato NetWorker backup software as an alternative to use of the Innovative application’s integrated backup function. It includes the necessary support in the Innovative application and the service of installing the Legato NetWorker client software on the Innovative server.

Encore APIs

Encore Query API. The Encore Query API is a Web service for libraries that want to give their programming staff hands-on control of its own real-time library data. It is a flexible and robust center for creating your own dynamic frontend application interface for data collection and dissemination, or whatever practical appli­ cations you envision. Cataloging data (e.g., bib­ lio­graphic, holding, item, order, checkin) are made accessible through the Encore Query API. This powerful XML-based API can also access Program Registration and Innovative Electronic Resource Management records. PLANNED—Reporter Statistics. Reporter API: Direct access to the star-schema data mart that powers the Encore Reporter using an industry standard tool such as Mondrian will allow libraries with technical staff to pull data and create locally authored reports. API access may be used instead of, or in addition to, the Encore Reporter application. PLANNED—OAI-PHM Server. OAI-PMH Server will allow approved third-party client applica­ tions, such as Google or OAIster, to crawl the library’s bibliographic database and harvest the metadata as needed on a library specified schedule. This functionality will mirror that currently available with both the Content Pro and Symposia products.

Millennium Enterprise Backup API (read-only).



SUSHI. Millennium Electronic Resource Man­

27

RFID integration with Item Status API. We have several instances of the use of Item Status API. • Jefferson County Public Library, Lakewood, CO • Poudre River Public Library District, Fort Collins, CO • Mountain View Public Library, Mountainview, CA Item Status. Patron Update Web Service.12

Information on Item Status API http://brewing.iii.com/2008/09/10/item-status-apinow-working-with-3m-and-envisionware-rfid-systems

Patron Update Web service article www.iii.com/news/it/it_2009_03.pdf

Library Technology Reports  www.alatechsource.org  November/December 2009

In what way do you consider your system to embrace the service-oriented architecture (SOA)?

28

Innovative leverages SOA for the development of new products and for the enhancement of existing products. Our applications leverage SOA using multiple back-end infrastructure components which provide encapsulation, code reuse, and deployment flexibility. In addition we are able to leverage these services for both our own application presentation layer as well as customer-facing APIs. For example, with Encore, using SOA has resulted in an implementation that is distributed, easier to manage, and more extensible and reusable for future development. Are there any other issues regarding APIs that you would like me to be aware of as I develop this report? Are there other approaches that your company supports instead or in addition to APIs for providing end-user access to system data and functionality?

As mentioned earlier, Innovative practices a “needs based” approach to this type of functionality. As libraries identify areas where there are information needs that can be supported by the ILS, we will develop interfaces that support those needs. This also extends to technologies. We implement technologies based on those needs. Whether it results in the implementation of an API or other communication technique, we implement in the manner that best suits the needs of the problem to be solved.

Case Studies and Customer Responses No responses were submitted from libraries that have implemented Innovative Interfaces products that make use of APIs.

Koha The open source Koha ILS has attracted a number of libraries of many different types in many regions of the world. In the United States, Koha has been adopted by a mix of public and academic libraries, primarily in the small to mid-sized range. The system was originally developed in New Zealand in 1999 and has seen continuous development and enhancement in the past decade. In the United States, most libraries implementing Koha have done so through paid service contracts with commercial firms, including LibLime, PTFS, and ByWater Solutions. LibLime ranks as the largest of these firms, has been providing these services the longest, and has the most client libraries. Given its vintage of development, Koha predates the period when most applications were built according to a service-oriented architecture. The software has evolved significantly since its original version. The ILS has become more sophisticated in functionality and has been extended to support a wider range of standards; a limited number of APIs have been added. Koha finds use primarily in smaller libraries that do not necessarily expect to work with their ILS through an API. A large portion of the libraries using Koha rely on a support company for all the technical work involved in implemen­ tation, and many take advantage hosting services. As the dominant company involved with providing support services, LibLime provided responses to the survey questions regarding Koha’s support for APIs. Survey Responses

13

Describe, in general terms, the APIs that your company offers for your primary ILS and other library automation products.

LibLime created and maintains a simple set of RESTful APIs that enable our customers to write applications to interact with their Koha databases. The same set of APIs are implemented in our ‡biblios.net product and are documented at the ‡biblios.net Web services website.

‡biblios.net Web services website https://bws.biblios.net/doku.php

Koha Web Services Overview http://wiki.koha.org/doku.php?id=en:development :web_services

What is the business model for your APIs? Is access to the APIs included with the base product, or is it an extra-cost option?

Access is included with the base product. Do you publish documentation for your APIs? Is it available only to licensed customers, or to third-party developers as well?

Opening Up Library Systems through Web Services and SOA: Hype, or Reality?  Marshall Breeding

The documentation is available to anyone. In a follow-up question LibLime was asked to indicate what documentation of the APIs has been developed.

There are some portions of the Community documentation that are sparse, that’s for sure. Since Koha is open source, it’s assumed that any programmers that need to use the API will just delve into the programming itself. Note that all of the APIs supported in ‡biblios.net are also supported natively in Koha, and they share the same codebase. Does the API operate through REST or SOAP Web services, or does it use proprietary mechanisms for transmitting data and requests?

It operates through REST Web services. Can the API create and modify data, or is it read-only?

Data can be created and modified using the API. Describe the technical architecture of the API.

LibLime’s Web services architecture goes beyond the nebulous so-called “Services Oriented Architecture” and focuses instead on resources using the principles embedded in the Resources Oriented Architecture and in Roy Fielding’s doctoral dissertation in Representational State Transfer.

www.ics.uci.edu/~fielding/pubs/dissertation/rest_ arch_style.htm

Are your APIs able to perform the following types of transactions? (I’ve provided some examples of some specific activities that libraries may want to accomplish, but there may be others that you support that you may want to mention.) Bibliographic records—ability to extract or update metadata on a field-by-field basis, beyond the capabilities of standard protocols such as Z39.50.

Yes. Item/holdings records—ability to respond to realtime requests for availability, circulation status, etc.; ability for external applications to execute circulation transactions for check-outs, returns, holds, etc.

Yes. Patron records—personal details, demographic data, au­thentication credentials, materials charged or re­quested, etc.; real-time synchronization with ex­­ternal au­thoritative repositories of user populations.

Yes.

Yes. Acquisitions and financial data—ability to interact with external accounting or ERP systems.

Yes, in theory, though there are no live examples. Vendor records—synchronization with external ERP

Yes. Please feel free to mention any case studies where one of your customers has been able to perform interesting work with your system through the use of APIs.

We’re unaware of any customers that even know what an API is. Most of the time we simply provide tools and widgets that access the various APIs embedded in our products and our customers use those tools/widgets. APIs for LibLime are not an add-on afterthought; they are how the product is actually designed. The most interesting application of our APIs exists on the ‡biblios.net Web services platform. Quite a few libraries have used Koha’s built-in cataloging editor to contribute to the ‡biblios.net platform, which uses the API even if they don’t know it does. The cataloging editor in ‡biblios uses the authority Web service to provide an auto-complete dropdown list of authority records in authority controlled fields. We have a few Koha customers that synchronize patron data with LDAP.

Case Studies and Customer Responses No responses were received from libraries using Koha reflecting their use of APIs or Web services.

Polaris Polaris, based in Syracuse, New York, focuses on the public library arena. The company offers the Polaris Integrated Library System. The company was originally created as a division of Gaylord, but became an independent company in 2003 when Gaylord was acquired by Demco. Polaris was introduced around 1997 and has steadily increased its customer base ever since. Polaris finds use in public libraries of all sizes; in recent years, it has found inroads into the municipal library arena with sales to Phoenix Public Library and Miami Public Library. From its beginning, Polaris has been designed to accommodate large

Polaris

Library Technology Reports  www.alatechsource.org  November/December 2009

Roy Fielding, doctoral dissertation, chapter 5, “Representational State Transfer (REST)”

Circulation transactions/history—detailed usage data for collections, user categories, etc.

www.polarislibrary.com

Opening Up Library Systems through Web Services and SOA: Hype, or Reality?  Marshall Breeding

29

libraries. With this emphasis on larger libraries comes an expectation for the extensibility offered through APIs. 14

Survey Responses

Describe, in general terms, the APIs that your company offers for your primary ILS and other library automation products.

The Polaris API needs to be viewed in context with the underlying architecture of the Polaris ILS. The Polaris ILS is an open database. Polaris customers have a fully documented copy of the database schema and, with knowledge of SQL, can freely access and leverage the database without permission or assistance from Polaris. The Polaris API simply enables customers to take this level of access and control a step further by ensuring that any enhancements or procedures written against the Polaris ILS are automatically updated against any changes to Polaris’s stored procedures. Essentially, as the Polaris ILS evolves with every release, so do the enhancements created by the customer. What is the business model for your APIs? Is access to the APIs included with the base product, or is it an extra-cost option?

Library Technology Reports  www.alatechsource.org  November/December 2009

The API is an extra-cost option due to the level of ongoing support needed to maintain the product.

30

Do you publish documentation for your APIs? Is it available only to licensed customers, or to third-party developers as well?

Yes, Polaris does publish documentation regarding the API for our customers. Customers are free to share that documentation with third-party developers at their discretion. Does the API operate through REST or SOAP Web services, or does it use proprietary mechanisms for transmitting data and requests?

The API uses standard database communication mechan­ isms, such as JBDC, ODBC, OLEDBC, ADO, etc. Polaris chose this approach because they are existing standards. In addition, this approach is more secure and better pro­ tects the integrity of the customer’s data, as you need to be inside the customer’s network to access the database. However, Polaris does offer a SOAP-based holdings Web service that provides item level call number, location, availability and real-time status information. The Web service is provided at no cost as part of the PAC Web application and includes documentation on its use and example service calls. Can the API create and modify data, or is it read-only?

Yes, the Polaris API enables the customer to create and modify data.

Please describe the technical architecture of your APIs.

The Polaris API is a database of stored procedures exposed through standard database communication mechanisms including JBDC, ODBC, OLEDBC, ADO, etc. Are your APIs able to perform the following types of transactions? (I’ve provided some examples of some specific activities that libraries may want to accomplish, but there may be others that you support that you may want to mention.) Bibliographic records—ability to extract or update metadata on a field-by-field basis, beyond the capabilities of standard protocols such as Z39.50.

Polaris provides the capability for complete and flexible extraction of bibliographic content through the Simply Reports Export Express product, not through the API. Item/holdings records—ability to respond to real-time requests for availability, circulation status, etc.

Yes, the API is able to perform this type of trans­action. Ability for external applications to execute circulation transactions for checkouts, returns, holds, etc.

The API does address renewals and holds, but does not address returns and checkouts. However, customers can use SIP to accomplish these types of transactions. Patron records—personal details, demographic data, authentication credentials, materials charged or requested, etc.

Yes. The API does perform these types of trans­ac­tions. Real-time synchronization with external authoritative repositories of user populations.

This can be accomplished without the API. Polaris has a utility that interfaces with Civic Technologies . Circulation transactions/history—detailed usage data for collections, user categories, etc.

This can be accomplished without the API by querying the database through the use of Simply Reports or SQL Reporting Services. Acquisitions and financial data—ability to interact with external accounting or ERP systems.

Polaris has developed a utility for interaction with external financial systems through a generic XML-based data interchange. The adaptability of this model is dependent on the capabilities of the financial system with regards to data exchange with external systems. This interface has been integrated at Dallas Public Library with the Advanatage 3 Financial System. Vendor records—synchronization with external ERP.

No, the API is not able to perform this type of transaction.

Opening Up Library Systems through Web Services and SOA: Hype, or Reality?  Marshall Breeding

Please feel free to mention any case studies where one of your customers has been able to perform interesting work with your system through the use of APIs.

Phoenix Public Library has been able to interface with Endeca for the PAC. Also, Henderson District Public Libraries in Nevada has leveraged our open database, without the need for an API, for quite some time (they also have our API). As one example, Henderson wrote their own .NET application that uses the Polaris database and the Stamps.com API to generate overdue and hold notices in postcard format. The notices, including postage, are printed in-house by the circulation department and mailed. Patron accounts are updated automatically. In addition to reducing staff time, notices are turned around faster, and the library saved significantly on printing and postage.

can be supplemented with Export Express, Polaris’s export utility, to enable users to easily extract records from the database and save them in exportable format. Essentially, Polaris strives to provide a balance for our user community–an open system, but one that is fully functional and enables our customers to focusing on meeting the needs of their communities.

Case Studies and Customer Responses No responses were received from libraries using Polaris reflecting their use of APIs or Web services.

SirsiDynix

Polaris offers a SOAP-based holdings Web service that provides item level call number, location, availability and real-time status information. The Web service is provided at no cost as part of the PAC Web application and includes documentation on its use and example service calls. Whenever possible, any integration with third party content providers is done through Web services published by the vendors. Polaris currently consumes Web services from NoveList Select, Baker & Taylor’s Content Café, and Syndetics, as well as Baker & Taylor, Ingram, BWI & United Library Services for Titles to Go.

SirsiDynix, a consolidated company formed through a series of business acquisitions, offers Symphony as its primary ILS. The company also continues to support Horizon and Dynix Classic. SirsiDynix has library customers in many regions of the globe spanning many different library types. Its customers run the gamut of large research libraries to small public libraries. The company faces the need to provide powerful flexible tools to its larger customers that have more complex automation needs while delivering fully managed self-contained systems for others. One of the key business strategies involves an emphasis on software-as-a-service (SaaS). SaaS is quite consistent with the use of APIs, but tends to be implemented by libraries of smaller size and complexity, which are less likely to take advantage of APIs.

Are there any other issues regarding APIs that you would like me to be aware of as I develop this report? Are there other approaches that your company supports instead or in addition to APIs for providing end-user access to system data and functionality?

Polaris offers tools that enable customers of all skill levels to access their data. For library staff with technical skills, the Polaris API is easy to use, intuitive and supplements the “openness” that is built into the fabric of the system. For customers who do not have this level of technical skill, or who are not interested in devoting staff resources to these types of projects, Polaris offers tools to make it easy to access the data and interface with other vendors, without the customer needing a programming background. As noted above, much of the functionality you inquired about can be accomplished without the need for an API or advanced programming skills on the part of our customers. As an additional example, SimplyReports, Polaris’s Web-based reporting tool, enables customers to build hundreds of thousands of custom reports using a GUI interface. With SimplyReports, customers point and click to the data elements they are interested in—requiring no programming skills or knowledge of SQL. SimplyReports

SirsiDynix www.sirsidynix.com

Symphony, formerly known as Unicorn, has been steadily evolving since it was introduced in the early 1980s. SirsiDynix (then Sirsi Corporation) became the first ILS vendor to enable its customer libraries access to its internal API in late 1995. This API offered comprehensive access to all the data and functions of the underlying Unicorn system. It operated at the UNIX command line and generally returned results as pipe-delimited text. SirsiDynix offers training for its customers that want to use the API. While the company charges for this training and generally prefers that libraries not use the API unless they have taken this training, there is no additional license fee involved with the API itself. Since the Unicorn API allows libraries to create and modify data records, those making use of it must work with great skill and care to ensure that no databases are

Opening Up Library Systems through Web Services and SOA: Hype, or Reality?  Marshall Breeding

Library Technology Reports  www.alatechsource.org  November/December 2009

In what way do you consider your system to embrace the service-oriented architecture?

31

damaged or corrupted. Use of the API can result in support questions of great complexity. The API gives the library programmer great power to work with the system; with that power comes the responsibility not to allow an error in a custom script to wreak havoc on the library’s data. Survey Responses15

Library Technology Reports  www.alatechsource.org  November/December 2009

Describe, in general terms, the APIs that your company offers for your primary ILS and other library automation products.

32

SirsiDynix provides multiple APIs with our various products. We provide the following: Symphony APIs. Approximately 415 API commands into the Symphony Application server. All of the SirsiDynix clients (Java Workflows, e-Library, StaffWeb) use these same APIs that are available to the customer. SIP APIs. We fully support SIP and provide entry points into our SIP Server NCIP APIs. We fully support NCIP and provide entry points into our NCIP Server Symphony Web Services. We provide a set of Web service (SOAP and RESTful) methods to the Symphony Server Discovery Platform Web Services. We provide a set of Web services (SOAP today and RESTful shortly) into the Enterprise Platform. The Horizon and Dynix products provide full and direct access to the database, so many customers use standard SQL tools to interact directly with the database. The Symphony product provides either an embedded database or a full use database, depending on customer preferences and pricing. With a full use database, the customer also has direct access to the data in the database and can use standard SQL tools to interact with the database. Summary of APIs and Web services:

SIP API—Industry standard for self-service circu-

lation used by Horizon and Symphony • Supports 15 standard SIP messages • Supports 5 proprietary SIP messages NCIP API—Next generation of SIP • Supports 15 standard messages Symphony API (HAT Protocol)—Full access to Symphony • 415 supported HAT commands Symphony Web Services—Simplification of HAT API • Version 1: Supports 30–40 Web service methods

• Version 2: Roadmap—target mobile, e-Library and JWF APIs Discovery Platform Web Services—Used by Enterprise, SchoolRooms and Hyperion applications • 10 Web services (WSDLs): 146 methods What is the business model for your APIs? Is access to the APIs included with the base product, or is it an extra-cost option?

All APIs and Web services are automatically in­stalled and available to our customers. Customers are not required to purchase our training subscription but are strongly encouraged to do so. It is an extra optional cost that provides technical documentation, hands-on lab experience, source samples, etc. Do you publish documentation for your APIs? Is it available only to licensed customers, or to third-party developers as well?

Yes, we publish hundreds and hundreds of pages of tech­ nical documentation and descriptions for our APIs and Web services. Does the API operate through REST or SOAP Web services, or does it use proprietary mechanisms for transmitting data and requests?

Both. Our Symphony API is a proprietary protocol utiliz­ ing TCP/IP sockets and formatted strings for all of the com­mands, parameters, and return values. Our Web ser­ vices are implemented with both SOAP and REST. Can the API create and modify data, or is it read-only?

All APIs and Web services can modify data and also re­trieve read-only data. Describe the technical architecture of your APIs.

The Symphony APIs (proprietary protocol) provide access to 100% of the back end Symphony functionality. Our own client applications utilize this protocol and these APIs. The Symphony Web Service is architected to be more modular. We are focusing extensive research and design effort into grouping together related Web service calls into a Web service and then providing multiple Web services (WSDLs) that provide more meaningful functional separation. These individual Web services provide a true SOA. The Enterprise Discovery Platform Web services consist of 10 distinct services with our release of Enterprise V3. The Enterprise patron user interface and the Enterprise administrative user interface utilize these 10 Web services exclusively. These are the same Web services we’ll release to our customers. The following picture [see figure 9] shows this architecture. Are your APIs able to perform the following types of transactions? (I’ve provided some examples of some

Opening Up Library Systems through Web Services and SOA: Hype, or Reality?  Marshall Breeding

Consistent Application Interfaces

Reuse within Services

Numerous Data Sources

Figure 9 SirsiDynix technical architecture.

Bibliographic records—ability to extract or update metadata on a field-by-field basis, beyond the capabilities of standard protocols such as Z39.50.

Yes. Item/holdings records—ability to respond to real-time requests for availability, circulation status, etc.; ability for external applications to execute circulation transactions for check-outs, returns, holds, etc.

Yes.

Vendor records—synchronization with external ERP.

Yes, we can retrieve vendor records and also have customers who have used our API to synchronize and external ERP with the records in the Symphony database. Describe any case studies where one of your customers has been able to perform interesting work with your system through the use of APIs.

We’ve had numerous customers utilize our APIs to write client applications and also use scripting tools to automate their various unique business practices. In what way do you consider your system to embrace the service-oriented architecture?

Acquisitions and financial data—ability to interact with external accounting or ERP systems

A true SOA provides distinct services that are well defined, documented, and easy to use. With our new Web services and architecture, development tools can consume our WSDLs and create stub implementations to our services within minutes. We are now soliciting the help of our customer base, vendors, and others thru our Strategic Partner Program. The partners will be helping us define additional services and also to enhance our existing services. Our Enterprise V3 product was 100% written based on the Discovery Web Services. We spent a tremendous amount of time designing these services with SOA in mind.

Yes, we can retrieve vendor records and also have customers who have used our API to syn­chronize and external ERP with the records in the Symphony database.

Are there any other issues regarding APIs that you would like me to be aware of as I develop this report? Are there other approaches that your company supports instead

Patron records—personal details, demographic data, authentication credentials, materials charged or re­-quested, etc.; real-time synchronization with external authoritative repositories of user populations.

Yes. Circulation transactions/history—detailed usage data for collections, user categories, etc

Yes.

Opening Up Library Systems through Web Services and SOA: Hype, or Reality?  Marshall Breeding

Library Technology Reports  www.alatechsource.org  November/December 2009

specific activities that libraries may want to accomplish, but there may be others that you support that you may want to mention.)

33

or in addition to APIs for providing end-user access to system data and functionality?

As mentioned above, direct database access is available to our Horizon/Dynix customers. Direct database access is also a possibility with our Symphony product depending on the licensing arrangement with the customer.

Case Studies and Customer Responses No responses were received from libraries using Sirsi­ Dynix reflecting their use of APIs or Web services.

Library Technology Reports  www.alatechsource.org  November/December 2009

Talis

34

Talis, a library automation company based in Birmingham, United Kingdom, offers the Talis Library Management Suite (LMS), used exclusively in the United Kingdom. While the company focuses its business activities primarily in the United Kingdom, it has been a proponent of the service-oriented architecture and semantic Web technologies to a much wider audience. Representatives from Talis have been actively involved in conferences and at other venues outside the United Kingdom, especially in the United States, promoting Web 2.0 technologies, SOA, and the semantic Web. The company has been involved in providing open source tools while it continues to license proprietary software.

Talis

these limitations, Talis supplements its efforts on traditional library software development with the creation of an SOA framework that can be used in the creation of integration products. Within the library market, these tools might provide interoperability between Alto and the business systems of the local authorities or a university. Ambitiously, Talis also sees its integration products finding use with its competitors’ LMS products. Taken more broadly, Talis sees its SOA framework as having the capability to address other business scenarios where interoperability can be accomplished through Web services. As noted below, Talis offers a set of licensed, commercial quality products as modules of a broader platform called Keystone. Talis is also involved in a project called Jangle, a specification of a middleware layer that can be applied to any ILS to expose a standard set of services through the Atom Publishing Protocol. Some open source implementations have been built around the Jangle specification. The basic idea involves building a core middleware layer that can be associated with any ILS in order to provide a standard set of services as Atom feeds. The key to implementing Jangle involves creating a connector between the proprietary or idiosyncratic APIs of any given ILS to the Jangle core. Talis staff have been involved in the creation of the Jangle specification and in open source projects to implement it. Yet the company does not assert ownership of the project, but rather promotes involvement of a broader community of open source developers. Jangle, for example, has been positioned as one of the methods for providing connections between the open source VuFind discovery interface and an ILS.

Jangle http://code.google.com/p/jangle

www.talis.com

Alto, the company’s primary integrated library system (or library management system in UK parlance) has been adopted primarily by public and academic libraries. The Alto automation system has evolved steadily over a long history of development. While Alto itself was created prior to the age of APIs, Web services, and SOA, the company has developed a strategy of creating integration products that layer APIs in the form of Web services onto existing traditional products. In recent years, Talis has increasingly defined its technology strategy around the service-oriented architecture. The company continues to develop and support its traditional products and services, but has produced a new set of products that rely on SOA to connect library products with other institutional technology infrastructure components. The LMS marketplace in the United Kingdom, where Talis does business, presents very limited opportunities for major new sales. This finite body of libraries offers only a handful of LMS procurements each year. Given

Survey Responses Author’s Note: Talis did not provide direct answers to the questions, but submitted a draft of a white paper that addresses the topic. Excerpts of this paper have been selected in response to the survey questions. Describe, in general terms, the APIs that your company offers for your primary ILS and other library automation products.

“Talis SOA is a continuously evolving architecture which is the technical engine behind three commercial areas.

Talis Keystone is the product which enables institutional integration for both academic institutions and local authorities across multiple Library Management Systems in the areas of portal integration, online payments of library fines and charges, integration with corporate finance systems, inte-

Opening Up Library Systems through Web Services and SOA: Hype, or Reality?  Marshall Breeding

gration with identity systems - such as student registries and IDentity Management (IDM) services and Customer Relationship Management (CRM) systems. Talis Keystone is a fully managed product, backed by the Talis Consulting department who are experienced in providing integration project services to customers enabling them to tailor their integrated solution to meet their exact commercial requirements. Talis Connect Services is the licence issued to Talis customers to enable them to provide interoperability with third party suppliers who are members of the Talis Additions Partnership Programme. Working closely with our partners to implement an integrated solution on top of the web service stack in the Talis SOA architecture, we at Talis are able to give our customers the assurances that their products fully interoperate with their library management solution. Talis Local Data Services is the component inside of the Talis Library Management System (Alto) which provides internal interoperability for features inside of the Talis product portfolio. Talis products are using the SOA architecture as the interface to the business logic and services of the core library system; over time more products and services will evolve over to this architecture.”16

“Talis Keystone is a licensed product with a central middleware and a series of bolt on modules that can be activated as required, depending on the business requirements of the library service. This gives customers choice and flexibility to create the integration solutions that they require, rather than imposing a suite of solutions which may not be entirely relevant. As well as the middleware license, each module also has a license fee. Talis Connect Services has a similar business model to Talis Keystone; however, Talis Local Data Services is part of the Talis Alto (Library Management System) subscription.”17 Do you publish documentation for your APIs? Is it available only to licensed customers, or to third-party developers as well?

Author’s note: Information both from Talis and customer sites indicates that the company provides extensive documentation for its APIs. Customer comments indicate that only licensed sites receive access to that documentation. Does the API operate through REST or SOAP Web services, or does it use proprietary mechanisms for transmitting data and requests?

Can the API create and modify data, or is it read-only?

Author’s note: The APIs described in the white paper include ones that involve transactions that modify library data as well as those that read and report data. Describe the technical architecture of the API.

“The Talis SOA architecture is a standalone appliance which is designed with the principles of componentisation, reusability, interoperability, orchestration and loose coupling at its core. Over time, the use of SOAP based web services has been fully replaced with a growing portfolio of approximately seventy RESTful web services in various functional areas. Based upon the Java platform and on open standards such as XML and http the web services have enabled developers in libraries, in other institutional departments and in third party suppliers to easily integrate their solutions with their library management system.”19 Are your APIs able to perform the following types of transactions? (I’ve provided some examples of some specific activities that libraries may want to accomplish, but there may be others that you support that you may want to mention.)

Author’s note: Appendix B of the white paper provides an inventory of the Web services offered by Talis. Business areas addressed include MyAccount, Finance, e-pay, borrower services, circulation, loan services, charge services, message services, item services, and system services.20 Please feel free to mention any case studies where one of your customers has been able to perform interesting work with your system through the use of APIs.

Author’s note: Talis describes several organizations that have purchased its integration components: Queens University Belfast licensed Talis Keystone to support e-payments. The project involved using Keystone to connect the Talis LMS with WorldPay, an internet payment solution through the campus portal.21 A similar project took place at the University of Wolverhampton which “chose to link directly

Opening Up Library Systems through Web Services and SOA: Hype, or Reality?  Marshall Breeding

Library Technology Reports  www.alatechsource.org  November/December 2009

What is the business model for your APIs? Is access to the APIs included with the base product, or is it an extra-cost option?

“The Talis SOA architecture is a standalone appliance which is designed with the principles of componentisation, reusability, interoperability, orchestration and loose coupling at its core. Over time, the use of SOAP based web services has been fully replaced with a growing portfolio of approximately seventy RESTful web services in various functional areas. Based upon the Java platform and on open standards such as XML and http the web services have enabled developers in libraries, in other institutional departments and in third party suppliers to easily integrate their solutions with their library management system.”18

35

from the university web page to the e-Payment provider. Students and staff can discover the amount that they owe to the library and can conveniently pay their fines and charges online. This seamless transaction from the university web page to the e-payment provider is enabled using Talis Keystone to integrate the two systems and provide an enhanced service for students.”22 The University of Manchester, licensed Talis Keystone to integrate their Ex Libris Voyager LMS with their campus portal based on Microsoft SharePoint allowing students to view library information including number of items charged, items overdue, and fines owed.23 Customer Perspectives and Comments

Library Technology Reports  www.alatechsource.org  November/December 2009

A systems manager in a library that uses Talis Alto and Keystone offers some perspective of the Talis approach to APIs:

36

Talis uses a framework called Keystone for providing APIs to the system. You can use either SOAP or REST with Keystone. Keystone has a “core” module to provide the framework and then you purchase “modules” that provide specific functionality. We currently have the “View My Account” module installed and we use this to display borrowers’ account details in the campus portal. We are about to install the “Borrower ePayments” module which allows fines and charges to be paid online. One module we would like to install in future is the acquisitions/finance system link so we can send processed invoices to our finance system automatically for payment. Keystone at the moment certainly does not offer access to all the features of the Talis system. However, this is because Talis have not yet written modules. I suspect this will be all driven be demand—if you are willing to pay for a module, Talis will, I’m sure, be willing to write it. Therefore, I don’t think Talis are trying to keep their system closed. The APIs are well documented, though we did have an issue of not being able to get the ePayment API doc before we purchased, so it was very difficult to work out exactly what it did and what we were actually buying. I think you need to have a reasonable level of programming skill to use these APIs, even though the REST interface is pretty straightforward. Systems librarians without formal programming training and who are perhaps used to making small changes to letter scripts, would probably struggle. I’ve got more of a programming background and I don’t really have the time to spend on it. The “View My

Account” work was done by our portal developers who are web developers. For the “ePayments,” Talis actually wrote a front-end application for another customer who didn’t have a portal and we’re using that. I’m not sure if this really is SOA—I’ve never been comfortable that I’ve really understood the term. It always seemed a bit of a buzzword. I’m sure Talis would say that this is SOA! My main concern with Keystone is not anything technical. Because you have to pay for the core and each module plus a heavy annual support fee, it means the cost of these things soon mount and add significantly to the overall cost of the system. Talis are also developing what they call a light­ weight integration protocol called Jangle. This seems quite broad in scope, both in terms of what it will allow access to in the ILS and in the variety of systems it can support (it appears that they have a Jangle connector for a non-Talis system before they have produced one for Talis!) It will be interesting to see what becomes of this.24

VTLS VTLS, based in Blacksburg, Virginia, offers the Virtua ILS, which was initially introduced around 1998. One of the longest standing companies in the industry, VTLS has been in continuous operation since 1974.

VTLS www.vtls.com

A diverse group of libraries have implemented the Virtua ILS, including academic, public, national, and many regional consortia. The customer base of libraries using Virtua is internationally diverse, including the United States, Europe, Asia, Australia, the Middle East, South Asia, and many others. Especially noteworthy among its clientele is the Queens Borough Public Library, the busiest and one of the largest public libraries in the United States. The company has recently announced Chamo, a new public interface for Virtua based on the open source Drupal extensible content management system. One of the characteristics of Chamo that VTLS emphasizes is an architecture that directly accesses the Oracle database API rather than functioning through the Virtua server application. VTLS serves many libraries with very complex automation needs and performs a great deal of custom development of its systems. This niche of the library automation arena expects more than off-the-shelf functionality, making support for APIs especially vital.

Opening Up Library Systems through Web Services and SOA: Hype, or Reality?  Marshall Breeding

Survey Responses25 Describe, in general terms, the APIs that your company offers for your primary ILS and other library automation products.

Both APIs and database views to support special needs are available to customers. SOAP is used in VITAL; Chamo’s API is a simple XML over http service. It will support SOAP in the next release. What is the business model for your APIs? Is access to the APIs included with the base product, or is it an extra-cost option?

Database views are free. APIs are licensed to cus­tom­ ers that license the primary product (Virtua or VITAL). Do you publish documentation for your APIs? Is it available only to licensed customers or to third-party developers as well?

Yes, APIs are documented, but available only to customers with an active license. Does the API operate through REST or SOAP Web services, or does it use proprietary mechanisms for transmitting data and requests?

SOAP is supported in VITAL only. (Note from VTLS: VITAL is VTLS’s institutional repository product based on Fedora.) Can the API create and modify data, or is it read-only?

Describe the technical architecture of your APIs

The API is part of the main Chamo application, a Java EE servlet. Since the API is simple XML over http, it uses the same servlet technology as the standard Web interface. Are your APIs able to perform the following types of transactions? (I’ve provided some examples of some specific activities that libraries may want to accomplish, but there may be others that you support that you may want to mention.) Bibliographic records—ability to extract or update metadata on a field-by-field basis, beyond the capabilities of standard protocols such as Z39.50.

Single API call to retrieve all bibliographic data including the full record in MARCXML format, and all item information including availability, and serials issues. There are no smaller or more granular operations. (Our API design is focused on simplicity.)

Item/holdings records—ability to respond to realtime requests for availability, circulation status, etc.; ability for external applications to execute circulation transactions for check-outs, returns, holds, etc.

Yes—see above. Patron records—personal details, demographic data, au­thentication credentials, materials charged or re­quested, etc.; real-time synchronization with external authoritative repositories of user populations.

There are two API calls here: • Authenticate a patron via ID and password • Retrieve all patron details, including contact information, checkouts, requests, and fines. Circulation transactions/history—detailed usage data for collections, user categories, etc.

This is part of the previous API. There are no APIs for this data except the patron-related ones. Acquisitions and financial data—ability to interact with external accounting or ERP systems.

Yes, but only available through Edifact. Vendor records—synchronization with external ERP.

No, not supported. In what way do you consider your system to embrace the service-oriented architecture?

SOA is implemented in full scale add-on products like FRBR SaaS.

Case Studies and Customer Responses No responses were received from libraries using VTLS reflecting their use of APIs or Web services.

Notes 1. Marshall Breeding, “Ex Libris Sets Strategic Course on Open Systems,” Smart Libraries Newsletter, Aug. 2008; “Ex Libris Launches Open-Platform Program, Reaffirming Its Commitment to Openness as a Core Company Value,” Ex Libris press release, June 29, 2008, www.librarytechnology .org/ltg-displaytext.pl?RC=13372 (accessed Oct. 14, 2009).

Opening Up Library Systems through Web Services and SOA: Hype, or Reality?  Marshall Breeding

Library Technology Reports  www.alatechsource.org  November/December 2009

The APIs allow users to place and modify patron requests and perform renewals. The rest is read-only: search, availability information, and patron information including fines, checkouts, and requests. If users choose to work with Z39.50 and its extensions, then they can access or modify any and all data within the database.

API calls that update item information: • Renew a checked out item for a patron. • Request an item for a patron. • Modify an existing request • Cancel a request

37

Library Technology Reports  www.alatechsource.org  November/December 2009

2. Tamar Sedeh, telephone interview by the author, Aug. 13, 2009. 3. Tamar Sadeh, e-mail and telephone interview by the author, including a Web demo of the EL Commons, Aug. 13, 2009. 4. Ken Mitchell, e-mail interview by the author, Aug. 31, 2009. 5. Mike Curtis, e-mail interview by the author, Aug. 24, 2009. 6. Mike Rogers, e-mail interview by the author, Aug. 20, 2009. 7. ILS manager at National Library of Australia, e-mail interview by the author, July 27, 2009. 8. Brad LaJeunesse, president, Equinox Software, e-mail interview by the author, July 26, 2009. 9. Gar Sydnor, senior vice president, The Library Corporation, e-mail interview by the author, Aug. 6, 2009. 10. Gene Shimshock, vice president of marketing, Innovative Interfaces, e-mail interview by the author, Aug. 13, 2009. 11. Ibid. 12. Innovative Interfaces, “At University of Lethbridge (Canada), Machines Talk When People Talk: Patron Web Services Keeps Library in Synch with Campus,” INN>Touch 22, no. 4 (March 2009): 4, www.iii.com/news/it/it_2009_03.pdf. 13. Joshua Ferraro, CEO, LibLime, e-mail interview by the author, Aug. 18, 2009. 14. Kathryn Miller, director of marketing, Polaris, e-mail interview by the author, Aug. 14, 2009.

38

15. Talin Bingham, chief technical officer, SirsiDynix, e-mail interview by the author, Aug. 28, 2009. 16. Andy Latham, “Opening the Wall of the Library: SOA and Web Services at Talis” (Aug. 2009): 3, www.talis.com/inte gration/documents/talis_SOA_white_paper_august_2009 .pdf (accessed Aug. 30, 2009). 17. Ibid., 4. 18. Ibid. 19. Ibid. 20. Ibid, 21–23. 21. Ibid, 20; see also “Students at Queen’s University Belfast Can Now Pay Their Library Fine Online with Debit and Credit Cards,” Talis press release, Jan. 10, 2008, www.librarytech nology.org/ltg-displaytext.pl?RC=12971 (accessed Oct. 1, 2009). 22. “Online Payments for Students at the University of Wolver­ hampton,” Talis press release, Dec. 4, 2008, www.librarytech nology.org/ltg-displaytext.pl?RC=13696 (accessed Oct. 1, 2009). 23. Latham, “Opening the Wall,” 5. 24. Anonymous [a systems manager in a library that uses Talis Alto and Keystone], e-mail interview by the author, Sept. 1, 2009. 25. Vinod Chachra, president and CEO, VTLS, e-mail interview by the author, Sept. 1, 2009.

STATEMENT OF OWNERSHIP AND MANAGEMENT Library Technology Reports, Publication No. 024-897, is published 8 times per year by the American Library Association, 50 E. Huron Street, Chicago, IL 60611-2795. It is the official publication of ALA Techsource, a unit of the publishing department of the ALA. Annual subscription price, $325. American Library Association, 50 E. Huron Street, Chicago, IL 60611-2795, owner and publisher; Dan Freeman, 50 East Huron Street, Chicago, IL 60611-2795, editor. Periodicals postage paid at Chicago, Illinois, and additional mailing offices. Printed in U.S.A. As a nonprofit organization authorized to mail at special rates (Section 423-12, Domestic Mail Manual), the purpose, function, and nonprofit status of this organization and the exempt status for federal income tax purposes has not changed during the preceding twelve months. EXTENT AND NATURE OF CIRCULATION (“Average” figures denote the average number of copies printed each issue during the previous twelve months. “Actual” figures denote actual numbers of copies of single issue published nearest to the filing date—August/September 2009 issue.) Total number of copies printed: Average, 1,391; Actual, 1,339. Sales through dealers and carriers, street vendors, counter sales, and other paid distribution outside USPS: Average: 110; Actual: 105. Total paid and/or requested circulation: Average, 796; Actual, 759. Free distribution by mail, carrier, or other means, samples, complimentary and other free copies: Average, 0; Actual, 0. Total distribution: Average, 1,006; Actual, 961. Copies not distributed: office use, leftover, unaccounted, spoiled after printing: Average, 385; Actual, 378. Total (previous two entries): Average, 1,391; Actual, 1,339.

Opening Up Library Systems through Web Services and SOA: Hype, or Reality?  Marshall Breeding

Chapter 3

Observations and Conclusions API Hype and Reality

Abstract

I

n this report, we have seen a wide variety of approaches to the way that APIs can be incorporated into integrated library systems. Many examples demonstrate the benefits that libraries gain through access to a welldeveloped API for their ILS. We have also noted that this capability appeals to only a relatively narrow niche of libraries. The majority of libraries expect the ILS, an entity in which they have invested significant resources, to deliver the functionality they require as-is without the need for them to perform local programming. APIs find their most enthusiastic adherents in larger libraries with complex automation requirements. As the general software arena gravitates more toward the service-oriented architecture, it will become increasingly important for all library automation products to evolve accordingly.

Opening Up Library Systems through Web Services and SOA: Hype, or Reality?  Marshall Breeding

Library Technology Reports  www.alatechsource.org  November/December 2009

This chapter of “Opening up Library Systems through Web Services and SOA: Hype or Reality” examines the general conclusions that can be drawn from the data developed in this report. The evidence gathered in this report reflects ongoing progress toward more openness in library automation systems, but also that much work remains. We see a variety of options and opportunities. Libraries that expect to work with their automation system as delivered and not become involved in local extensions or programming will find that the majority of systems were built for that kind of use. For libraries that want to do more with their automation systems, however, we see a great deal of functionality possible today through open interfaces, with momentum toward creating much more.

In broad terms, we found no glaring inconsistencies between the claims made by vendors for opening up their systems through APIs and the capabilities actually delivered. APIs that function as important tools that find use in strategic library projects have been created and documented, particularly in the ILS products used by large academic and municipal libraries. Yet even with those that place the highest emphasis on exposing their systems through Web services and other APIs, many gaps remain in areas not yet addressed. We also note that the two open source systems lag behind proprietary systems in terms of customer-facing APIs that result in tangible activities which extend functionality or enable interoperability. While the open source model may offer many other advantages, we see fewer APIs designed for library customer use and a much lower level of activity among libraries executing projects that make use of this approach. This trend has much to do with the demographics of the libraries using the software. Developers of open source ILS products find these programs in an early level of maturity and continue to focus on expanding the core functionality to meet basic expectations. By and large, the kinds of libraries that would make use of an open API have not adopted open source ILS products. Although we see many ILS products that offer extensive APIs, we found no products that meet the ideal of comprehensive access to data and functionality through an open API. Even those with the most advanced APIs have work left to do in the quest toward fully open systems. Having collected information from and about each of this slate of companies and products, we can offer some general observations. Ex Libris makes the strongest claims toward open systems. It promotes its Open Platform Program as one of

39

Library Technology Reports  www.alatechsource.org  November/December 2009 40

its key business and technology strategies. To a very large extent, we see substance behind the program and that Ex Libris has put more tools in the hands of its customers than have its competitors. Yet we received comments from its customers indicating that gaps remain. Some aspects of functionality have not yet been addressed by the current set of APIs. The Open Platform Program was launched recently; the success of the program will be marked by the delivery of more APIs, more documentation, more consistency among the APIs, especially in libraries becoming more engaged in their use. While each of Ex Libris’ products offers APIs in some way and in varying levels of scope, the company’s concerted effort to rework the APIs of each of its separate products into a more unified and comprehensive body has just begun. Many of these APIs expose services provided by legacy software. As Ex Libris completes development of its Universal Resource Management (URM) product, the possibility of a more comprehensive and consistent set of APIs may be realized. We noted much more support for open APIs in Aleph 500 than in Voyager, which Ex Libris acquired from Endeavor Information Systems. Ex Libris has the most at stake in this arena. The centrality of this issue to this company is reflected in the detailed response to our survey questions and in the number of customer sites interested in relating their experiences. While some of the other companies have some portion of their customers that may have an interest in making use of an API, Ex Libris focuses on libraries that consider these capabilities as a basic expectation. Large research libraries, national libraries, and consortia require systems that they can extend and expand. While a customer-facing API may be a minor consideration for other companies, it’s a basic expectation for the kinds of libraries that Ex Libris aims to serve. SirsiDynix offers one of the most comprehensive APIs for its flagship Symphony in the field of ILS providers. Sirsi Corporation, one of the antecedent companies of SirsiDynix, pioneered the territory of putting a full API into the hands of the libraries that use its product. The APIs made available at that time for Unicorn continue as that system evolved into the product now offered under the Symphony brand. That family of APIs, while comprehensive, operates through proprietary command-line utilities. Yet, with a library programmer trained in their use, they give access to every element of functionality and data. By policy, access to the API was originally limited to libraries that participated in the company’s training program to mitigate the complex support calls related to its use. Today, SirsiDynix indicates it has relaxed these restrictions. More recently, SirsiDynix has developed a growing set of APIs that follow a more open architecture. Though the number of APIs available through RESTful Web services is relatively small, it represents important progress

in the evolution from a proprietary API to one more consistent with current technology preferences and that will be more easily consumed by its customer libraries. At this point, the number of Web services that it offers represents a small subset of the functionality of the whole system as seen in its proprietary API. In recent years, Innovative Interfaces has increasingly focused on developing technologies that provide more open access to its products. Traditionally, Innovative has operated as a turnkey vendor that takes full responsibility for the products as they are used by its customer libraries and has enforced fairly tight control over the management of those systems. That approach feeds perceptions that the company’s products are less open. The company has created a number of components that deliver APIs in specific functional areas. While the number of API products may be limited, the business model of licensing them discretely seems defensible given Innovative’s general model for software pricing. In recent years, the company has been engaged in the development of Encore, which embraces a modern, service-oriented approach. The (separately licensed) Encore Query API provides a strong set of Web services that will be of benefit to libraries that require programmatic access to their systems. The open source Evergreen ILS, the most recently minted product of the group represented in this report, may be the one that can most defensibly claim a service-oriented architecture. Its foundation on the OpenSRF framework forms the basis of a set of granular services upon which the higher application programming is built. The OpenSRF API seems at this point to be consumed mostly by developers of the system, and less by the libraries that have implemented Evergreen. Again, the demographics of the libraries that use the system come into play. Because the system is implemented primarily by consortia of public libraries, the requirements for extensibility by library customers through the API may be at a lower volume. But as Evergreen moves more into academic libraries, demand for this capability will likely increase. The recent implementation of Evergreen by the Conifer consortia of academic libraries in Ontario may pave the way for others. Today we see Evergreen in an early stage of its maturity cycle. Over time, we expect additional functionality built into the system itself and functionality offered through open APIs. While Koha is an open source ILS, the profile of libraries using this software is not one where interoperability through APIs is a large concern. Most of the libraries using Koha have relatively modest automation scenarios where the automation system as delivered must meet their requirements. The libraries using Koha span a wide range of sizes and types, but the majority of them are relatively small. As a whole, these are not the kinds of libraries that face needs that would be addressed by a user-accessible API. While Koha includes some APIs, at

Opening Up Library Systems through Web Services and SOA: Hype, or Reality?  Marshall Breeding

with the underlying database by providing them access to the full database schema. Like many of other the ILS vendors, Polaris licenses the API separately from the base product. This low-level database-oriented API gives libraries that use Polaris complete access to all aspects of the data managed within the system. Polaris offers far fewer higher-level APIs. A set of Web services delivered through SOAP provide read-only access to elements needed for online catalog displays such as location, call number, and current circulation status. For VTLS, a company that specializes in customized products for complex library automation environments, APIs play an important role. The company offers different approaches to APIs across its product line. VTLS did not provide detailed information regarding the APIs implemented in its Virtua ILS, but the responses indicate that the API addresses some, but not all functionality and data managed within the Virtua application. Its new Chamo discovery interface embodies an API oriented more toward the underlying database than to the higher-level Virtua application server.

Conclusions The evidence gathered in this report reflects ongoing progress toward more openness in library automation systems, but also that much work remains. We see a variety of options and opportunities. Libraries that expect to work with their automation system as delivered and not become involved in local extensions or programming will find that the majority of systems were built for that kind of use. For libraries that want to do more with their automation systems, however, we see a great deal of functionality possible today through open interfaces with momentum toward creating much more. The hype persists. Library automation systems, proprietary and open source alike, compete more and more on the basis of enabling libraries to do more with their systems. That competition for openness drives the development of the technologies that enable that capability. The reality is still a bit messy. While we’ve seen a great deal of functionality exposed through Web services and other APIs, it still takes a lot of hard work to use the APIs in ways that benefit the library. The APIs available to library programmers continue to be quirky and less than comprehensive, even from the vendors with the strongest offerings in this area. We can also tell by the information received that vendors and libraries alike see the need to make systems more open. Hopefully, a better reality will evolve over time.

Opening Up Library Systems through Web Services and SOA: Hype, or Reality?  Marshall Breeding

Library Technology Reports  www.alatechsource.org  November/December 2009

this stage they appear to be only minimally documented and used primarily by the programmers that work with the source code of the application. Talis has established itself as one of the primary companies in the library automation industry that embraces SOA as the key strategic technology for libraries. The company has made a great deal of progress in creating software that helps libraries take existing legacy automation applications and create opportunities for interoperability through Web services. Just as important, the company has taken a leadership role in educating the library community on the benefits of SOA. Keystone, Jangle, and other products and projects have advanced the state of the art in this area of library technology. Alto, the Talis LMS, does not offer a robust set of APIs itself, but rather enables this level of access to become available through Keystone. Keystone connects to Talis, or another LMS, through proprietary techniques, and is then able to expose a set of open APIs in the form of Web services. Libraries using Alto do not gain these points of interoperability unless they also license one or more of the Keystone modules. At this time, Talis has not developed an entirely new library management system built using SOA. This suggests that Alto and its other legacy products will evolve over time to embrace this architecture. For the present, Talis’ focus has been more on encapsulating legacy systems with integration layers that allow increased interoperability through Web services. The Library Corporation takes different approaches in regards to APIs for each of its products. Library. Solution, given that it focuses on smaller libraries outside the bounds of those that require extensible systems, does not offer APIs directly. TLC points out that the systems are flexible and highly configurable in other ways, but not through this approach. Carl.X, which evolved from an older legacy, serves a larger class of libraries that come with the more advanced automation needs that involve access to APIs. TLC indicated that it has created and made available APIs as projects arise that require them. Carl.X includes a more comprehensive proprietary API, made available only to its customer libraries. The new LS2 platform embodies a design that will be much more amenable to Web services and other APIs. TLC already positions the LS2 PAC, its initial module, as the means to deliver Web services to libraries using either Carl.X or Library.Solution as their ILS. Polaris offers access to its product in several different ways. The most comprehensive level of access is accomplished through open access at the database level. The Polaris API offers its customers an option to work directly

41

Chapter X

Resources

Boss, Richard W. “Sirsi Offers API to Customers.” Library Systems Newsletter 15, no. 11 (Nov. 1995): 1. Breeding, Marshall. “Ex Libris Sets Strategic Course on Open Systems.” Smart Libraries Newsletter 28, no. 8 (Aug. 2008): 1–3.

Library Technology Reports  www.alatechsource.org  November/December 2009

Breeding, Marshall. “Opening Up Library Automation Software.” Computers in Libraries 29, no. 2 (Feb. 2009): 25–28.

42

Breeding, Marshall. “Web Services and the ServiceOriented Architecture.” Library Technology Reports 42, no. 3 (May/June 2006). Digital Library Federation. “ILS Discovery Interfaces.” www.diglib.org/architectures/ilsdi (accessed Sept. 1, 2009).

Sadeh, Tamar. “The Ex Libris Open Platform Strategy.” The Ex Librian Newsletter (July 2008). www .exlibrisgroup.com/?catid={8E2F087A-6266-4E8DB784-FF321DFADE27} (accessed Sept 1, 2009). Sero Consulting Ltd., Glenaffric Ltd., Ken Chad Consulting Ltd., Veronica Adamson, Paul Bacsich, Ken Chad, David Kay, and Jane Plenderleith. “JISC & SCONUL Library Management Systems Study: An Evaluation and Horizon Scan of the Current Library Management Systems and Related Systems Landscape for UK Higher Education.” March 2008, www.jisc.ac.uk/media/documents/programmes/ resourcediscovery/lmsstudy.pdf (accessed Aug. 15, 2009).

Jangle Specification, Nov. 5, 2008. www.jangle.org. Marcin, Susan, and Peter Morris. “OPAC: Placing an Encore Front End onto a SirsiDynix ILS.” Computers in Libraries 28, no. 5 (May 2008): 6–12.

Opening Up Library Systems through Web Services and SOA: Hype, or Reality?  Marshall Breeding

Notes

Library Technology Reports  www.alatechsource.org  November/December 2009

Opening Up Library Systems through Web Services and SOA: Hype, or Reality?  Marshall Breeding

43

Library Technology Reports Respond to Your Library’s Digital Dilemmas Eight times per year, Library Technology Reports (LTR) provides library professionals with insightful elucidation, covering the technology and technological issues the library world grapples with on a daily basis in the information age. Library Technology Reports 2009, Vol. 45 January 45:1 February/ March 45:2 April 45:3

“The State of Funding for Library Technology In Today’s Economy” by Larra Clark and Denise Davis, Office for Research and Statistics, American Library Association, Chicago, IL “Implementing Second Life: Ideas, Challenges, and Innovations” by Joe Sanchez, School of Information, University of Texas, Austin, TX “Open Source Public Workstations in Libraries” by John Houser, Senior Technology Consultant, PALINET, Philadelphia, PA

May/June 45:4

“Collaboration 2.0” by Robin Hastings, Information Technology Manager, Missouri River Regional Library, Jefferson City, Missouri.

July 45:5

“Gaming and Libraries” by Jenny Levine, Internet Development Specialist and Strategy Guide, American Library Association, Chicago, IL

August/ September 45:6

“Building the Digital Branch: Guidelines to Transform Your Website.” by David Lee King, Digital Branch & Services Manager at the Topeka & Shawnee County Public Library, Topeka, KS

October 45:7 November/ December 45:8

“Digital Storytelling in Practice” by Kelly Czarnecki, Technology Education Librarian at ImaginOn for the Charlotte Mecklenburg Library, Charlotte, NC “Opening Up Library Systems through Web Services and SOA: Hype, or Reality?” by Marshall Breeding, Director for Innovative Technologies and Research, Vanderbilt University Library, Nashville, TN

www.alatechsource.org ALA TechSource, a unit of the publishing department of the American Library Association

MEET THE NEW! FACE OF ALA TechSource Online Ć
Access a growing archive of more than 8 years of Library Technology Reports (LTR) and Smart Libraries Newsletter (SLN) Ć
Read full issues online (LTR only) or as downloadable PDFs Ć
Learn from industry-leading practitioners Ć
Share unlimited simultaneous access across your institution Ć
Personalize with RSS alerts, saved items, and emailed favorites Ć
Perform full-text searches

Library Technology R

e

p

o

r

t

November/December 2009 vol. 45 / no. 8 ISSN 0024-2586

s

Expert Guides to Library Systems and Services

www.alatechsource.org

a publishing unit of the American Library Association

FREE SAMPLES @ alatechsource.metapress.com

LIBRARY TECHNOLOGY UNCOVERED, EXPLORED, ONLINE

Subscribe to TechSource Online today! alatechsource.metapress.com

Your support helps fund advocacy, awareness, and accreditation programs for library professionals worldwide.

ISBN 978-0-8389-5806-3

9 780838 958063

Opening Up Library Systems through Web Services and SOA: Hype, or Reality? by Marshall Breeding