Core technologies

You can define Sakai roughly as a series of web applications running in a servlet container with some shared central services. A servlet is a Java object that gets a request from the servlet container — the Tomcat server in this case — and sends a response. The web browser makes a request; an application receives the request, does some work, and then generates a response (normally a web page) that the end user gets to see. Of course, the exact details are more complex; in the case of Sakai, the web browser request goes to an aggregator that dispatches many requests to specific tools, which in turn use services and generate responses. The aggregator then collects the responses to make one view for the end user.

Luckily for Java developers, the architects based the Sakai framework on standard technologies. That was smart: it's easy to find employable developers because the technology is well-known. Just as importantly, at a technical level the servlet container isolates each tool from the others, and the use of services decouples the underlying data from the presentation layer. The whole framework is malleable and can be changed by groups — you can tear out one piece and replace it with another while others are working elsewhere.

Each tool has its own separate space for Java libraries; Java developers know this by the term classloader isolation. For example, if one web application wants to parse XML using a particular version of library X, and a second application wants to use library Y, the libraries will not interfere with each other. In practical terms, this implies that development teams can build their code without the fear of side effects from or to others. The exception to the enforcement of isolation is the core Sakai framework that lives within a common classloader space and is visible to all. The Sakai Framework allows developers to use standard libraries for core needs. For example, the database interaction relies heavily on the well-known Hibernate (http://hibernate.org) framework. Hibernate maps objects, such as a course and a user, onto tables in a database; the mappings take place via XML configuration files. Theorists call this method of using mappings the Object Relational Model (ORM). These are the advantages of using Hibernate:

A positive consequence of Hibernate's methodology is that much of the translation from object to database that normally sits hard-coded in the Java application's source, making the code fragile, now sits in text-based XML files, which are human-readable and readily editable. Just as good: the Hibernate community is large, which allows Sakai to take advantage of and contribute to the larger effort to test and improve Hibernate. Sakai takes advantage of new features as the product rapidly evolves and becomes enriched.

Hibernate itself uses the reliable standard Java Database Connectivity (JDBC) framework (http://download.oracle.com/javase/tutorial/jdbc/index.html) to connect to numerous database types. However, Sakai is currently tested and supported only on MySQL, Oracle, and in-memory databases. In theory, an interested third party is welcome to expand the list, but the amount of work associated with testing a new database type is enormous and makes additions to the list unlikely.

Managing Sakai-related services is achieved via the Spring framework (http://springframework.org), another practical industry standard. The developers configure its details through XML.

The final technologies that I shall speedily mention are associated with servlets. The first is a filter: a filter intercepts all incoming requests and/or the responses from a servlet and takes actions on those requests and responses. Filters can sit in a chain with a request or a response passed from one filter to the next. In Sakai, the process of generating the view for the end user is heavily dependent on filters.

The second technology is a listener. It listens for different parts of the life cycle of a servlet. For example, when a servlet initially shuts down, the listener can do some work such as cleaning up some temporary directories or removing database connections that are no longer required. This is handy for injecting services in each tool at startup and for the clean shutdown of the services at the end. Again, the configuration of listeners and filters is XML-based, enabling plug and play through text-editing.

Basically, the architects have based Sakai on complex interactions and configuration, but they have used standard technologies that Java developers would commonly find in the course of their work.

Now, let's take a look at Sakai's physical infrastructure.