Sakai Technical Overview

Charles Severance

Sakai Chief Architect

November 7, 2005

The Ideal Sakai Deployment

• Take an empty Sakai system– Choose a set of 10-15 tools

for your needs– Choose a set of Services

(web services, etc)– 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

SakaiTool

Library

SakaiServiceLibrary

LocalCustomization

Sakai Goals

• Component based expandability• Appearance of a single well-integrated

application• Flexible Presentation (HTML, Portals)• Support for Web Services• Flexibility in Expansion including non-

Java• Production-ready

Framework, Tools and Services

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

• Services– 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

Sakai Service Rules

Tool A

X DataModel

X API

Service XImpl

Tool B

Y DataModel

Y API

Service YImpl

Tools can access Service APIs

Services can access Service APIs

We must be able to swap Service implementations

Substituting Service Implementations

Tool A

X API

Service XWS Impl

Tool B

Y DataModel

Y API

Service YImpl

If a deployment chooses to implement Service X is using web services, there is no data model and any implementation-X specific access is no longer available.X Web

Service

The

Sak

ai F

ram

ewor

k

SakaiService

SakaiService

SakaiTPP Tool

SakaiTPP Tool

Sakai Framework

• Registration of tools and services

• Provides portability between environments where possible– HTML / Web Services

• Framework includes presentation elements as well to support tools

The

Sak

ai F

ram

ewor

k

SakaiService

SakaiTPP Tool

Functionality Flow

• Goal: no replication of code

• Code trends toward the broadest and most reusable are of the system– Framework– Service– Tools

• As long as it does not break the “rules”

SakaiTPP Tool

SakaiService

Goal: Appear as Single Integrated Application

Why Build A Sakai Tool?

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

Sakai User?• Want a servlet “in Sakai” but with a minimum of

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

Sakai Goals (may conflict)

• A collaborative application– Reusable objects (Quiz Questions) across

many tools– Component based - any component can be

removed without harming the system

• Extremely easy to expand - reduce barriers to adding a new tool

Resources Presentation

Samigo

Melete

Anouncements

CurrentReusein 2.0

Resources Presentation

Samigo

Melete

Anouncements

BetterReuse

Resources Presentation

Samigo

Melete

Anouncements

Flexibility in reuse

ScormAuthoring

Resources Presentation

Samigo

MeleteLanguageModule

Anouncements

So you want to write a new

tool?

ScormAuthoring

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

Two Layer Architecture

TaskTool

Task API

TaskAPI

Impl.

Task DB

TaskTool

Task DB

Presentation

Public Abstraction

Persistence,Business Logic,ORM, etc…

To fully integrate into “Sakai

TaskTool

Task API

TaskAPI

Impl.

Placement

Import/export

Components

Authorization

OtherTools

WebServices

Sakai DB

AutoDDL

Helper

Internationalization

Sakai 2.0 Framework

Sakai 2.0 Design Approach

• Significant re-factor of functionality– SAF - Kernel

• Components/Spring Session, Tool registry, Identity• Support for Sakai tools, basic servlets, web services, and webdav• Thread conditioning, Servlet filter• Kernel enables the other services

– SAF - Services• Primary support APIs which for tool interactions

– SAF - Presentation Services• JSF, Velocity, Servlet

• Major goal: Clean support for servlets, web services, and webdav using the Kernel

SAF Design Documents

• Sakai Tool Model• Sakai Sessions• Sakai Request Flow• Sakai Mercury

Portal• Sakai Use of Maven

• Sakai Configuration• Sakai Charon Portal• Sakai Component

Model• Sakai Authentication• others

These documents on collab.sakaiproject.org“Sakai Development”

SAF - Kernel

• Does not go “above” servlet level - “provisions” a Sakai servlet (and its thread) to fully operate

• Elements (6900 lines of code)– Components - Interaction with Spring to register/retrieve the

Sakai API implementations with class-loader isolation– Session

• httpSession - shared Sakai-wide for user/login• sakaiSession - shared Sakai-wide for user/login• sakaiToolSession - scoped by user/login/placement

– Tool registry - including support for “helpers”– Identity of current logged in user– Utilities including thread local support

SAF - Components

• It is like container-wide Spring components, each with their own class loader

• In Sakai 1.0 and 1.5 we placed components in webapps to get the class loader isolation, but we ended up with load-order problems

• In Sakai 1.0 and 1.5 we “bent” Spring to orchestrate Sakai components

• In Sakai 2.0 components simply appear “in Spring”

tomcat/components component-1 WEB-INF components.xml classes lib component-2 WEB-INF components.xml classes lib

tomcat/webapps/app1

ComponentManageror

Spring

tomcat/webapps/app2

ComponentManageror

