Sakai Technical Overview Charles Severance Download:

Sakai Technical Overview

Charles Severance

Download: www.dr-chuck.com/talks.php

Overview Video: http://www.dr-chuck.com/media.php?id=64

Sakai Overview• Sakai is used for Collaboration, Teaching, and

Learning• Sakai Project started January 2004 • Non-profit Sakai Foundation January 2006• Open Source - 100% free - Apache License• Voluntary financial support from 100+ Higher

Education organizations• Six paid staff members• Worldwide community with 100+ people active

in developing and testing Sakai releases• See www.sakaiproject.org

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

Enterprise Production-Ready

Sakai Enterprise TechnologiesJava1.4

Oracle

Apache - SSL, mod_jk, WEBISO, virtual hosting

MySql 4.1

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.

SakaiTomcat 5.5

SpringHibernate

Java Server FacesVelocity (legacy)

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)

Sakai in Production

Text

20+ Full scale installations

Sakai in Production

140 Sites in Production

Sakai in Production

Text

myUnisa: 1 Mar 2006 to 17 Mar 2006Unique visitors: 72675Number of visits: 169796 (2.33 visits/visitor)Pages: 10,086,589Bandwidth: 66.13 GB (408.4 KB/visit)

Sakai in Production

Text

High Level

Framework, Tools and Services

• 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

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

Service Oriented Architecture

Persistence

ServiceInterface(i.e. API)

Fitting Into the Sakai Framework

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

Sakai Presentation Services

<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>

Web Services

Framework

Application

ToDo Code

ToDo Layout

Presentation FrameworkWS Client

Axis

WS End Point

Web Svcs

Other Tools

Layout


SAF—Kernel


Other Services ToDo Service


Clear Abstraction Boundaries

Aggregator

Presentation

Tools

Services

Client

SystemT

he A

bstr

act

Sak

ai E

nviro

nmen

t

Abstract Architecture

• 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

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”

• Supports Sakai Tools as well as JSR-168 portlets

Aggregator

Presentation

Tools

Services

Mercury

Apple Portal

VB Portal

QuickTime™ and aTIFF (Uncompressed) decompressor

are needed to see this picture.

Prototype of Sakai working in the Bodington Learning Management System

Plex PLE

Sakai and RSS

• Public/Anonymous or User-contextualized• This can allow Sakai to be integrated into a

wide range of applications including portals, browsers and desktop apps

• Feature added to Sakai 2.4 and will be back ported to Sakai 2.3

Sakai WorkGroup Portal

• Extend the Sakai “gateway” site which is displayed prior to log in to display more than one “site”

• Allows Sakai to be used as a simple Content Management System like Mambo or Plone

• Sakai Workgroup portal is released in Sakai 2.4 and will be back-ported to Sakai 2.3

Sakai Gateway Site

Use Cases for Sakai-168

• Prepare a Pluto-style portlet war file and drop it into Sakai as a webapp - autoregister

• Users simply use Sakai’s Site Info tool to place portlets like any other Sakai tool

• It will be possible to use any Sakai API within a JSR-168 Portlet

• Sakai will provide a JSR-168 complaint classes so that portlets have the same look and feel as Sakai tools

SakaiTool

RequestFilter

JSR-168Tool

PortletServlet

Sakai ToolRegistration

Pluto PortletRegistration

Sakai’s Aggregator SakaiSite Setup

Pluto Container

Sakai ToolDispatch

Pluto 1.1 Integrated into Sakai

JSR168 in Sakai

Upcoming Aggregators

• XSLT Based Portal

• Hierarchy Portal - Astro

• Rumors and notions– Acetylene - Rumored RSF based portal– iFrame-free portal– Better Desktop Portal

Aggregator

Presentation

Tools

Services

Presentation Layer Goals

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

browser environment• GUI Widget reusability• 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, including under control of the end user

Aggregator

Presentation

Tools

Services

Presentation Technologies

• Java Server Faces - JSF– Current recommended solution because of setter/getter pattern

and support for reusable GUI components– Challenging to work with

• Velocity– Simple, but abstraction is weak on the request-side

• Real Server Faces - RSF– Emerging as preferred approach with rich component reusability

