Rosetta Application Roles
Rosetta Application Roles
Each server used by Rosetta can be assigned to one or more application roles. Each application role is in charge of different activities. For example, all Deposit activities—acquiring the deposited files, converting the input data to METS structure—are performed by servers whose APP_ROLE = DEP (Application Role is set to Deposit). If more than one server is assigned to the same application role, a load balancer is required to balance the load between the servers.
This section describes the following Rosetta application roles:
Deposit Role
The Deposit role acquires the deposited material and stores this content in the Deposit Storage.
The Deposit role interacts with the following components, as illustrated in the figure below:
Deposit Application Role Architecture
Patron Directory Service (PDS)
Users can register using either an external legacy application or the Rosetta system. The PDS enables the authentication and login of users regardless of the registration method. For example, the PDS can be configured to work with an external user database, such as an LDAP directory service.
The PDS is configured by a System Administrator.
Database Schemas
The Deposit application role uses the following database schemas:
- SHR, which contains configuration information required for processing Producer Agent content (such as material flow and Producer profile configuration).
- DEP, which stores information about deposit activities that a Producer Agent submitted
Deposit Storage
The Deposit storage area contains
- deposit activities, which are deposited by Producer Agents, and
- submission information packages (SIPs), which are generated by the Rosetta system.
For each deposit activity, the Rosetta system creates a Deposit folder. To differentiate between Deposit directories that store different deposit activities, the Rosetta system adds an automatically generated ID to the name of each Deposit directory.
The figure below illustrates the organization of a Deposit directory.
Deposit Directory Organization
Repository Application Role
The repository application role (sometimes known as the staging area) manages all activities associated with SIPs (validation stack, enrichment, 3A/TA, Web editor) and IEs (processes, publishing, Web editor).
The repository application role interacts with the following components, as illustrated in the figure below:
Staging Repository Application Role Architecture
Database Schemas
The repository application role uses the following database schemas:
- SHR, which contains configuration information required for processing SIPs and IEs (such as material flow and Producer profile configuration).
- REP, which stores information about content stored in the Operational Storage, including intellectual entities, metadata, SIP processing configuration, storage rules, and delivery rules.
Deposit Storage
The repository application role interacts with the Deposit Storage in order to move the stream files and METS files to the Operational Storage for further processing.
For more information about the Deposit Storage, see Deposit Storage.
Operational Storage
The Rosetta system stores the stream files, as defined by storage rules. (For more information on storage rules, see the Configuring Storage Rules section in Part III, Configuration Components, of the Rosetta Configuration Guide.)
Information about the physical location of the stream files, along with their identifiers, is stored in the Oracle database. These identifiers are also stored in METS files in order to enable the Rosetta system to establish a relationship between a METS file — which contains metadata about the stream files — and the files themselves.
METS files are grouped into submission information packages (SIPs) and stored as described in Deposit Storage.
Permanent Storage
The repository application role interacts with the Permanent Storage when a content object (such as an intellectual entity, representation, or file) that has already been moved to the Permanent Storage must be edited.
Because no changes can be made in the Permanent Storage, the Rosetta system retrieves the content object from the Permanent Storage and stores this object in the Operational Storage.
After the object is edited, the Rosetta system returns this object to the Permanent Storage.
For more information about the Permanent Storage, see Permanent Storage.
Permanent Application Role Server
The permanent application role server provides permanent storage for content objects (such as IEs, representations, and files) that have been processed and approved.
The permanent application role server interacts with the following components, as illustrated in the figure below:
Permanent Application Role Architecture
Database Schema
The permanent application role server uses the PER database schema to store information about content objects (such as intellectual entities, representations, and files) that are permanently stored in the Rosetta system.
Operational Storage
The permanent application role server interacts with the Operational Storage to retrieve content objects — that have been approved by Staff Members — from the Operational Storage, and move these objects to the Permanent Storage.
For more information about the Operational Storage, see Operational Storage.
Permanent Storage
The Permanent Storage is designed to store intellectual entities (IEs) that were approved by Staff Members for permanent preservation. As a result, content objects that are stored in the Permanent Storage cannot be updated, deleted, or rearranged.
Whenever a content object must be changed (for example, its metadata requires editing), the Rosetta system moves it back to the Operational Storage. When the editing process is complete, the system creates a new METS XML as the new version of the IE and writes it to the Permanent Repository.
The Rosetta system stores files in the Permanent Storage, as defined by storage rules. (For more information on storage rules, see Configuring Storage Rules.)
Information about the physical location of the files, along with their permanent identifiers, is stored in the Oracle database. These permanent identifiers are also stored in METS files in order to enable the Rosetta system to establish a relationship between a METS file — which contains metadata about the permanent files — and the files themselves.
To store METS files, the Rosetta system creates a folder for each IE. The system uses the IE’s permanent identifier as the name of the folder.
Delivery Application Role
The delivery application role is in charge of managing the Delivery requests that come from outside of Rosetta, for example from Primo patrons or the Aleph Web-OPAC.
The delivery application role can reside on the same server as other application roles (such as repository) but it can also reside on a dedicated server that can be accessed by external users.
Delivery interacts with both storages, operational and permanent, in order to deliver the requested metadata and files. It also interacts with the SHR scheme where the delivery rules are managed and the REP scheme where information about the files is stored.
Index Application Role
The index application role manages the SOLR indexing that allows the search of objects in Rosetta. The index application role can reside on the same server as other application roles (such as repository) but it can also reside on dedicated server(s) to allow better search performance. All index (IDX) servers must be accessible to all backoffice (REP) servers.
For more details about the SOLR, see the SOLR section of this guide.