The Sakai framework
With the ever-increasing pace of technological change, it is hard to predict the winners and losers in the marketplace. For instance, the builders and engineers of the so-called Web 2.0 social online explosion based their web-based applications on AJAX (Asynchronous JavaScript and XML) technology. This power lay dormant for years, hidden in the vague details of JavaScript and ActiveX components. The change was rapid and learning professions are only now fully coming to terms with the implications in terms of interactive, responsive, and socially-aware ecosystems.
An application builder, to save further work when the technology changes, needs to decouple the graphical user experience from the underlying services, the business model, and the data. That way sites can be archived, whether they are the course, project, or resource sites, but the same data reused no matter what the evolutionary pressures and workflow changes are.
Today, most users still interact with online materials via a desktop computer. However, mobile phones, portable game consoles, PDAs, and so on are becoming more powerful. They have the CPU cycles of a common desktop of less than 10 years ago; their screens are getting larger, and they are increasingly touch- and voice-aware. With campus-wide wireless connectivity and a few creative thoughts, you can imagine yet another rapid change to come. Perhaps your institution uses portals such as uPortal (http://uportal.org) and you want to aggregate a campus-wide view, taking data directly from. Sakai's underlying services. How does the Sakai framework support change?
The framework needs to be flexible enough to plug and play into different aggregations of views. It needs to support different development groups working within the system at the same time. It should be as simple to deploy as possible, using standard technologies that make it easier to find support, administration, and development personnel.
There is a difference between framework and architecture. Here's how Mark J. Norton, Senior Technical Consultant of the Sakai Project, explained it in his "Overview of Sakai Technology" for an audience at the University of British Columbia: the architecture is the abstract design upon which the framework is based. The following screenshot explains the architectural division of labor from within Sakai. The framework actualizes the architectural concept.
The aggregation layer
Users interact with sites. A site contains pages and tools. To build a view of the whole site you require the aggregation of fragments of pages and tools. To change the overall look and workflow of your site, you plug your own custom code into the aggregation layer.
Sakai has a couple of different aggregators. The default (and the one you interact with the most) is the portal aggregator, which is designed to be viewed with a desktop web browser. The screenshot shown next is the PDA view as found under /portal/pda, which is designed for low-fidelity mobile browsers. When a user loads a page within Sakai, Sakai determines which browser (user agent) they're using and chooses the most appropriate aggregator to render the content. Sakai did not originally include a PDA portal, so this is a good example of how the framework makes it possible to respond to a changing computing environment.
Note
Currently, there is a great effort going into the creation of other aggregators for support of desktop tools and widgets, and for mobile devices.
Sakai is an international player with extra functional pressures to reconcile. For example, South Africa's North West University (http://nwu.ac.za/) and the University of South Africa (http://unisa.ac.za/) have Internet bandwidth issues. The price is high and connectivity is spotty at times. To alleviate these problems, the universities have designed an offline viewer for Sakai content. The viewer and project are named SOLO (http://bugs.sakaiproject.org/confluence/display/SOLO/Learning+offline+with+SOLO). SOLO hooks into the low bandwidth PDA view just mentioned. The tool makes Announcements, Resources, and Lessons supplied by the Melete tool (http://www.etudes.org) available to learners. SOLO replaces the standard web interface with a rich interface similar to those found in Windows and the Macintosh OS, which are more familiar to users, and eliminates browser refreshes, thus lowering bandwidth demand and costs for the learner.
Note
SOLO is described in more detail in Chapter 13,Show Cases.
The presentation layer
Underneath the aggregation layer is the presentation layer. There, Sakai employs number of widget sets that tools can use to generate their final rendered output. The widget sets help, enforce a consistent look and feel, and play well with accessibility and internationalization. The current technologies used within the presentation layer are JSF, JSP, Velocity, RSF, Apache Wicket, and Struts.
The use of standard widgets lowers costs, accelerates development life cycles, and makes the creation of good-looking applications that much easier.
The tools layer
Tools are units of discrete functionality — such as a poll, a wiki, or a content search tool. Each tool contributes to the overall usefulness of Sakai for the end user - and for developers, who build large areas of functionality (such as the portfolio system) on top of a series of smaller tools.
Tools manipulate their information via common services such as getting or modifying users or courses, and so on. Furthermore, the Sakai framework is highly extendable. Kernel functionality enables new services and tools to be registered. While building tools, developers can add their own services, such as those currently within Sakai that allow developers to retrieve, add, modify, and delete the grade book entries. Once a service like this exists, other tools can build new services that work with the same data and underlying code. One example would be a new print tool, adding the option to print a grade book in different formats.
The services layer
Services simplify development by abstracting implementation details. The tool does not need to know which database type the service is using, where the service is, or what the file system is doing. As long as the service implementation uses a standard API, you can plug and play with different implementations and versions. The framework includes lots of commonly-used services, such as the ability to get and add users or courses, upon which compound services that are more complex can be built.
As tools move from provisional to core, the number of services increases and so does the potential richness of development choices. This increasing set of service options is a heavy foot on the accelerator of functional improvement.
Only the programmers see the service layer directly and therefore this layer will not be mentioned further in this book other than briefly in Chapter 10, Web Services: Connecting to the Enterprise. The best location to find further information is the programmer's café (http://confluence.sakaiproject.org//x/XICrAg).