Sakai 22 Browser Support

Sakai 22 is designed to work with modern browsers. Recommended browsers (those with the most QA testing effort against them) are Google Chrome, Safari, and Mozilla Firefox. Microsoft Edge should work fine. Sakai should work on most modern tablet and mobile devices. IE 11 is a poor browser choice as it is deprecated, slow, and has not implemented modern features. Newer functionality like Rubrics, may not work with IE 11.

Operating system (OS) choices

Sakai can be installed on most OS's where the Java Virtual Machine is supported.

Linux is the recommended OS because it is where Sakai is most commonly installed and therefore has the most exposure.

Other notable operating systems include macOS, Microsoft Windows.

Notably all of the community's QA servers are running Linux.

Java 11

Sakai 22 is built with Java 11.

This is the first release to be using Java 11 however we are still using Java 8 Language syntax to maintain portability with Sakai 21 which uses Java 8.

While it is possible to run Sakai with different JDK's it is recommended to run with Java 11 the QA servers are using Adoptium's Temurin JDK (formerly AdoptOpen) as this is what was tested by the Sakai QA team.

Java Virtual Machine options have changed vastly from those of Java 8, for example the low pause Concurrent Mark Sweep (CMS) garbage collector is no longer available in Java 11 so choosing a new garbage collector is important. Currently the most logical choice is the Shenandoah garbage collector as it is in the mainline OpenJDK since Java 11.0.9.

Application Server (Servlet Container)

While there are a number of Servlet Containers to choose from Apache Tomcat has been Sakai's long time default container.

Apache Tomcat 9 is the recommended version to use or Sakai 22. (Given that Tomcat 10 supports the JakartaEE spec we don't recommend this version for Sakai 22 as Sakai is still using the JavaEE spec)

HTTP Proxy

It is very common practice to add an http proxy to forward requests from the clients browser to the application server. This allows for a number things like handling SSL, load balancing, request manipulation, logging, and adds support for security measures/practices.

This is probably the one piece of that stack where it is recommended to use the http proxy your most comfortable with, the only requirement is support for sticky sessions.

If your not sure which to use here are some honorable mentions: nginx, Apache httpd, HAProxy

Database

Here is a list of of supported databases

MySQL 5.6 or 5.7
MariaDB 10+
Oracle 12c+

The most popular choice is MySQL and is the recommended.

Clustering, file storage and load balancing strategies

A typical Sakai cluster is comprised of one or more application servers running one or more instances of Tomcat 9 operating either in standalone mode or behind a proxy that can load balance. Each Tomcat instance runs a full copy of Sakai. The cluster is backed by a single database providing a transactional store of information.

Storing binary content outside the database is a configurable option in Sakai and highly recommended from a performance standpoint. Most Sakai schools with sizable user populations opt for network-attached storage (NAS) or storage area network (SAN) solutions.

Authentication

Sakai has it's own local authentication or you can configure it to use external authentication to achieve single sign on.

Sakai can integrate with a variety of external authentication services some of which are:

CAS
Kerberos
LDAP
ADFS
Shibboleth

Integrating with student information systems

Sakai Community institutions have integrated their Sakai installations with Banner, Datatel, and Peoplesoft as well as a variety of home-grown student information systems (SIS).

Sakai has two basic approaches to integrating data from external systems. Most sites use a combination of these approaches. The first approach is to use the internal Sakai "provider" APIs. These APIs are places for Sakai to "consult" while Sakai is running. There are APIs for User Identity, User Directory, Course Listing, and User Roles.

User Identity API allows Sakai to call local code to validate users during authentication
User Directory API allows user information such as name and e-Mail address to be retrieved from an external system such as LDAP or X.509. The User Directory API has provisions to allow the local site to make decisions when to display student information in order to meet FERPA requirements
Course Listing API consulted when the instructor is creating a course site - this API returns the list of externally stored rosters for which the current user is the instructor. The user can select from one or more of these external rosters to associate with the course they are creating
User Role API is consulted during authentication to determine which external rosters the user is a member of and what their role is within those rosters

The above API's are "pull" APIs--they are consulted when the user logs in or tries to take some action. The Course List API described above does not auto-populate courses.

If there is a desire to "push" information into Sakai, there are two approaches - Quartz and web services.

Sakai utilizes an internal batch system called Quartz that provides a cron-like capability within Sakai. Quartz is used by creating a Java class that does the necessary work and then having Quartz schedule the regular execution of that Java code.

A more common approach to pushing data (e.g. enrollment and course information) into Sakai is through web services. Many of Sakai's APIs can be accessed by web services. Web service access points have been developed for many of the common Sakai APIs used for configuration. The Sakai web service data structures are kept simple to insure the widest possible interoperability. Administrators often build scripts to pull data from their SIS system and populate Sakai with that data.

This combination of pull/push configuration capabilities allows for a very wide range of integration possibilities for Sakai.

Browser not supported