Sakai Technical Overview
Part II
Charles Severance
June 1, 2006
Download: www.dr-chuck.com/talks.php
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 Technologies
Java
1.4
Apache - SSL, mod_jk,
WEBISO, virtual hosting
Sakai
Tomcat 5.5
Spring
Hibernate
Java Server Faces
Velocity (legacy)
MySql 4.1
Oracle
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.
Enterprise Scalability
Hardware or Software
UM = NetScaler IU = Software
IP Sprayer w/
Sticky Session
Hot Spare
App servers with identical
software loads.
UM = SunFire V480, Quad 900 MHz
CPU, 20GB RAM, 4 StorEdge 3310
SCSI RAID Arrays w/ 12 73Gb disks
(Oracle)
Hot Spare
Database Server
App Server
UM = 8X Dell PowerEdge 2650,
dual 2.4-3.2 GHz CPU, 4 GB RAM
File Server (optional)
IU = NetApp
File
Server
(opt)
Database
Server
Hot
Spare
Sakai in Production
Text
20+ Full scale installations
Sakai in Production
myUnisa: 1 Mar 2006 to 17 Mar 2006
Unique visitors: 72675
Number of visits: 169796 (2.33 visits/visitor)
Pages: 10,086,589
Bandwidth: 66.13 GB (408.4 KB/visit)
Text
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
Tool
Library
Sakai
Framework
Service
Library
Customization
Configuration
Service Oriented Architecture
Browser
Browser
ToDo
Presentation
My
Monolithic
ToDo List
Servlet
Persistence
ToDo
Service
Code
Persistence
Service
Interface
(i.e. API)
Fitting Into the Sakai Framework
SAF—Presentation Services
Browser
Presentation
Abstraction
ToDo Tool Layout (JSP)
Framework
ToDo Tool Code (Java)
Service
Interface
(i.e. API)
Application
Other Services
SAF—Common Services
SAF—Kernel
ToDo Service
Sakai Presentation Services
<sakai:view_container title="#{msgs.sample_title}">
<sakai:tool_bar> <sakai:tool_bar_item/> </sakai:tool_bar>
<sakai:instruction_message
value="#{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_item
action="#{MyTool.processActionDoIt}
value="#{msgs.sample_one_cmd_go}" />
</sakai:button_bar>
Web Services
WS Client
Presentation Framework
Presentation
Abstraction
Web Svcs
Axis
Layout
ToDo Layout
Framework
WS End
Point
Other Tools
ToDo Code
Application
Other Services
SAF—Common Services
SAF—Kernel
ToDo Service
Service
Interface
(i.e. API)
Clear Abstraction Boundaries
Abstract Architecture
The Abstract Sakai Environment
• 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
Client
Aggregator
Presentation
Tools
Services
System
Aggregator
Aggregator / Portal
Presentation
Tools
• 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”
Services
Mercury
Apple Portal
VB Portal
Plex PLE
Aggregator
Upcoming Aggregators
Presentation
Tools
• Cleaned up OSP Portal
• Hierarchy Portal - Astro
• Rumors and notions
– Acetylene - Rumored RSF based portal
– Iframe-free portal
– PDA Aggregator
– Better Desktop Portal
Services
Aggregator
Presentation Layer Goals
Presentation
Tools
• True abstraction between Presentation and Tools
Services
• 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 Technologies
Presentation
Tools
• JSF
– Current recommended solution because of setter/getter
pattern and support for reusable GUI components
– Challenging to work with
• Velocity
– Legacy
– Simple, but abstraction is weak on the request-side
• Struts
– Legacy
• RSF
– Emerging but still waiting for proof in all areas
Services
Aggregator
JSF Patterns
Presentation
<sakai:view_container title="#{msgs.sample_title}">
Tools
<sakai:tool_bar> <sakai:tool_bar_item/> </sakai:tool_bar>
Services
<sakai:instruction_message
value="#{msgs.sample_one_instructions}" />
<sakai:group_box
title="#{msgs.sample_one_groupbox}">
<h:inputText
value="#{MyTool.userName}" />
<sakai:button_bar>
<sakai:button_bar_item
action="#{MyTool.processActionDoIt}
value="#{msgs.sample_one_cmd_go}" />
</sakai:button_bar>
<sakai:date_input
value="#{MyTool.date}" />
MyTool.processActionDoIt() {
}
Aggregator
Tools and Services
Presentation
Tools
• 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
Services
Finding Abstraction in your Tomcat
Aggregator
tomcat/webapps/portal
tomcat/webapps/mercury
tomcat/webapps/osp-portal
Presentation
tomcat/webapp/sakai-user-tool
tomcat/webapp/sakai-message-tool
Tools
tomcat/shared/lib/site-api.jar
tomcat/shared/lib/user-api.jar
Services
tomcat/components/sakai-authz-pack
tomcat/components/sakai-user-pack
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.
Reuse in
2.1
Anouncements
Presentation
Resources
Samigo
Melete
Reuse in
2.2
Anouncements
OSPortfolio
Presentation
Resources
Samigo
Melete
Better
Reuse
Anouncements
OSPortfolio
Presentation
Resources
Samigo
Melete
Flexibility
in reuse
Anouncements
OSPortfolio
Presentation
Resources
Samigo
Melete
Scorm
Authoring
We are building a
general way to
do this….
Anouncements
OSPortfolio
Presentation
Resources
Samigo
Language
Module
Melete
Scorm
Authoring
HTML
HTML
HTML
HTML
Sakai Entity
APIs
Existing
Sakai
Tools
Existing
Sakai
Tools
plone
perl
Sakai SOA APIs
SOAP
php
Search
Service
Web
Sakai Services
python
WebDav
Access
Sakai Entity APIs
joomla
Import and Export
Legend
Existing Sakai
2.2 Work
.NET
External
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
*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.
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
WS Client
Presentation Framework
Presentation
Abstraction
Web Svcs
Axis
Layout
ToDo Layout
Framework
WS End
Point
Other Tools
ToDo Code
Application
Other Services
SAF—Common Services
SAF—Kernel
ToDo Service
Service
Interface
(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
How IMS
TI Works
1
6
7
IMS TI Outcome
Request
Application
Code
Sakai
Outcome
5
Sakai
IMS Proxy
Sakai APIs
4
Launch
2
Session
And Services
Bootstrap
3
Samigo, ConceptTutor, Etc
JVM
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
SOAP
Collaboration
and
Learning
WebDav
Current Sakai
SOAP
Collaboration
and
Learning
REST
HTML
HTML
Sakai “Swiss Army Knife”
Future Sakai
WebDav
HTML
HTML
HTML
HTML
SOAP
New
Semantic
Tools
Existing
Sakai
Tools
CalDav
Sakai SOA APIs
SPARQL
Sakai
Core
Services
Existing
Sakai
Services
REST
Legend
Existing Sakai
SPARQL
REST
WebDav
Import and Export
WebDav
CalDav
RSS
Sakai Object Bus
RSS
SOAP
iCal
iCal
Sakai
Semantic
Services
Sakai Web
2.0
New Work
Local Configuration
Sakai Velocity
Support
Sakai JSF
Support
Sakai Velocity
Tools
Sakai JSF
Tools
Providers in
Sakai
Sakai Servlet
Tools
Sakai
Application
Services
Sakai
Framework
Services
Role
Provider
Course/Site
Provider
Enterprise Data
User
Provider
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.
Many Skins…
Text
20+ Full scale installations
Emerging Integration Points
• CourseManagement
• ContentHosting Plugin
• Calendar Plugin
Questions..