XRAS Architecture Overview

XRAS was initially designed in 2014 to be a flexible system that the Extreme Science and Engineering Discovery Environment (XSEDE) program could offer as a service to other research infrastructure providers to support their unique allocation process needs. Starting from a common understanding of the core needs of most allocations processes, XRAS built on XSEDE’s prior allocation system, adapted the system to support multiple clients, and turned many of XSEDE’s idiosyncrasies into customization options for its base functionality. The Allocation Services team of the current Advanced Cyberinfrastructure Coordination Ecosystem: Services & Support (ACCESS) program continues to support XRAS operations and development.

The simplest way to think of XRAS is as three core components, each with a user interface and a backend application. The three components are Submit, Review, and Admin, and we refer to their user interfaces as Submit UI, Review UI, and Admin UI. All three components leverage a common underlying database schema, and they present three distinct views into your allocations activities.

The XRAS Submit UI communicates with the Submit backend via a RESTful API, a key technical feature that allows XRAS clients to build and deploy fully custom Submit UIs within their local administrative domains. If you don’t have the time or staff skills to build your own Submit UI, XRAS can provide and host a default interface for your process.

Unlike Submit, the interfaces for Review and Admin are tightly coupled to the backend components. You will be using a distinct instance of the same Review and Admin interfaces used by all other XRAS clients, including the ACCESS Allocations team, and these are the interfaces we describe in this document.

You can further (optionally) integrate XRAS with your local site by leveraging two API capabilities. The Identity Service API connects XRAS with your local user database and lets your users, reviewers, and staff access XRAS with your local user accounts and authentication. If you don’t have local user accounts and authentication, you can also use ACCESS user accounts and authentication or ORCID identifiers and authentication. If your institution has a local accounting system, the Accounting Service API lets XRAS present local usage details within XRAS, based on information from your accounting system, and post allocation award information directly to your local management systems. 

With that high-level introduction to XRAS and its architecture, we can now move on to helping you use XRAS to manage your allocations process.