1. Introduction to Sakai and Sakai Services
Aaron Zeckoski
From slides by Antanig Basman & Ian Boston

2. Sakai Technical Goals Enterprise Production-ready
Abstraction boundaries between tools, services, framework, and presentation
Seamless integration across tools when appropriate
Component-based expandability with ClassLoader isolation
Data interoperability and ability to expand Sakai without using Java
Flexibility - Ease of local customization

3. The Sakai Enterprise Technologies
Java
1.5
Apache - SSL, mod_jk (optional)
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.
JSP, JSF,
Velocity, RSF
Tomcat 5.5.x
Spring
Hibernate, JDBC
Presentation
App Delivery
Database
MySql
Oracle
Others?

4. Sakai Structure 1: Physical Deployment
IP Sprayer w/
Sticky Session
Hot Spare
Load Balancer: Hardware or Software
UM = NetScaler IU = Software
App servers with identical software loads.
UM = 8X Dell PowerEdge 2650, dual GHz CPU, 4 GB RAM
Database Server
UM = SunFire V480, Quad 900 MHz CPU, 20GB RAM, 4 StorEdge 3310 SCSI RAID Arrays w/ 12 73Gb disks (Oracle)
File Server (optional)
IU = NetApp
App Server
Hot Spare
Sakai is a standard n-Tier enterprise production application.
The UM hardware comfortably supports 5000 simultaneous users (500+ per app server)
App servers can be dynamically added or dropped from the cluster (the cluster is self organizing).
At UM this runs in the production area just like PeopleSoft or any other enterprise app with 24x7 support controlled production rolls, etc etc. (i.e. developers have no access at all to production hardware).
File
Server
(opt)
Database
Server
Hot
Spare

5. Framework, Tools and Services
Responsible for presentation (GUI)
Should not do any type of persistence
User facing
Services / Components
Must provide documented API
Cannot do any presentation (not aware of HTML at all)
Must access other services through service APIs
Developer facing
Framework
Provides registration for tools and service
Provides common capabilities and services
Knows nothing of domain objects
Developer/Service facing

6. Sakai Application Structure
Web Browser
WS Client
Portal
New Portal
Presentation
Abstraction
Other Tools
New Tool
Axis
Web Svcs
Presentation Tech
Framework
WS Endpoint
Service
Interface
(i.e. API)
Application
Kernel plays a key role. Part of making things symmetric between web applications and web services.
Kernel completely rewritten for Sakai 2.0.
Other Services
New Service
Common Services DB
Kernel DB

7. Basic Sakai Services
Sakai has many core services to support the tool writer and higher level services
Here are the common ones used by most application developers
UserDirectoryService – handles user information lookups
SessionManager – handles user sessions
SecurityService – does authorization checks
SiteService – allows integration with Sakai sites
ToolManager – allows finding out the location of a user and information about tools
FunctionManager – registers permissions for tools
URL:

8. Standardized Sakai Services
In addition to core services, Sakai also supports the use of providers for integration
UserDirectoryProvider – map local user information into Sakai
(e.g. in LDAP, IMS Enterprise, Kerberos)
GroupProvider – map enrollments in groups into Sakai
CourseManagementProvider - map courses and sections and related information into Sakai
Sakai also has specialized integration points
Entity Broker / Provider – allows your app to participate in the Sakai environment and not just be a user of the services
Create and detect events
Control entity URLs
Attach properties
Import/Export
Etc…

9. What is in Sakai, where is it all?
The Sakai “container” is a lightly(ish) modified J2EE (Servlet) container
Tomcat, WebSphere, WebLogic, etc. are all in use
A Sakai tool is a user-facing element, and is basically a kind of Servlet
A Sakai component is the implementation of some Sakai API, and is a (collection of) Spring Beans
How do tools and components relate to and talk to each other? Need to step back and review some J2EE basics.

10. ClassLoaders
ClassLoaders are the key means for code insulation and dynamism in Java
Most other environments don’t have anything like them
ClassLoader rules are poorly understood, even by Sun
Unfortunately a working understanding is key to successful Sakai development

11. ClassLoaders in Tomcat (J2EE)
Java ClassLoaders are (meant to) form a tree
This is the standard layout for a Servlet container
Note that Webapp ClassLoaders are slightly “odd” in that unlike all others, they will look *locally* to resolve non-System classes first, rather than looking in parent first
This can be the cause of various “hilarious” errors/difficulties in Sakai

12. ClassLoaders in Sakai
APIs up here
Components in here
Tools in here
Component1
Component2
Sakai adds to the J2EE standard ClassLoader layout
“Component” environments are just like Servlets (webapps) in many ways
Use URLClassLoader (standard CL semantics, inverse of webapp CL)
Parent is Shared (tomcat 5.5) or lib (Tomcat 6.0)
Unlike them in some others
Only components.xml (Spring file), no web.xml
Respond only to function calls, not to Servlet dispatches!
Do not reload (currently – would be nice if they would)

13. Writing Sakai Tools
A Sakai tool is “nearly” like a normal Servlet, only with some oddities
URL environment is “screwed up” which prevents using normal view technologies straightforwardly
RSF, JSF and Velocity have “first class support”
Extra packaging required, with special material in web.xml, as well as a tool registration file (tools/toolname.xml)
All of this is taken care of by the App Builder Plugin
The tool’s Spring context (applicationContext.xml) is automagically “glued” onto the bottom of the global shared Spring context, so Sakai services can be directly referenced in Spring
Spring JARs must NOT be included in the application, since they are already in shared

14. Writing Sakai Components/Services
A Sakai component is divided into three parts
An API module
contains Java interface definitions and constants
often contains model and sometimes utils
might also contain HBM mapping files
forms a JAR which is sent to the shared area
An Implementation (IMPL) module
contains implementations for the API interfaces
among other things
a Spring-formatted components.xml file which publishes the implementation beans to the shared Spring context.
forms a WAR which is sent to the components area
A test module
Contains programmatic tests (unit/integration tests)

15. Spring framework in Sakai
Sakai takes advantage of Spring to create service beans and load resources
Spring is primarily used for
IoC (dependency injection)
Transaction control (for DB access)
Testing (Transactional testing)
Resource loading (properties etc.)
Basic Spring understanding is critical for working with Sakai framework services
URL:

16. More spring framework Sakai is currently using Spring 2.0.6
Upgrade to 2.5 in future
Sakai ComponentManager is built on the Spring framework
This will not change anytime soon
Spring must be deployed in shared
Work is in progress to move some of this out of shared

17. Advanced concepts
Spring behavior can be tricky in the weird Sakai ClassLoader environment
Looking up resources in a component requires something special
Sakai loads all components into a common application context in a custom way you are unlikely to see anywhere else

18. Questions?