sakai technical overview
DESCRIPTION
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 - PowerPoint PPT PresentationTRANSCRIPT
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