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), Xservices, 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 ExLibris 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 (XServices, 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 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).

Today all open interfaces are offered as part of the core product and we do not charge any license fees for them.

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.

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 functionality, including the creation and the modification of data.

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

Xerxes

http://xerxes.calstate.edu

Livetrix

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

Umlaut

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

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.

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 open-platform 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.

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

• (a) Leaves out a wide range of functions (e.g. no “browse”/authority search features, no ability to determine 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.)

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: hold-request 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.

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.

Yes. There are occasional typos, and some undocumented bugs/features for the APIs, but overall ALEPH has a reasonably well-documented set of 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.

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.

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)

Very constrained.

There are no real APIs with current version of the ILS that we are on.

Yes, definitely too closed.

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.

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

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.

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.

All Evergreen APIs are available at no cost out of the box.

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.

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.

Evergreen is constructed as a set of loosely coupled services 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 provides 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.)

Modification of bibliographic records is performed atomically, by updating the record as a whole.

The API provides methods for both aggregate and individual availability information for items, and can be used to perform all transactions involving items.

Evergreen can perform batch imports and updates of user records from an external, authoritative source, but does not directly integrate with such sources for real-time authentication.

Evergreen allows retention of full circulation data, as well as supporting the retention of circulation 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.

While acquisitions functionality is currently under development, Evergreen does currently support interaction with external systems through EDI (EDIFACT) file interchange.

The OpenSRF provides access to all functionality defined in the application.

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 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 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.

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.

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 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.

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.

We use SOAP (Simple Object Access Protocol) and the more “modern” JSON (JavaScript Object Notation) in LS2.

The API is CRUD (create read update destroy).

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

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.)

Available in LS2 via SOAP and JSON.

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.

Personal details are available in LS2 PAC via SOAP and JSON. Authentication credentials materials charged or requested are available in LS2 PAC via SOAP and JSON. Real-time synchronization with external authoritative repositories of user populations in near real time is available with ActiveDirectory.

No, only via reporting.

No.

No.

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.

API sets are optional functions within Millennium. Depending 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.

Technical documentation is available to customers and third-party developers. Techdocs, Innovative's Technical Documentation site, provides information to libraries that 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.

All of Innovative's modern APIs operate through SOAP, and utilize Perl and JavaScript. Legacy APIs use http://mechanisms.

See specific API descriptions provided below.

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.)

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

• Patron API (URL, read-only). Delivers patron information 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. Innovative 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 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 Web-enabled 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.
• 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 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.
• Millennium Enterprise Backup API (read-only). 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.
• 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.
• 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 self-validate 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 product 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.
• SUSHI. Millennium Electronic Resource Management includes a configurable Web service, which connects to specified vendors on a library-determined 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.

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 front-end application interface for data collection and dissemination, or whatever practical applications you envision. Cataloging data (e.g., bibliographic, 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 Serverwill allow approved third-party client applications, 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.
• 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.

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.¹²

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.

Information on Item Status API

http://brewing.iii.com/2008/09/10/item-status-api-now-working-with-3m-and-envisionware-rfid-systems

Patron Update Web service article

www.iii.com/news/it/it_2009_03.pdf

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.

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

Access is included with the base product.

The documentation is available to anyone.

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.

It operates through REST Web services.

Data can be created and modified using 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.

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

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.)

Yes.

Yes.

Yes.

Yes.

Yes, in theory, though there are no live examples.

Yes.

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.

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.

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

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.

The API uses standard database communication mechanisms, 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 protects 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.

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

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.)

Polaris provides the capability for complete and flexible extraction of bibliographic content through the Simply Reports Export Express product, not through the API.

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

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.

Yes. The API does perform these types of transactions.

This can be accomplished without the API. Polaris has a utility that interfaces with Civic Technologies.

This can be accomplished without the API by querying the database through the use of Simply Reports or SQL Reporting Services.

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.

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

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.

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.

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 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.

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 circulation 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

All APIs and Web services are automatically installed 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.

Yes, we publish hundreds and hundreds of pages of technical documentation and descriptions for our APIs and Web services.

Both. Our Symphony API is a proprietary protocol utilizing TCP/IP sockets and formatted strings for all of the commands, parameters, and return values. Our Web services are implemented with both SOAP and REST.

All APIs and Web services can modify data and also re-trieve read-only data.

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 specific activities that libraries may want to accomplish, but there may be others that you support that you may want to mention.)

Yes.

Yes.

Yes.

Yes.

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.

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.

We've had numerous customers utilize our APIs to write client applications and also use scripting tools to automate their various unique business practices.

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.

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.

“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, integration 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.”¹⁶

“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.”¹⁷

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.

“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.”¹⁸

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.

“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.”¹⁹

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.²⁰

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.²¹
• A similar project took place at the University of Wolverhampton which “chose to link directly 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.”²²
• 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.²³

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.

Database views are free. APIs are licensed to customers that license the primary product (Virtua or VITAL).

Yes, APIs are documented, but available only to customers with an active license.

SOAP is supported in VITAL only. (Note from VTLS: VITAL is VTLS's institutional repository product based on Fedora.)

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.

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.)

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.)

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

Yes—see above.

There are two API calls here:

• Authenticate a patron via ID and password
• Retrieve all patron details, including contact information, checkouts, requests, and fines.

This is part of the previous API. There are no APIs for this data except the patron-related ones.

Yes, but only available through Edifact.

No, not supported.

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