Spring

common/lib spring sakaiComponentManager

Each component looks like a webapp, but with no web.xml. Each has classes and its own “lib”. Their class loader uses common and shared.

All globally registered components are available to Spring for injection (Interface names are the bean names) or via the Sakai ComponentManager API using Service Locator pattern.

SAF-Components

SAF-Components Benefits

• Separate class loaders for each component, and each webapp

• Allows the jar footprint of one component not to be forced to overlap with all of the other components, tools, portal, etc.– Multiple conflicting xerxes can be kept separate– Adding/replacing a tool or component does not

break things like the portal or other components

• Provides an EJB-like isolation but using Spring to connect components to client code

SAF - Session

• Tomcat Sessions leave much to be desired– Cross-context dispatch issues (fights between Pluto and

Tomcat - changes between dot versions)– Not well suited for Web Services or WebDav when browser

is not involved– Lifecycle issues - can’t always count on cleanup– Scope issues - Shared / Servlet / Portlet

• Sakai sessions solve all of these problems

SAF-Session Scenarios

Browser A

WebDavClient

WS or WSRPClient

Tool X1

Tool Y1

Browser B

Tool X2

Tool Y2

Renderer Servlet

Tool X(Portlet)

Tool Y(Servlet)

Filter

WebDavServlet

AxisServlet

Sakai APIs need logged in user, current session, etc.

Filter Filter

Cookie set via login or at SSO via WebISO

Basic Auth(Cookie opt)

WS AuthSession ID

Re-dispatch

FilterFilter

Web Services

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

• Web Services shipped in Sakai 2.0

• Based on Axis 1.2• Release 2.0

includes sample PHP client

Web ServicesClient

Jakarta Axis

Sakai APIs

Sakai Kernel

WS End Point

Samples Only

Available in Sakai 2.0

Sakai Web Services Endpointimport org.sakaiproject.api.kernel.session.Session;import org.sakaiproject.api.kernel.session.cover.SessionManager;

public class SakaiSession {

public String checkSession(String id) { System.out.println("session id="+id); Session s = SessionManager.getSession(id); if (s == null) { System.out.println("no session established"); return "Session Null"; } else { String resp = "session: " + s.getId() + " user id: " + s.getUserId() + " user enterprise id: " + s.getUserEid() + " inactive after: " + s.getMaxInactiveInterval(); System.out.println(resp); return resp; } }}

Sakai Web Services Clientrequire_once('SOAP/Client.php');

if ( ! $_POST['url'] ) $_POST['url'] = "http://nightly2.sakaiproject.org/sakai-axis/";

if ( $_POST['login'] ) { $site_url = $_POST['url'] . 'SakaiLogin.jws?wsdl'; echo ("Loggging in to Sakai Web Services at ".$site_url); $wsdl=new SOAP_WSDL($site_url);

// Create an object directly from the proxy code $myProxy=$wsdl->getProxy();

$session=$myProxy->login("admin","admin");

echo ("Session:"); print_r ($session ); $_POST['session'] = $session;}

Flexible Presentation

Aggregator

Presentation

Tools

Services

Client

SystemT

he A

bstr

act

Sak

ai E

nviro

nmen

t

Abstract Architecture

• To render a Sakai response, the tools, and services work with other elements– Presentation Support– Aggregation

The

Sak

ai F

ram

ewor

k

InternalAggregator

Sakai ToolPresentation

SakaiTool Code

ApplicationServices

FrameworkServices

PresentationSupport

The

Sak

ai T

ool E

nviro

nmen

t

ExternalAggregator

System

Writing a Tool

• Each tool describes its presentation needs in a generic fashion - the framework provides mechanisms to render the tool’s presentation

• The tool is unaware of any aggregation or final presentation

• Tools may produce “application” services related to the tools (chat tool / chat service)

• A service built for a particular tool should still operate through an API and be available to other tools

The

Sak

ai F

ram

ewor

k

HTML BasedAggregator

GUI layout(JSF/JSP)

ScheduleTool (Java)

ScheduleAPI (Java)

OSID IdAPI

Sakai JSFWidget Set

The

Sak

ai T

ool E

nviro

nmen

t

uPortal viaWSRP

System

An Example

• This is a tool written using the Sakai JSF widget set

• The tool builds its own API (Schedule)

• The tool makes use of framework APIs.

• The tool is rendered in HTML and displayed within uPortal via the Web Services for Remote Portlets (WSRP) protocol

• Outside the tool, there is great flexibility which is hidden to the tool

The

Sak

ai F

ram

ewor

k

Servlet/HTMLRenderer

Java ServerFaces in JSP

Java Tool LogicJava Beans

Sakai ApplicationServices

