Sakai OAE anatomy
Note
Ray Davis began contributing to Sakai during the development of Sakai 1.5. He is currently employed by the University of California, Berkeley.
Since the initial release of Sakai CLE 1.0, Sakai services and tools have dramatically improved in functionality, stability, and performance. Meanwhile, Sakai's architectural foundations and constraints have remained essentially unchanged. In late 2007, project veterans began reviewing more powerful and more standard approaches to componentization. A few months later, a team based at Cambridge University experimented with a radical redesign of the Sakai 2 user experience to better support social networking and simplify common administrative processes. These threads combined in an ambitious new project whose contributors span the globe: the Sakai Open Application Environment, or Sakai OAE.
Apart from the use of Java, the technical foundations of Sakai OAE represent a sharp break from Sakai CLE 1 and CLE 2. The OAE initially represented a functional break as well, focusing on areas poorly handled by the CLE (such as academic networking and widely shared content) rather than immediately attempting to re-implement the CLE's classroom-centric tools and views. However, the loose coupling and "mash-up" support of the Sakai OAE easily enables functional coexistence with established Sakai CLE installations.
Note
Warning: Sakai OAE is very much a work in progress, and information can change rapidly. To catch up with the latest information I suggest visiting the Sakai wiki at: http://confluence.sakaiproject.org/.
Architectural overview
Sakai CLE 1 and CLE 2 attempted to force pluggability into traditional Java web application packaging, and to force the complexities of the academic community into traditional website structures. The Sakai OAE breaks these conceptual silos into smaller units, following the lead of successful social networking ecologies, which encourage focused service development, loose coupling, and flexible user-facing design.
In contrast to the technology-driven project organization of Sakai CLE 1.0, Sakai OAE requirements come from our user community and our user experience (UX) designers. At the time of writing, the UX team's work was scattered across several sites, with the Sakai 3 Design Confluence page the most central: http://confluence.sakaiproject.org/display/3AK/Sakai+3+Design
At the highest level of code organization, the OAE implements a REST web architecture, splitting between remote services (mostly written in Java) and browser-hosted files (mostly JavaScript, CSS, and HTML). Server code and client code communicate via mutually agreed-upon interfaces, with client calls packaged as normal HTTP GET, POST, PUT, and DELETE requests, and server responses packaged as lightweight and JavaScript-friendly JSON objects.
The best introduction to RESTful interfaces may be the Wikipedia page: http://en.wikipedia.org/wiki/Representational_State_Transfer.
In its initial phases of the project, Sakai OAE's REST architecture was mirrored by a development approach split between two subprojects, each with its own team, its own bug-tracking space, and its own source code repository. The 3akai-ux subproject handled browser-hosted files, while the Nakamura subproject handled services.
Client-side anatomy ("3akai-ux")
Sakai OAE's client-side browser experience is thoroughly AJAX: static HTML, CSS, and JavaScript files are loaded and cached by the browser, and dynamic content is then filled in by the JavaScript requests to the server.
3akai-ux's JavaScript code uses and is highly influenced by the jQuery library (http://jquery.com/) and the Fluid project (http://wiki.fluidproject.org/display/fluid/Infusion+Documentation). Most functionality is displayed within relocatable divisions of the browser display (typically under user control) and implemented by widget directories of JavaScript, HTML, graphics, CSS, and internationalization files. Sakai's widget strategy is inspired by the W3C Widget specification and by OpenSocial Gadgets, but avoids the constraints imposed by those standards.
All browser-hosted files are themselves stored as normal content in the Sakai 3 data repository, and so configurations, customizations, and new widgets can easily be added to a running system.
The client-side subproject currently makes its home at: http://confluence.sakaiproject.org/display/3AK/Sakai+3+UI+Development. The project code is hosted at: https://github.com/sakaiproject/3akai-ux.
Nakamura server-side anatomy ("Nakamura")
The Sakai OAE uses the OSGi standard (http://www.osgi.org/Main/HomePage) as its component framework. OSGi is by far the most established approach to dynamically managed modules, and this choice puts Sakai squarely in the Java mainstream, with easy access to documentation, administrative tools, extensions, pre-built packages, and IDE support.
Virtually all OAE data (including user accounts and a fair amount of application code) is persisted in the reference implementation of the Java Content Repository (JCR) standard, Apache Jackrabbit (http://jackrabbit.apache.org). As it happens, an established open source project has already combined OSGi, Jackrabbit, and a RESTful web architecture: Apache Sling (http://sling.apache.org/site/index.html). Rather than attempting to recreate their work, the Sakai OAE builds on Sling, and OAE developers frequently contribute to the Sling project. (In general, the Sakai OAE strives to take better advantage of established open source communities than what the Sakai CLE did.)
The server-side team maintains extensive documentation at: http://confluence.sakaiproject.org/display/KERNDOC/Nakamura+Documentation, but its mailing list and calendar are maintained at Google Groups (http://groups.google. com/group/sakai-kernel). Project code is hosted at: https://github.com/sakaiproject/nakamura.