This document makes use of the "Ituri Platform" name to describe the general components developed for the FOLIO project that are of general purpose interest. This name is a placeholder while these components are spun off from FOLIO as a distinct project under the Open Library Foundation.
The Ituri Rainforest is a rainforest located in the Ituri Province of northeastern Democratic Republic of the Congo formerly called Zaire (Wikipedia). About one-fifth of the rainforest is made up of the Okapi Wildlife Reserve, a World Heritage Site. "Okapi" is the project name for the back-end microservices API gateway, which itself is fondly known as an "okay API".
Ituri Platform Description
The Ituri Platform – consisting of Okapi, Stripes, and related components – was initially developed to be the infrastructure for the FOLIO LSP project. It is seen now as a generally useful infrastructure component for other projects, and the Open Library Foundation (OLF) is in the process of separating the Platform into a distinct OLF community project (which is provisionally called the "Ituri Platform"). The most well-known project to use the Ituri Platform is the “FOLIO Library Services Platform (LSP)” suite of apps intended to replace the functionality of an integrated library system. The Ituri Platform, however, is problem-domain agnostic: it enables developers to build software solutions that solve many problems in the library space. (In fact, it would facilitate solutions even outside the library domain.) For instance, the recently announced Project ReShare uses the Ituri Platform.
The Ituri Platform (or simply "Ituri") is a true multi-tenant application environment for web-based applications (or "apps"). The concept is similar to Google’s office suite and other web-hosted, extensible environments. A tenant is like a workspace in the Ituri Platform, which is typically specific to a library or organization. It has its own set of apps, its own users, and its own data. Multiple tenants, each using a variety of apps, run on a single installed instance of the Ituri Platform. Apps are deployed independently for each tenant, so libraries can adapt an Ituri-based solution to their needs by selecting which apps to use.
One of Ituri's critical design decisions is the division of functionality into Apps. Apps correspond roughly to business objects in the supported domain. For instance, one would have an app for Invoices, another app for Vendors, and yet a third app for Payments. Each app is responsible for the business logic and data storage for its type of data, and other apps communicate through well-defined, versioned application programming interfaces (APIs). Between tenants, apps also communicate through these same APIs. To have an app that reads data directly from another app or another tenant violates a fundamental separation of concerns built into Ituri.
Ituri establishes a basic software architecture and delivers foundational services that any application set would require. These services are general, utilitarian, and domain agnostic. More specifically, they do not assume, enable or support specific workflows within any domain. They are building blocks. In some ways, the analogy of an Operating System is appropriate for the Ituri platform. In and of themselves, the platform pieces are of little functional value. The domain-specific apps are required before organizations see the benefit of adopting Ituri. Once Ituri is adopted, though, the incremental costs of creating or adding new apps are significantly reduced.
Ituri Platform Components
The platform has three general pieces:
Runtime components and frameworks
The Ituri Platform back-end consists of a microservices architecture called Okapi. Okapi is an implementation of the microservices API Gateway pattern. Modules are written to the Okapi specification to perform the business logic and data storage activities of an app. The Okapi specifications insulate module implementers from needing to understand operational details of service discovery, load balancing, reporting, and tenant-separation. To aid in the creation and maintenance of Okapi modules, developers can use a framework called RAML Module Builder (RMB). Geared towards Java developers, RMB provides facilities for building JSON APIs and seamlessly storing JSON objects in a Postgres database as well as providing stub interfaces for the required Okapi lifecycle management functions.
It is possible for software applications to use other front-end development toolkits other than Stripes to communicate with Okapi modules. For instance, a library discovery layer tool may communicate directly with Okapi modules to look up items the patron has checked out. Most apps on the Ituri platform are expected to use the Stripes toolkit to provide a consistent user experience to app users.
Fundamental application building blocks
Regardless of the problem domain, every system requires users, permissions, authentication, configuration, and secure inter-communication mechanisms. Ituri provides this functionality through domain-agnostic modules:
mod-users: management of details of users in the system
mod-permissions: permission-checking functionality that determines if a requested operation is allowed by the user
mod-authtoken: session management
mod-configuration: configuration management
On the roadmap for development is workflow functionality that will be available to app developers for managing to-do lists and orchestrating machine operations.
Software Development Lifecycle Practices and Utilities
The Ituri Platform uses modern software development lifecycle practices such as a continuous-integration/continuous-delivery pipeline, automated test suites, standards around tooling, code coverage expectations, deployment patterns and established environments that allow development teams to integrate new code and functionality. Those practices are provided in the form of infrastructure management code (folio-infrastructure, folio-ansible, folio-install) and documentation.
Likewise, there are command line tools that are designed to allow system operators and developers to leverage the platform capabilities in a quick, convenient and automatable fashion. Those tools are the Okapi-CLI and Stripes-CLI.
FOLIO Library Services Platform (LSP)
This document is provided to help the community with terminology and concepts that can help define the different aspects of FOLIO and the software systems that are part of it. We expect that future projects will be modeled after FOLIO LSP and share the Ituri Platform, but will have separate domain "Base" modules and "Extended" apps.
FOLIO LSP Base
To provide library-specific functionality on the level of contemporary Library Services Platform, FOLIO project is actively developing a set of backend modules and staff user applications that will eventually form a consistent solution to everyday tasks of running a library. Those modules are designed to run on the Ituri Platform and are built both by the FOLIO Core Team and External Teams that closely follow FOLIO style and design guidelines. Those modules are fully replaceable and selectable, however, due to interdependencies between them it may be required to select full subsets of those apps to provide required functionality. We use the term FOLIO LSP Base to denote them. LSP stands for Library Services Platform.
FOLIO LSP Base includes, but is not limited to the following:
User Management, Inventory and Circulation suite of modules:
Acquisitions suite of modules: (non-exhaustive):
ERM’s suite of modules
FOLIO LSP Extended Apps
FOLIO LSP Extended Apps are library-domain specific modules and apps that are provided by FOLIO partners. The key characteristic of “Extended Apps” is that their use is ancillary and optional in terms of running a library. Clearly they can be useful, but they are not essential. It’s generally encouraged that all FOLIO apps follow the common set of usability and look/feel guidelines, although this is not a requirement for extended apps. Note that there are no functional dependencies between FOLIO LSP Base apps and Extended Apps, as they operate side-by-side. FOLIO LSP Extended Apps are fully replaceable and selectable.
Examples of potential FOLIO LSP Extended Apps:
- Collection analysis tools
- Reporting tools for tracking physical conservation and digital preservation activities
- Integration with learning management systems
- Curatorial value assessment records and associated documentation
- Records of movement of items within an organization (typically used for museum collections)
Implications of Platform vs LSP Base vs Extended Apps
The distinction between these categories implies a certain level of “centralness” and with that comes added governance. The table below begins to outline the current thinking. Note that the table below is meant to convey directional intent. We currently do not have policies or guidelines that dictate this governance.
Coordinated by Product Council
Approved by Tech Council
Approved by Tech Council
Adherence to Definition-of-Done
Manage Pull Request