Sakai JSFWidget Set

The

Sak

ai T

ool E

nviro

nmen

t

Portals viaiframe

Sakai and/or OKIAPIs

Sakaiiframe

WSRPRenderer

SakaiNon iframe

Portals viaWSRP

JSR-168Renderer

uPortal viaJSR-168

Rendering Flexibility

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

Tool Display in JSF

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

MyTool.userName() {}

MyTool.date() {}

MyTool.processActionDoIt() {}

Describing Actions in JSF

The

Sak

ai F

ram

ewor

kHTML BasedAggregator

Java ServerFaces in JSP

Java Tool LogicJava Beans

Sakai ApplicationServices

Hibernate

Sakai JSFWidget Set

The

Sak

ai T

ool E

nviro

nmen

t

uPortal viaiframe

VelocityTemplates

Sakai LegacyTools

Sakai LegacyServices

SakaiFramework APIs

Sakai VelocitySupport Layer

The

Sak

ai L

egac

y E

nviro

nmen

t

SakaiStand-Alone

OKI OSIDs

OKI OSIDLegacy Covers

Support For Velocity Tools

LoginBranding

Site Selection

Tool Selection

Tool AreaTool Area

Presence

HTML Aggregator - Charon

CharonPortal

Kernel Tool Registry

Charon

Tool A Tool B Tool C

Sakai Sites

Request Filter

Mercury

WSRP Activities

• SunGard-led and funded: Vishal Goenka• Working with uPortal in their WSRP 3.0 effort• As we really try to use WSRP, we identify issues in

the standard and WSRP4J implementation• Sakai and uPortal are becoming involved in WSRP

standards activities and WSRP4J

Sakai

tool tool

HTTP

WSRP

Portal

Sakai

tool tool

HTTP

Sakai

tool tool

HTTP

Non-Sakai Non-Java Tools

tool tool

WS

RP

Non-SakaiTool

WSRP WSRP

WSRP Use Case

WSRP“Portal”

Kernel Tool Registry

Sakai WSRP

Tool A Tool B Tool C

Sakai Sites

Request Filter

Apache WSRP4J

WSRP ConsumerPortal

Web Services

WSRPPlacements

WSRP Image

Visual Basic Portal

Kernel Tool Registry

Sites Web Service

Tool A Tool B Tool C

Sakai Sites

Request Filter

- Server - Site Tool Tool + Site+ Server

Visual Basic Portal

- System X - Site Tool Tool + Site+ System Y

SakaiX

SakaiY

QuickSakai: Apple Desktop

Many Portals..

Kernel Tool Registry

Charon

Tool A Tool B Tool C

Browser

Request Filter

Mercury Astro ?? WSRP Web Svc

Browser

DesktopPortal

WebPortal

Browser

Varuna

Sedna

Web Services

Ease of Expansion Including non-Java Tools

Sakai Goals (may conflict)

• A collaborative application– Reusable objects (Quiz Questions) across

many tools– Component based - any component can be

removed without harming the system

• Extremely easy to expand - reduce barriers to adding a new tool

Simpler Routes to New Tools

• May want to write in PHP, or some other language other than java

• May not want to comply with “Sakai” rules such as import/export, accessibility, or internationalization

• May just want very small distribution (I.e. not part of the Sakai release)

• Perhaps a very innovative early concept

IMS Tool Portability Group

• 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• Does not require tools to be written in Java• Working demonstration at the July 2005 Alt-I-lab

with Samigo in Sakai, WebCT, and Blackboard

JVM

Sak

ai

Sakai APIs

Sam

igo,

Con

cept

Tut

or, E

tc

SakaiIMS Proxy

SessionAnd Services

Bootstrap

Sakai WebServices

ApplicationCode

1

2

34

5

6

7

Launch

Outcome

How IMS TI Works

Going Forward

Sakai 2.1

• Expected December 1, 2005• Performance improvements and bug fixes• Sections and Groups within a Site

– Section Tool, Announcements, Gradebook, Samigo

• Provisional Tools– SU Tool, Roster Tool, Wiki, WSRP, TwinPeaks

Sakai 2.2 (best guess)

• Second Quarter 2006• Hierarchy• Open Source Portfolio• More tools Section Aware• IMS Content Packaging Import and Export• Provisional Tools (initial list)

– Mail Tool, IU Discussion Tool, Melete, JSR-168 Portlet, IMS Tool Portability, Blog, JForums

Way Long Term

• Sakai / uPortal tightly integrated– JSR-168, WSRP Consumer, WSRP

Producer

• JSR-170 - Java Content Repository• IMS Common Cartridge• All domain objects fully modeled with

published Data models and RDF/OWL support

Summary / Questions

• Thank you for your time