Sakai Technical Overview

Aaron Zeckoski (azeckoski@gmail.com)

From original slides by

Chuck Severance and Ian Boston

Creative Commons Attribution-NonCommercial-ShareAlike 2.5 License Sakai Programmer's Café

Sakai Montreal CRIM Workshop

Technical Goals

Sakai Technical Goals

• Enterprise Production-ready• Abstraction boundaries between tools, services,

framework, and presentation• Seamless integration across tools when

appropriate• Component based expandability with class

loader isolation• Data interoperability and ability to expand Sakai

without using Java• Flexibility - Ease of Local Customization

Sakai Enterprise Technologies

• Sakai is aimed at Enterprise Deployments.

• Sakai supports organizations with > 100,000 users in a single installation

• Sakai consists of technologies chosen to be common in Java Enterprise Environments.

Java1.5

Oracle

Apache - SSL, mod_jk, WEBISO, virtual hosting

MySql 4.1

SakaiTomcat 5.5

SpringHibernate

Java Server FacesVelocity (legacy)

RSF

DatabaseServer

IP Sprayer w/Sticky Session

Enterprise ScalabilityHardware or SoftwareUM = NetScaler IU = Software

App servers with identical software loads.UM = 8X Dell PowerEdge 2650, dual 2.4-3.2 GHz CPU, 4 GB RAM

Database ServerUM = SunFire V480, Quad 900 MHz CPU, 20GB RAM, 4 StorEdge 3310 SCSI RAID Arrays w/ 12 73Gb disks (Oracle)

File Server (optional)IU = NetApp

Ap

p S

erv

er

Hot Spare

Hot Spare

Hot S

pare

FileServer(opt)

High Level

• Tools– Cannot do any type of persistence– Responsible for presentation (GUI)

• Services / Components– Must provide documented API– Cannot do any presentation (not aware of HTML at all)– Must access other services through service APIs (not data

models)

• Framework– Provides registration for tools and service– Provides common capabilities– Knows nothing of domain objects

Framework, Tools and Services

Component Based Expansion

• Take an empty Sakai system

– Pick from the tool library

– Include the appropriate services

– Add some local customizations, look feel, language etc

• And you have a production ready system

• Tools and capabilities written by many different groups or individuals

SakaiFramework

ServiceLibrary

Customization

Configuration

Customization

Configuration

ToolLibrary

ToDoPresentation

Persistence

Browser

ToDo ServiceCode

MyMonolithicToDo ListServlet

Browser

Persistence

ServiceInterface(i.e. API)

Service Oriented Architecture

Framework

Application

SAF—Kernel

SAF—Common Services

Other Services

ToDo Tool Code (Java)

ServiceInterface (i.e. API)

ToDo Service

ToDo Tool Layout (JSP)

SAF—Presentation Services

PresentationAbstraction

Browser

Fitting Into the Sakai Framework

<sakai:button_bar><sakai:button_bar><sakai:button_bar_item<sakai:button_bar_itemaction="#{MyTool.processActionDoIt}action="#{MyTool.processActionDoIt}value="#{msgs.sample_one_cmd_go}" />value="#{msgs.sample_one_cmd_go}" /></sakai:button_bar></sakai:button_bar>

<sakai:view_container title="#{msgs.sample_title}">

<sakai:date_input <sakai:date_input value="#{MyTool.date}" />value="#{MyTool.date}" />

<h:inputText <h:inputText value="#{MyTool.userName}" />value="#{MyTool.userName}" />

<sakai:group_box <sakai:group_box title="#{msgs.sample_one_groupbox}">title="#{msgs.sample_one_groupbox}">

<sakai:instruction_message<sakai:instruction_messagevalue="#{msgs.sample_one_instructions}" />value="#{msgs.sample_one_instructions}" />

<sakai:tool_bar> <sakai:tool_bar_item/> </sakai:tool_bar>

JSFSakai Presentation Services

Web Services

Framework

Application

ToDo Code

ToDo Layout

Presentation FrameworkWS Client

Axis

WS End Point

Web Svcs

Other Tools

Layout

PresentationAbstraction

SAF—Kernel

SAF—Common Services

Other Services ToDo Service

ServiceInterface (i.e. API)

Clear Abstraction Boundaries

Aggregator

Presentation

Tools

Services

Client

SystemT

he A

bstr

act

Sak

ai E

nviro

nmen

t• Sakai breaks its scope into distinct areas and builds strong abstractions between layers

• Goal is to be able to insert and remove implementations at any level without anyone noticing

Abstract Architecture

Aggregator / Portal

• It assembles tools, buttons, tabs, etc and produces the final user interface

• The aggregator can completely transform the interface as it sees fit

• Receives and dispatches requests to tools after setting things like “context”

Aggregator

Presentation

Tools

Services

Apple Portal

VB Portal

Plex PLE

• Cleaned up OSP Portal

• Hierarchy Portals - Astro & Orcus

• Rumors and notions– Acetylene - Rumored RSF based portal– Iframe-free portal– PDA Aggregator– Better Desktop Portal

Aggregator

Presentation

Tools

Services

Upcoming Aggregators

