Sakai is a $6.8M project which implements a model for the purposeful coordinating of work in a large community of teachers and learners. It is based on many of the principles of open source development efforts, but community source efforts rely more explicitly on defined roles, responsibilities, and funded commitments by community members than some open source development models. The project is founded by the University of Michigan, Indiana University, MIT, Stanford, the uPortal Consortium, and the Open Knowledge Initiative (OKI) with the support of the Andrew W. Mellon Foundation and William Hewlett Foundation. The Sakai Educational Partners' Program (SEPP) extends this community source project to other academic institutions around the world as described in Section 3.
The consortium members are joining forces to integrate and synchronize their considerable quantity of educational software into a pre-integrated collection of open source tools. According to the developers, this will yield three big wins for sustainable economics and innovation in higher education:
The stated products of this project will include an Enterprise Services-based Portal, a complete Course Management System with sophisticated assessment tools, a Research Support Collaboration System, a Workflow Engine, and a Technology Portability Profile as a clear standard for writing future tools that can extend this core set of educational applications.
Use of these modular, pre-integrated tools will in principle greatly reduce the implementation costs of one or more similar tools at any institution. The core partners are committing over $2 million per year to launch and support this two year project. The core universities are also committed to implementing these tools at their own institutions starting in Fall 2004 through the duration of the project. The committment of resources and adoption is purposefully set on an aggressive timeline to swiftly integrate and synchronize the educational software at the core institutions. This effort will demonstrate the compelling economics of "software code mobility" for higher education, and it will provide a clear roadmap for others to become part of an open source community.
Sakai 1.0 beta was released to SEPP on June 23. You can now download release candidate RC2 from http://cvs.sakaiproject.org/release/1.0.rc2/.
Technology Portability Profile
The technical barriers can be overcome by distilling the accumulated architectural knowledge and programming experience gained in building systems into a Technology Portability Profile (TPP) that provides four essential elements for code mobility.
The maturing of the OKI OSIDs, recent demonstration of a working tool interoperability framework at U. Michigan, and industry ratification of the JSR-168 portlet specification made the timing perfect for developing the full Technology Portability Profile for higher education. But, while specifications, standards, and profiles are numerous in higher education, it is large adoptions that give a specification momentum to become a universal and wide spread standard. we noted that many of the requirements of the TPP are also appropriate to e-Research.
Sakai Java Technology
The Sakai core depends upon a number of novel technologies which are now described. The risks associated with these technologies are noted.
Sakai (http://www.sakaiproject.org) is basically a software package designed to add collaboration and course management facilities to the uPortal portal framework. The software already provides collaboration tools in the form of chat, discussion and shared file space, and is being extended with further tools designed to add course management functionality. Tools are being added for both test creation and assessment, the unspoken ambition being to create a functional open source competitor to Blackboard.
Look and Feel
Sakai takes the basic portal paradigm of portlets arranged in a tiled formation on screen and adds the ability to group users into 'worksites', seen as tabs across the top of the portal display. Sakai diverges somewhat from the concept of allowing a user to arrange several portlets on screen and then persisting that layout between user sessions. Instead, Sakai displays one portlet at a time and arranges a toolbar of buttons down the left hand side of the display. Whilst on the surface, the fact that you can no longer aggregate you own collection of portlets seems to be a waste of good portlet functionality, we think that having the portlets accessible quickly on a toolbar is a sound design decision as it simplifies usage. The single portlet per tool model only varies with the worksites Home tool. When you first click on a worksite tab, you are taken to the Home tool, which presents you with a synoptical view of the recent activity in the various worksite tools. You can view recent chat messages, postings in the dicussion tool and announcements on one screen.
Sakai currently has a hybrid architecture aimed at allowing the gradual transition from CHEF style tools to Sakai style TPP tools. Like other portal projects Sakai uses the MVC, Model-View-Control, paradigm. Whereas CHEF uses Jetspeed as its portlet layout engine, Sakai uses uPortal. Whereas CHEF used the Apache project's Turbine as its component and persistence framework (Model), the Sakai TPP uses Spring. Whereas CHEF uses Velocity as its display (View), the Sakai TPP uses JSF (Java Server Faces). Whereas CHEF uses Struts as its intermediary (Controller) between the components and the display (View), the Sakai TPP uses JSF. The hybrid architecture arises from the requirement that CHEF tools also need to run alongside the TPP tools, so all the technologies mentioned in this section, bar Turbine, are present in the Sakai RC1 software stack. This hybrid approach enabled the basic CHEF collaboration tools to be brought straight across from CHEF with minimal modifications. This decision allowed the core Sakai team to work on architecture, rather that tool porting in the initial stages of the project. The downside of this is that the Sakai stack is large and more complex than it would be with a single coherent MVC framework in place.
Sakai is currently in a state of flux at release point v1.0 RC2. The chosen architecture for the software is being debated upon and there is a drive to prioritise the establishment of WSRP compliance above the establishment of JSR-168 (pluggable portlets) compliance. The Sakai core team are also working on uncoupling the software from particular portal frameworks and Java application servers (current uPortal and Tomcat respectively). Whilst these developments will ultimately be good for Sakai, the lack of API stability is causing problems with tool authors - a group who are expected to prefer API stability over elegance.
There will be some important differences between the v1.0 (15/9/04) and v2.0 (2Q05) releases.
The primary purpose of the v1.0 release is to run in production at the educational institutions of the core SEPP members and show others the general direction of the software. It will be production quality code which can be used, but it should not be considered the ``final'' Sakai. Within v1.0 the developers have a number of APIs that are only implemented as 'legacy' and all of the major tools are legacy, meaning ``ported from CHEF''.
Between the 1.0 and 2.0 release new Sakai framework capabilities are being developed and new tools built using those capabilities. There will also be a general tightening up of the environment for the development of new tools. By 2.0 the team hope to have a product that is on par with commercial collaborative systems in a number of important areas:
- Well defined and well documented development platform
- Ready-to install in a wide range of configurations out of the box
- Rich feature set
The key is that 1.0 may be lacking in some areas that is important for ease of porting new tools
As an example, 1.0 in production by default required either Oracle or MySQL, although the MySQL specific code does not seem to be as well tested as is the case with Oracle. The reason for this is that the University of Michigan (the main developers of CHEF and Sakai) runs Oracle for all its student systems. The embedding of SQL code directly into the software is commonly regarded as bad practice; if some middleware like Hibernate or iBatis' sqlMaps were used it would be quite easy to port the mappings to various RDBMSs without touching a line of Java. It may well be that an abstraction approach has been tried and performed badly, hence the presence of tuned (RDBMS specific) code, but this is merely speculation. We have shown that we can adapt it to work with PostgreSQL by patching the various files involved, but this should be regarded as an interim measure. This is an example of the current minor 'annoyances' that an organization might encounter getting v1.0 into production.
Institutions choosing to implement v1.0 right now should therefore understand that they will need to have a little more developer talent allocated to Sakai than if they wait for v2.0. There may be something that you have to adjust locally in 1.0 that by 2.0 we will have as a simple option in install.
It is promised that Sakai v2.0 is just as easy to install, configure, and forget as commercial collaborative systems.
There is still currently a dialogue occurring, amongst the members of the SEPP and the core development team, regarding the architecture of Sakai. This dialogue was in part triggered by cross language support concerns raised at the first SEPP conference in Denver, see Section 3. What is now being proposed is a de-emphasising of JSR-168 compliance, with a corresponding emphasis on WSRP support. The reason for this is obvious - WSRP is language agnostic, so if Sakai can aggregate remote software services via the WSRP mechanism, it no longer can be accused of being Java specific. Another big shift in architecture is a proposed effort to uncouple Sakai from uPortal as its layout engine. There is now talk of being able to run Sakai with other portal frameworks like Jetspeed and Liferay. All of these shifts in architecture could be looked upon with concern, but what it highlights is the open nature of the development effort and the influence that the SEPP members now wield as a group. Sakai will work towards being more easily integrated into existing institutional infrastructures, with eased deployment and tool aggregration facilities, and that can only be a good thing. The downside to these changes is that early access tool developers like ourselves are faced with the frustration of a shifting architecture to code to.
The following table shows some existing projects using Sakai:
|in the UK|
|in the USA|
|U. Michigan||WTNG and CTNG tools migrating to Sakai|
|MIT||tools migrating to Sakai|
|Stanford||tools migrating to Sakai|
|Indiana||tools migrating to Sakai|