• JSR-168 - Portlets– A well-established standard and simple to use – Suitable for simple tools – Portability between Sakai and other JSR-168 Portals

Aggregator

Presentation

Tools

Services

<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

Finding Abstraction in your Tomcat

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

Sakai Tools

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


Samigo

Melete

Anouncements

Reuse in 2.2

OSPortfolio


Samigo

Melete

Anouncements

BetterReuse

OSPortfolio


Samigo

Melete

Anouncements

Flexibility in reuse

ScormAuthoring

OSPortfolio


Samigo

MeleteLanguageModule

Anouncements

We are building a general way to do

this….

ScormAuthoring

OSPortfolio

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

Tool

Moving Tools into the Sakai Release

• 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

*Sample* Attribute Matrix

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 No No

Ease of Expansion Including non-Java Tools

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.

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

• IMS Tool Interoperability Version 1.0• Uses web services and IFRAMES

• Roughly based on WebCT PowerLinks

• Does not require tools to be written in Java

• IMS Tool Interoperbility Version 2.0• Work is underway - hope to imitate PowerLinks Web Services

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



Sakai IMS TI Implementations

• Sakai Tool (Anthony)– Fully compliant– Multiple tools per placement– Rich persistence

• JSR-168 Portlet (Chuck)– Does not support Outcome Request– Users JSR-168 preferences as persistence– Portable between Sakai and Portals– Extensions

• IMS TI Lite - SOAP Lite• Load Descriptor from URL





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

Sakai 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


SAF—Kernel


Other Services ToDo Service


Installation and Configuration

Installing Sakai

• Downloads– System Requirements– Documentation– Getting the Latest Source Code– Issue Tracking– Community– Getting Older Releases– License

• http://source.sakaiproject.org/release/2.3.1/

Providers inSakai

Sakai VelocityTools

Sakai JSFTools

Enterprise D

ataSakai JSFSupport

Sakai VelocitySupport

Sakai ServletTools

SakaiFramework

Services

SakaiApplicationServices

Roster/RoleProvider

User DirectoryProvider

Course/SiteProvider

https://source.sakaiproject.org/svn/providers/trunk/

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 (Group/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

Developing a Skin for Sakai

• Documentation– https://source.sakaiproject.org/svn//

reference/trunk/docs/architecture/sakai_skin.doc

Many Skins…

Text

20+ Full scale installations

Developing for Sakai

Choices…

• Native Sakai Tool

• JSR-168 Portlet

• Integrate an Existing Tool

When to write a native tool

• When you want to be part of the Sakai release

• When you have a complex user interface and need to reuse UI Widgets

• When you want make use of other tools (we call these helpers)

• When you want to work closely with the rest of the system (like search)

When to write a JSR-168 Portlet?

• When your tool is pretty simple and has a simple user interface

• When your tool has simple persistence needs - particularly when you can use properties

• When the tool is self-contained and has potential reuse outside of Sakai

When to Integrate a tool?

• When you already have an established tool that is well-developed

• When you do not want to write in Java.• When you want to keep your tool stand-alone

as well as inside of Sakai• When your tool has very low interaction with

Sakai components other than user identity, user roles, and context (site/course)

Building a Sakai Tool

• Sakai Programmer’s Café

• http://bugs.sakaiproject.org/confluence/display/BOOT/Home

Building a JSR-168 Portlet

• Download JSR-168 Specification– http://jcp.org/en/jsr/detail?id=168

• Development Documentation– http://developers.sun.com/portalserver/reference/

techart/jsr168/– http://portals.apache.org/pluto/v11/resources.html

• Portlets in Sakai– https://source.sakaiproject.org/contrib/portlets/trunk/– https://source.sakaiproject.org/svn//reference/

trunk/docs/architecture/sakai-168-portlet-tool.doc

Integrating a tool using IMS TI

• Documentation still in progress since this is a recent addition to Sakai– http://www.sakaiproject.org/imsti-test/

• IMS Tool Interoperability Portlet– https://source.sakaiproject.org/contrib/

portlets/trunk/

• TO DO:– Write IMS TI - Lite in PHP and Ruby

Discussion and Examples

Documents

Sakai Technical Overview Charles Severance Download: