Introduction to Sakai and Sakai Services Aaron Zeckoski azeckoski@gmail.com From slides by Antanig Basman & Ian Boston

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

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?

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

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

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

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

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…

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.

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

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

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)

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

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)

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/

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

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

Questions?