ebook img

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

46 Pages·2010·2.019 MB·English
Save to my drive
Quick download
Download
Most books are stored in the elastic cloud where traffic is expensive. For this reason, we have a limit on daily download.

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

November/December 2009 vol. 45 / no. 8 MEET THE W ! FACE OF Library Technology NE IssN 0024-2586 ALA TechSource Online R e p o R T s expert Guides to Library systems and services www.alatechsource.org a publishing unit of the (cid:262)(cid:1) Access a growing American Library Association archive of more than 8 years of Library Technology Reports (LTR) and Smart Libraries Newsletter (SLN) (cid:262)(cid:1) Read full issues online (LTR only) or as downloadable PDFs (cid:262)(cid:1) Learn from industry-leading practitioners (cid:262)(cid:1) Share unlimited simultaneous FREE SAMPLES @ alatechsource.metapress.com access across your institution (cid:262)(cid:1) Personalize with RSS alerts, saved items, and emailed favorites (cid:262)(cid:1) Perform full-text searches LIBRARY TECHNOLOGY UNCOVERED, EXPLORED, ONLINE Subscribe to TechSource Online today! alatechsource.metapress.com Opening Up Library Your support helps fund advocacy, awareness, and accreditation programs for library professionals worldwide. Systems through Web Services and SOA: Hype, or Reality? by Marshall Breeding ISBN 978-0-8389-5806-3 9 780838 958063 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 Marshall Breeding serves as the Director for Innovative Technology R e p oR Ts and Research at the Vanderbilt University Libraries in Nashville, Tennessee. He has authored sev- American Library Association eral previous Library Technology 50 East Huron St. Chicago, IL 60611-2795 USA Report issues: “Electronic www.alatechsource.org Se curity Strategies for Libraries,” 800-545-2433, ext. 4299 “Strategies for Measuring and 312-944-6780 312-280-5275 (fax) Implementing E-Use,” “Integrated Library Software: A Guide to Multiuser, Multifunction Systems,” “Wireless Networks in Advertising Representative Libraries,” “Web Services and the Service-Oriented Archit ec- Brian Searles, Ad Sales Manager ture,” and “Open Source Integrated Library Systems.” Breeding ALA Publishing Dept. [email protected] is also a contributing editor to Smart Libraries Newsletter, 312-280-5282 published by ALA TechSource, and has authored the feature 1-800-545-2433, ext. 5282 “Automated Systems Marketplace” for Library Journal for the last six years. His column “Systems Librarian” appears monthly ALA TechSource Editor in Computers in Libraries magazine. A regular on the library Dan Freeman [email protected] conference circuit, Breeding frequently speaks at Computers 312-280-5413 in Libraries, Internet Librarian, and other professional gather- ings throughout the United States and internationally. He is Copy Editor a regular panelist on the LITA Top Technology Trends panel Judith Lauber at the ALA Annual and Midwinter conferences. Breeding cre- ated and maintains the Library Technology Guides Web site at Administrative Assistant www.librarytechnology.org. For more information or to con- Judy Foley [email protected] tact the author, see http://staffweb.library.vanderbilt.edu/ 800-545-2433, ext. 4272 breeding. 312-280-5275 (fax) Production and Design ALA Production Services: Troy D. Linker Abstract and Karen Sheets de Gracia Over the last few years, Web services and the service-ori- ented architecture (SOA) have become dominant themes in Library Technology Reports (ISSN 0024-2586) is published eight times a IT across many industries. Web-based computing, service- year (January, March, April, June, July, September, October, and December) by American Library Association, 50 E. Huron St., Chicago, IL 60611. It is orientation, and cloud computing increasingly displace the managed by ALA TechSource, a unit of the publishing department of ALA. client/server approach favored by libraries in the past. In Periodical postage paid at Chicago, Illinois, and at additional mailing offices. library automation, one major trend involves evolving or POSTMASTER: Send address changes to Library Technology Reports, 50 E. Huron St., Chicago, IL 60611. rebuilding automation systems to adopt this new approach to software. Purveyors of both open source and propri- 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 etary library automation products increasingly emphasize and the American Library Association state that the names are used for the ways in which they embrace openness, support appli- editorial purposes exclusively, to the ultimate benefit of the owners of the trademarks. There is absolutely no intention of infringement on the rights cation programming interfaces (APIs), or implement Web of the trademark owners. 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 wwwwww.a.alalatetecchhssoouurcrcee.o.orgrg For more information about subscriptions and Copyright ©2009 American Library Association individual issues for purchase, call the ALA Customer All Rights Reserved. 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 6 Intended Audience of This Report 6 Why Should Libraries Care about Application Programming Interfaces? 6 Possibilities Abound 7 Basic Concepts 8 API Implementation Models 9 What Is an API? 11 Proprietary APIs 12 APIs and Open Source 12 Standards as Open Interfaces 13 API Security 13 Terms of Service 13 With Power Comes Responsibility and Cost 14 No Universal Expectation for APIs 14 Chapter 2—Vendors and Products 15 CAse sTudies And CusTomeR Responses Ex Libris 15 Duke University Libraries 18 Broome Community College 19 University of Tennessee 20 National Library of Australia 21 Evergreen 21 The Library Corporation 23 Innovative Interfaces 25 Koha 28 Polaris 29 SirsiDynix 31 Talis 34 VTLS 36 Notes 37 Chapter 3 —API Hype and Reality 39 Conclusions 41 Resources 42 Abstract (cont.) libraries increasingly demand the ability to exploit their extent to which their automation products are able to systems using APIs, Web services, or other technolo- interoperate and thrive in this growing realm of Web gies. The demand for openness abounds, particularly in services. This report aims to assess the current slate of libraries that exist in complex environments where many major library automation systems in regard to their abil- different systems need to interact. As libraries develop ity to provide openness through APIs, Web services, and their IT infrastructure, it’s imperative to understand the the adoption of SOA. 3 CChhaapptteerr X1 Introduction Abstract In today’s environment, systems that are perceived as being “closed” have diminished appeal. It sure sounds In recent years, companies involved with both open better to characterize an automation system as “open” source and proprietary integrated library systems (ILSs) and flexible, but what do the terms really mean? We will have made a concerted effort to increase the openness— explore some of the techniques that provide increased that is, the degree of flexibility and interoperability— access to data and internal functionality, focusing espe- that their products offer to librarians and programmers. cially on Web services and other application program- This chapter of “Opening Up Library Systems through ming interfaces. Web Services and SOA: Hype or Reality” explores this Many libraries might say that they do not want a dynamic in the current ILS market. By taking a general “black box” system that restricts users to the functionality L look at what characteristics and functionality librar- ib ians seek in their software and defining key terms, this in the interfaces provided by the vendor, with no access rar to the internals of the system. Yet many libraries need a y chapter sets the stage for an in-depth exploration of the T turnkey system that helps them carry out their work with- ec modern ILS trend towards APIs, Web services, and the h out the need for any local programming or intervention. no service-oriented architecture. We should emphasize that APIs offer additional opportu- log y nities for those that want to do more with their software, R e In the current phase of library automation, we’ve become but do not impose any technical requirements for libraries po r inundated with the language of openness. Open source that choose not to use them. ts integrated library systems (ILSs) have emerged, prom- When it comes to the purveyors of proprietary soft- w w ising to give libraries more control over their software ware, claims of openness are also everywhere. The empha- w than has been possible with proprietary, closed-source sis on openness may have been accelerated by the open .ala products. Companies that produce and provide service for source movement, but it has been a steady theme for many tec h proprietary products have redoubled their efforts to offer years. Press releases and product literature gush with the so u more flexibility, openness, and interoperability through language of openness. The means to this openness are rce Web services and other application programming inter- the adherence to standards and Web services and other .org faces (APIs). A new front has developed in the competi- application programming interfaces. N tion among library automation alternative vendors, who This report aims to take a close look at the major ov e are racing to open up software and allow libraries more ILS products on the market and describe the approach m b access to their data and internal functionality. This new that each offers in delivering open access to its data and er/ emphasis on openness can be a great benefit to librar- functionality. Of particular interest are the APIs that each De c ies to the extent it that it actually offers new capabilities system offers to the libraries using its product. We will em otherwise not available. Still, as implied by the title of describe and evaluate their scope and comprehensiveness be this issue, it’s often difficult to distinguish products that and observe the extent to which each product offers these r 2 0 0 fully embrace openness from those where the claims don’t APIs through Web services, the preferred approach in the 9 quite match reality. current phase of information technologies. 5 Opening Up Library Systems through Web Services and SOA: Hype, or Reality? Marshall Breeding Libraries have varying expectations when it comes Developers and other technical staff may already to what they want from their automation products. Many be familiar with many of the concepts explained in this simply want the system to function as documented, using report, but should find the examinations of how different the interfaces and reports delivered with the system. Some APIs have been implemented in particular products to ILS products target libraries that expect basic functional- be of interest. Systems librarians, Web developers, and ity without the expectation of local programming. The others ready to extend their activities to include program- products in this category serve a vital role in the library ming with the library’s ILS or other key infrastructure automation arena. Libraries expecting to work with their components will learn basic concepts and the realm of systems through local programming should be clear on tasks that can be accomplished using these interfaces. which products offer this capability and which do not. Developers outside the library industry who may be involved with libraries will find important information on the integration capabilities offered by the major library Scope automation products. Librarians and other library workers not directly This report focuses on integrated library systems, the involved with technology will benefit from understanding core business application used to automate the work that the concepts involved since this is an area of technology takes place in libraries and to provide access to their col- that has a direct impact on the information environment lections and services. Libraries make use of many differ- of the library and the information and functionality that ent software components, such as discovery interfaces, supports their work. link resolvers, federated search tools, digital collection The ability to work with library automation soft- management systems, and institutional repository plat- ware through an API benefits some types of libraries forms. Although many of the same questions apply to more than others. Those involved with larger and more other genres of software, those lie outside the scope of complex library organizations will have more opportuni- this report. ties to take advantage of the APIs and other integration We further narrow the scope to the ILS products technologies covered in this report. The key target orga- widely used in the United States by the kinds of libraries nizations include academic libraries of all sizes, large and likely to have an interest in extensible systems. The types medium-sized public libraries, special libraries supporting of libraries in this category would include large research large organizations, and national libraries. These libraries libraries, municipal and large public library systems, generally operate a variety of information systems within and national libraries. The specific systems examined 9 their enterprise networks, with interdependencies that 0 will include those from Ex Libris, Innovative Interfaces, 20 often cannot be realized by out-of-the-box functionality. er SirsiDynix, VTLS, Polaris, and The Library Corporation, The libraries require custom programming to get what mb as well as Koha and Evergreen, which are widely adopted ce open source ILS products. Even though Talis does not they need out of their software. Smaller libraries tend to /De market its ILS in the United States, it has been an active use automation products as delivered by their develop- ber proponent of this approach and warrants inclusion. ers, increasingly as a hosted service, and may have fewer m needs that require programmatically extending the func- e ov tionality. Smaller libraries are also less likely to have the N Intended Audience of This Report technical staff to implement these capabilities. g or e. This report aims to provide useful information to anyone c our involved with automation products in a library context, Why Should Libraries Care s ch especially those involved with defining or implementing about Application Programming e at technology strategies. Library administrators will find al Interfaces? w. information, presented in clear, nontechnical language, w w that will help them understand some of the options to The integrated library system, or ILS, provides the essen- s extend and enhance their automation environment. These tial automation infrastructure for a modern library and t por extensions relate to extracting and manipulating data in represents one of the largest technology-related invest- e R ways that will support management decisions, allowing ments that a modern library makes. Libraries select from y g the library’s computer systems to work together more a variety of major products on the market, including both o ol efficiently and to better connect with the information sys- proprietary and open source flavors. n h c tems of the broader organization. For library administra- Each library brings a unique set of expectations and e T y tors and other nontechnical professionals, this report will requirements to the table as it implements its ILS. Through brar provide information and context to help understand the a careful selection process, the library will identify the Li claims and counterclaims of open source and proprietary system best suited to its fundamental requirements. Yet software proponents. no prepackaged automation system will completely satisfy 6 Opening Up Library Systems through Web Services and SOA: Hype, or Reality? Marshall Breeding all of the nuanced needs of every library. Equipped with an Extensible. An ILS embodies a specific set of fea- API, libraries with their own programmers have the option tures and functions that are needed to automate of creating functionality that fills in the gaps between the the internal operations of a library and provide its system as delivered and their specialized requirements. users with access to its collections and services. Library automation systems increasingly operate The set of features in a given ILS will continue within a broader context of information systems. Espe- to evolve over time in response to the ongoing cially in larger organizations, the ILS needs to communi- enhancement requests that emerge from the cate with a variety of other business applications. libraries that use the software and from the devel- Any ILS comes as a complete package designed to opment agenda of its developers. Many librar- present a broad set of features and functionality through ies have specific automation needs not fulfilled the user interfaces delivered with the system. These user by their ILS. These needs may not be shared by interfaces, whether presented through a Web browser other libraries that use the software, making them or implemented through a graphical Windows, Java, or unlikely candidates for the normal enhancement Macintosh interface, allow human users to interact with process. An extensible system allows the ILS to the software, searching for resources, performing trans- enhance its functionality without the intervention actions, extracting reports, or carrying out other busi- of the programmers that created it. APIs provide ness functions. In selecting a system, a library measures one of the most important vehicles for extending the completeness of that system in terms of what can be an ILS according to the needs of a given library. accomplished through these user interfaces. Vendor independence. The presence of a robust The user interfaces provided with the ILS are the API can help reduce a library’s dependence on the products of the people who develop the system. While organization that created and supports the ILS. some aspects of the user interface can be adjusted by the With a closed system, only the vendor can make configuration options selected by the library, the basic changes to the system to extend its functionality. functional capabilities cannot be altered except by those An API provides a library with the ability to create involved in the development of the software. customized functionality without the intervention While many libraries find the functionality delivered of its developers. This capability enables the library with the ILS to meet their automation needs, others benefit to have more flexibility; it is less hampered by an from the ability to perform tasks beyond that of the deliv- unresponsive vendor and can accomplish tasks ered software. A robust and well-documented set of APIs with its own staff that otherwise might require empower the library to perform tasks with the ILS and the paid custom programming from the vendor. Lib data it manages that go beyond the delivered system. The degree of independence gained by the ra r APIs associated with an integrated library system ability to take advantage of an API isn’t absolute. y T e enable interoperability, make its functionality extensible, The library continues to be dependent on the ch n and empower the library to be more independent of the product’s developers to maintain the product. If o lo organization that created the software: the company goes out of business or withdraws gy R the product, the programming invested may or e Interoperability. For many libraries, a key concern may not be transferable to another ILS. po r lies in their ability to make the ILS communicate ts effectively with other computer systems. The more w w that a library exists within an organization that w makes use of multiple information systems, the Possibilities Abound .ala more that it needs an ILS that can interact with tec To help readers visualize why it’s important for an ILS to h those other systems. In such a context, an ILS so offer an API, some of the tasks that can be accomplished u that cannot interoperate with other systems func- rc e tions as an isolated silo that may not support the might include: .org library’s organizational and business needs. To OPAC replacement or enhancement. One of the N a large degree, interoperability can be achieved ma -jor trends today involves the transition from ov e through adherence to applicable national and traditional online catalogs to new-generation dis- m b international standards. Yet standards do not nec- covery interfaces. These new products often come er/ essarily address every possible aspect of the way from sources other than the developer of the ILS, De c that a library might need its ILS to interact with but thoroughly rely on the ability to extract data em other business or information systems. APIs pick from and communicate in real time with the ILS. be up where standards leave off, allowing libraries to It’s through APIs that it becomes possible for a r 2 0 0 create interoperability that cannot be achieved in third-party discovery interface to work seamlessly 9 other ways. with the ILS. 7 Opening Up Library Systems through Web Services and SOA: Hype, or Reality? Marshall Breeding Many libraries need to enhance their existing These tasks represent only a few of the possibilities. online catalog in ways beyond the standard Equipped with a well-developed API, a library should be configurations that are offered. The display of able to respond to a wide variety of needs that arise involv- book jackets, summaries, or reviews can be layered ing some aspect of information managed within its ILS. onto catalog pages using an API. It’s of increasing interest to embed library content and services in external Web pages and Basic Concepts portals. A flexible set of APIs in the ILS, especially in the form of Web services, will help support This report focuses on techniques for providing librar- these capabilities. ies more open access to their core automation systems. The key approach that we will explore is the application Connectivity with self-check and automated mate- programming interface, or API. In today’s technology rials handling equipment. The ability to take environment, the preferred implementation of an API is advantage of self-service and other external auto- through Web services, which takes advantage of the pro- mation systems may be enhanced through APIs. tocols, structures, and technologies that support the Web. Much of this connectivity is addressed in SIP2 Systems formed entirely out of Web services and that fol- and NCIP protocols, but libraries may also be able low a particular set of organizational principles can be to enable additional efficiencies if they are able to said to follow a service-oriented architecture, or SOA. supplement these protocols through other APIs. One of the most important concepts to understand Single sign-on and authentication services. A key about an API is that it involves computer-to-computer problem that many libraries face involves how interactions. Not to be confused with the user interface their users sign in to their various applications. offered for humans, the applications programming inter- Given the multitude of systems, it’s important to face involves allowing one computer system to interact have some means of consolidating the function with other computer systems. As an application program- that controls how users sign in. It may involve ming interface, it involves programmers. Those libraries configuring the ILS to rely on an external authen- lacking technical staff capable of at least some software tication service, or it may mean the ILS function- programming will not work with the APIs directly. Libraries ing as an authentication service for external appli- without programming staff may benefit indirectly through cation. Either way, the ILS must support the APIs capabilities executed on their behalf by third parties. 9 associated with authentication, such as LDAP, Some systems may have internal APIs designed for 0 20 ActiveDirectory, Kerberos, or Athens. the developers of the system, but these APIs may not be er packaged in a way that makes them accessible to the per- b Financial system integration. Many libraries need m sonnel in the libraries that use the system. The presence e to be able to exchange financial information with c e of APIs within the internal system framework designed D other business systems in their institution. Pro- er/ curement and fund management tasks that take for use by the software engineers that program the appli- b m cation itself may not be palatable platforms that will help e place in the acquisitions module of the ILS often v the personnel in the libraries that use the software cus- o need to be transferred to an enterprise resource N tomize it and maximize its capability. While the use of planning (ERP) program (a genre of software that g internal APIs reflects modern software design, we’re pri- or large organizations use to manage their financial e. marily concerned with APIs designed to be used by the ourc data across different units) or other accounting libraries that implement the software. It’s these customer- s systems for payment. In academic libraries, fees ch facing APIs that directly benefit libraries using the soft- e incurred in the library may need to be transferred at ware, more so than the APIs that are geared more for use al to a bursar’s office for collection through the stu- w. by those involved with developing the application itself. w dent’s institutional account. Some libraries may w A customer-facing API needs to be largely abstract want to offer online payments though through s from the internal workings of the underlying system. It ort their own or though their institution’s site using should offer high-level operations that do not require ep third-party e-commerce products. R detailed knowledge of the internal programming conven- y g Detailed reporting. Although all ILS products come tions within the ILS. The API should be independent of o ol with reporting modules that generally include the any given programming language or operating system. n h c ability to produce customized reports, they may Most importantly, it must come with detailed documen- e T y not have the ability to address all aspects of data tation that provides the library programmer with ade- brar managed within the ILS. Many libraries are able quate information on the requests supported by the API, Li to use an API to extract data in ways not possible the protocols and syntax involved, and the form of the through standard reports. expected response. 8 Opening Up Library Systems through Web Services and SOA: Hype, or Reality? Marshall Breeding API Implementation Models APIs in the form of reusable services. These services imple- ment small units of work that form the building blocks of As we approach the realm of application programming larger applications. The services may be used within the interfaces, let’s think of applications that lack this archi- application at hand or exposed externally. Although any tecture and step our way through progressive levels of new automation system created today would surely be support. Figure 1 illustrates the most closed approach to service-oriented, most applications available in the library programming. This type of application is completely self- arena predate the emergence of this approach and have to enclosed. The software has exclusive access to any of the be retrofitted with service layers or APIs. data involved. Whether the databases used are proprietary The history of library automation is dominated by or based on standard relational database management sys- products that have evolved through many different cycles tems (RDBMS) products, the customer has no access to of software architectures; few systems built from scratch them other than through the interfaces delivered as part with new architectures of the prevailing age have emerged of the software application. All of the functions of the and survived. Equipping these evolved systems with APIs, software likewise cannot be accessed except through the especially in the form of Web services, represents one interfaces delivered with the application for staff access or of the major factors in their forward progression. Those public access, or through a reports module. that fail to adapt to this expectation may find themselves Whether or not an application offers an API has little less competitive as the library automation market moves to do with its completeness of functionality, sophistica- forward. tion, or scalability. While ILS products that target small One of the first steps forward out of the purely propri- libraries tend to be more self-enclosed, some of the legacy etary programming arena was for developers to take a more systems serving larger libraries might also fall into this abstract approach to database access. Early automated sys- category. The point of distinction here involves the nature tems managed data with proprietary methods. They stored, of the application as entirely self-enclosed with no pro- indexed, and retrieved data in the most expedient and effi- grammatic access to its internal data or functionality. cient ways possible, usually involving database functions The extent to which a system offers APIs relates, to created by the developer of the application. Since almost all a certain extent, to its vintage. Products designed more applications involve various aspects of data management, than five years ago may not have originally incorporated the idea of continually creating this layer of functionality APIs in their design. As these products evolved, most have within the application gave way to the use of third-party come to include APIs that expose functionality through a database management systems. The use of a third-party modern programming interface that may depend on inter- database management system allowed applications develop- L ib nal proprietary programming. ers to focus more of their resources on creating higher-level ra r Any major software application developed today functionality and less on reinventing lower-level data-access y T would be programmed in a way that would naturally routines. The transition from database access routines writ- ec h involve APIs. The prevailing preferred approach to soft- ten for specific applications to third-party RDBMS prod- no ware development involves the service-oriented architec- ucts often introduced a higher level of system overhead log y ture (SOA), which fundamentally embraces the concept of requiring more additional memory, disk storage, and pro- R e p cessing power. These RDBMS products offered much more o r Application Based on internal advanced functionality and scalability. ts proprietary programming The use of a third-party RDBMS comes with cost w w implications. Products such as Oracle require a separate w .a software license from the application software. When a la te library implements an ILS that uses a commercial RDBMS c h delivered s product, it must either purchase the level of license o interfaces required or take advantage of existing site license that its urce .o organization may have acquired. The ILS vendor may also rg bundle the RDBMS license into its cost package. N o The use of proprietary databases continues to some v e Core extent in library automation systems. Two of the major m software b e ILS products, Millennium from Innovative Interfaces r/ D and Symphony from SirsiDynix, were initially developed e c data using proprietary databases. In both cases, the company em stores b offers its system with an option to use Oracle or another e major RDBMS. For libraries that do not require Oracle for r 20 0 other reasons, many sites choose to use the proprietary 9 Figure 1 proprietary programming without Api. database. This option avoids additional licensing fees 9 Opening Up Library Systems through Web Services and SOA: Hype, or Reality? Marshall Breeding

See more

The list of books you might like

Most books are stored in the elastic cloud where traffic is expensive. For this reason, we have a limit on daily download.