Page tree
Skip to end of metadata
Go to start of metadata

Application architecture

Bold border with green shade = maintained by CalCentral team

Upper-left = outside applications making use of CalCentral's APIs

Upper-right = applications with lightweight integration (web links)

Bottom-left = integrations with outside services based on APIs 

Bottom-right = back-end direct-access services (databases)

Dashed line = proposed, not yet implemented

Dotted line = existing, soon to be phased out 

Red = SIS Replacement Project work 

CalCentral merges, augments, & personalizes

  • CalCentral DB is mostly restricted to personal preferences & customizations.
  • memcached acts as a storage container for optimized merged cache of multiple data sources.
  • We use & assist development of university-wide shared services.

AJAX + REST + JSON

  • Flexible & rich client-side widgets.
  • New functionality can start in the browser & relocate to the server as needed.

Expose services, sites, & applications

  • Instructure Canvas, Google Apps, & profile applications such as VIVO match most of our original intentions for Sakai OAE.
  • Student services, research services, adviser tools, alternative course sites, & other collaborative applications are easily brought into new or existing widgets.
  • Contemporary applications, services, & techniques allow development to be tailored precisely to campus needs without the overhead of a traditional "enterprise portal" product.

Authentication

  • CalCentral authentication is through CalNet using CAS.
  • User-specific access to APIs of external applications is generally via administrative logins using shared secrets (bCourses, Bearfacts, CFV, CalLink). 
  • In the case of bApps (Google), users grant individualized access to their data via the OAuth2 protocol. This personal token is stored encrypted in the CalCentral Postgres DB. 

Application deployment

For more information, see the CalCentral Ops Page (TEAM ONLY).

Development process

Design and development tasks are bundled into two-week sprints. The results are generally QA-ed the week after the sprint and released to production in the next week.

The release process is documented at the CalCentral Ops Page (TEAM ONLY).

Performance and scalability testing

Our current goal is for the CalCentral web application to support 6000 users on a busy day. To test that, ETS Ops (AKA Darlene) runs a suite of automated tests which simulate 7200 users arriving in a single hour against just 1 node of the 3-node cluster. The results are graphed and analyzed. Problems discovered are quickly fixed, mostly with application server tuning or strategic adjustments in cache usage. However, the CalCentral architecture is designed for easy hardware scaling.

Integrations

For full details see Road Map of CalCentral Data 

Security Reviews

Two intensive, source-code-aware reviews have been conducted by the SAIT security team. Tech Ops also run AppScan tests. The audit reports and resolutions are documented in JIRA issues that are restricted to a security group. All issues have been addressed. We will continue to request new reviews as development proceeds, particularly before deploying new data integrations to production.

  • No labels