• True abstraction between Presentation and Tools• Tools should not be aware that they are in a web browser

environment• GUI Widget reusability• Able to produce markup for multiple types of aggregators

(Sakai, JSR-168, WSRP)• Support multiple types of ultimate display devices (Browser,

PDA, etc)• Support internationalization and localization• Be as flexible as possible - support CSS and allow

transformability of the user interface,potentially under control of the end user

Aggregator

Presentation

Tools

Services

Presentation Layer Goals

• RSF– Becoming the recommended solution– Emerging and still waiting for proof in all areas

• JSF– Previously/Currently recommended solution – setter/getter pattern and support for reusable GUI

components– Very challenging to work with and not flexible enough

• JSP– Ease of use, considered dated, only used in 1-2 tools

• Velocity– Legacy tools written in this– Simple, but abstraction is weak on the request-side

• Struts– Legacy

Aggregator

Presentation

Tools

Services

Presentation Layer Goals

<sakai:view_container title="#{msgs.sample_title}">

<sakai:tool_bar> <sakai:tool_bar_item/> </sakai:tool_bar>

<sakai:instruction_messagevalue="#{msgs.sample_one_instructions}" />

<sakai:group_box title="#{msgs.sample_one_groupbox}">

<h:inputText value="#{MyTool.userName}" />

<sakai:date_input value="#{MyTool.date}" />

<sakai:button_bar><sakai:button_bar_itemaction="#{MyTool.processActionDoIt}value="#{msgs.sample_one_cmd_go}" /></sakai:button_bar>

JSF Patterns

MyTool.processActionDoIt() {}

Aggregator

Presentation

Tools

Services

Tools and Services

• Tools– Written in Java and orchestrate the user interface– Have no persistence– Preferred pattern is Java object with getters and setters

• Services– Persistence– Business Objects– Business Logic

• Tools interact with services through published APIs • Tools find the implementations of APIs at runtime

using Spring and/or the ComponentManager

Aggregator

Presentation

Tools

Services

tomcat/webapps/portaltomcat/webapps/mercurytomcat/webapps/osp-portal

Aggregator

Presentation

Tools

Services

tomcat/webapp/sakai-user-tooltomcat/webapp/sakai-message-tool

tomcat/shared/lib/site-api.jartomcat/shared/lib/user-api.jar

tomcat/components/sakai-authz-packtomcat/components/sakai-user-pack

Finding Abstraction in your Tomcat

Seamless Tool Integration

Many levels of Integration

• Want your website under a button in Sakai?• Want your PHP app to know the current logged in

Sakai User?• Want build a self-contained that “cooperates” with

Sakai?• Full blown Sakai tool - released separately?• An optional part of the Sakai release?• A seamlessly integrated core part of the Sakai

release?Integration with the rest of Sakai is just another aspect of any tool’s design. Tool writers choose how deeply their tool is to be integrated into Sakai. The community will likely value more highly integrated tools more.

Sakai Architecture Goals

• Two seemingly conflicting goals– Seamless integration across tools– Ability to expand Sakai without using Java

• In the short term, writing tools in Java and using Sakai framework elements directly is the path to seamless integration

• But in the long term, we must make 3P tools full peers in Sakai.

Resources Presentation

Samigo

Melete

Anouncements

Reuse in 2.1

Resources Presentation

Samigo

Melete

Anouncements

Reuse in 2.2

OSPortfolio

Resources Presentation

Samigo

Melete

Anouncements

BetterReuse

OSPortfolio

Resources Presentation

Samigo

Melete

Anouncements

Flexibility in reuse

ScormAuthoring

OSPortfolio

Resources Presentation

Samigo

MeleteLanguageModule

Anouncements

We are building a general way to do

this….

ScormAuthoring

OSPortfolio

HT

ML

HT

ML

Sakai Entity APIs

ExistingSakaiTools

Legend Existing Sakai 2.2 Work

WebDav

Web

Sakai SOA APIs

HT

ML

HT

ML

ExistingSakaiTools

Access

perl

php

python

.NET

Sakai ServicesSearchService

plone

joomla

External

Sakai Entity APIs

Import and Export

SOAP

Sakai Search

Building Tools

• To meet the goals of Sakai it is not sufficient to simply build a stovepipe tool

• While much of what is described here is “optional”, the more “integrated” a tool intends to be, the more “required” these elements become

Provisional Tools

• Should we include a tool in this release?– We needed something between “yes” and “no”

• Need to deeply involve the production users in the evaluation and testing of any new tool.

• Three stages– Contrib - Available - caveat emptor– Provisional - In the release, hidden, QA by developer team– Released - Full peer in terms of QA, etc.

• Increasing criteria as tools progress to encourage tools to meet Sakai’s tool architecture

Provisional Tool Criteria

• Community Support– Must have commit list and be in SVN– Must run in production at >=2 sites– Must have proper license– Must be willing to answer questions– Needs to be tracked in JIRA

Tool Criteria (cont)

• Technical– Support HSQL, MySql, Oracle– Use AutoDDL properly– Use sakai.properties– Do AUTHZ functions like the rest of Sakai– No patches to other elements– Must cluster– Use proper versions of Spring, Hibernate, etc.

