Introduction to Sakai and Sakai Services

ballooncadgeInternet and Web Development

Oct 31, 2013 (4 years and 8 days ago)

239 views

Creative Commons Attribution
-
NonCommercial
-
ShareAlike 2.5 License

Sakai Programmers’ Café

Introduction to Sakai

and Sakai Services

Aaron Zeckoski

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

Database

Java

1.5

Apache
-

SSL, mod_jk

(optional)

MySql

The Sakai Enterprise Technologies


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.

Oracle

Tomcat 5.5.x

Spring

Hibernate,
JDBC

Others?

JSP, JSF,

Velocity, RSF


Presentation

App Delivery

4

Database

Server

IP Sprayer w/

Sticky Session

Sakai Structure 1: Physical Deployment

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

Hot Spare

Hot Spare

File

Server

(opt)

5


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

Framework, Tools and Services

6

Sakai Application Structure

Framework

Application

Presentation Tech

WS Client

Axis

WS Endpoint

Web Svcs

New Tool

New Portal

Other Tools

Portal

Presentation

Abstraction

Kernel

Common Services

Other Services

New Service

Service

Interface

(i.e. API)

DB

DB

Web Browser

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/Sakai+Framework+Tips

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


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)

Component1

Component2

APIs up here

Components in here

Tools in here

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:
http://www.springframework.org/

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?