Introduction to Sakai and Sakai Services

1
Introduction to Sakai and Sakai Services

• Aaron Zeckoski
• azeckoski_at_gmail.com

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 gt 100,000 users
  in a single installation
• Sakai consists of technologies chosen to be
  common in Java Enterprise Environments.

Tomcat 5.5.x Spring Hibernate, JDBC
JSP, JSF, Velocity, RSF
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 2.4-3.2 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
Database Server
Hot Spare
File Server (opt)
5
Framework, Tools and Services

• Tools
• 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
New Portal
Presentation Abstraction
Portal
New Tool
Other Tools
Axis
Web Svcs
Framework
WS Endpoint
Service Interface (i.e. API)
Application
Other Services
New Service
Common Services
Kernel
DB
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 http//confluence.sakaiproject.org/confluence
/display/BOOT/SakaiFrameworkTips
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 dont 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
Component1
Component2
Tools in here

• Sakai adds to the J2EE standard ClassLoader
  layout
• Component environments are just like Servlets
  (webapps) in many ways
• Use URLClassLoader
• Parent is Shared
• 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 actually they really
  should)

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 tools 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 http//www.springframework.org/
16
More spring framework

• Sakai is currently using Spring 1.2.8
• Upgrade to 2.0.6 is in progress
• 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 this out of shared

17
Questions?