Tool Criteria (cont.)

• Interaction and Visual Design– Inherit skins properly– Look “like” the rest of Sakai tools (fit in)– Follow interaction designs in style guide– Use JSF UI Components (if applicable)– Include help - properly added to the Sakai

Help system

• QA test plans and specifications

Tool Criteria

• Desirable elements– Internationalized– Accessible (including a review)– Separation of persistence and business logic into

a properly factored Sakai Component – Event generation as appropriate

• These are strongly suggested for full inclusion

Announce Melete Jforum Rwiki Profile

AutoDDL Yes Yes Yes Yes Yes

Properties Yes Yes No Yes Yes

MySql Yes Yes Yes Yes Yes

Oracle Yes Yes No ** Yes Yes

Skinnable Yes Yes No Yes Yes

Cluster Yes ?? Yes Yes Yes

Resource Yes No No Yes No

I18N Yes Yes Yes Yes Yes

Events Yes No No Yes No

*Sample* Attribute Matrix

Ease of Expansion Including non-Java Tools

• Two seemingly conflicting goals– Seamless integration across tools– Ability to expand Sakai without using Java

• In the short term, writing tools in Java and using Sakai framework elements directly is the path to seamless integration

• But in the long term, we must make 3P tools full peers in Sakai.

Sakai Architecture Goals

Web Services

• Web Services allow flexible reuse of API and services in contexts beyond the Sakai interfaces– WSRP presentation– SOAP - RPC

• Web Services Issues– Security– Performance– API needs to tend towards document-style rather

than RPC-style

Web Services

Framework

Application

ToDo Code

ToDo Layout

Presentation FrameworkWS Client

Axis

WS End Point

Web Svcs

Other Tools

Layout

PresentationAbstraction

SAF—Kernel

SAF—Common Services

Other Services ToDo Service

ServiceInterface (i.e. API)

IMS Tool Interoperability

• Focus is on making tools portable between systems (Sakai, WebCT, and Blackboard)

• Established to further the discussion with commercial and other CMS/CLE providers

• Uses web services and IFRAMES• Roughly based on WebCT PowerLinks• Does not require tools to be written in Java• Currently in contrib space in Sakai

JVM

Sak

ai

Sakai APIs

Sam

igo,

Con

cept

Tut

or, E

tc

SakaiIMS Proxy

SessionAnd Services

Bootstrap

IMS TI OutcomeRequest

ApplicationCode

1

2

34

5

6

7

Launch

Outcome

How IMS TI Works

Tool Interoperability (REST)

• Several sites have written “proxy tools”– UNISA, Indiana, UM …

• As part of integrating CAPA and other tools at Rutgers - Chuck Hedrick has written one that is intended to be flexible, reusable and powerful

• Similar to IMS Tool Interoperability - but using REST approaches (I.e. easier)

• https://source.sakaiproject.org/contrib/rutgers/linktool/

Hedrick Proxy

Going Forward

• We must “dramatically up our game” when it comes to support for data interoperability to allow external applications to fully participate in Sakai and work directly with Sakai’s data

HT

ML

H

TM

LR

ES

T

WebDavSOAP

iCal

SPARQL

RSSCalDav

Collaborationand

Learning

WebDavSOAP Collaborationand

Learning

Current Sakai

Future Sakai

Sakai “Swiss Army Knife”

HT

ML

HT

ML

HT

ML

HT

ML

Sakai Object Bus

SakaiCore

Services

SakaiSemanticServices

NewSemantic

Tools

ExistingSakai

Services

ExistingSakaiTools

Legend Existing Sakai New Work

WebDav

RSS

REST

SPARQL

CalDav

iCal

SOAP

Sakai SOA APIs

Import and Export WebDav

RSS

REST

SPARQL

CalDav

iCal

SOAP

Sakai Web 2.0

Local Configuration

Providers inSakai

Sakai VelocityTools

Sakai JSFTools

Enterprise D

ataSakai JSFSupport

Sakai VelocitySupport

Sakai ServletTools

SakaiFramework

Services

SakaiApplicationServices

RoleProvider

UserProvider

Course/SiteProvider

User Directory Provider

• Very mature - since Sakai 1.0• User type is controlled by provider - this controls the

user template when the user is created• Can provide fully populated User objects or just

answer ID/PW queries• Consulted at log-in• Supports special “properties” known to the provider• Sample providers in release 2.0: JLDAP, OpenLDAP,

Kerberos, and IMS Enterprise in a database

Course Provider

• Does not auto-populate courses• Provides the course list when instructor is

making a new worksite• Consulted during “New Site” operation• More work needed here

– Need to make into a Site provider– Need to be able to set site type from provider– Need to come up with auto population mechanism

Realm Provider (Role)

• Consulted at login• What are the sites and roles within each site

for this user• If the system is using many different roles

throughout, this code must feed the proper site the proper role

• Sakai internal tables are updated as changes from the provider are noticed.

Emerging Integration Points

• CourseManagement

• ContentHosting Plugin

• Calendar Plugin

Questions..