Creative Commons Attribution- NonCommercial-ShareAlike 2.5 License Sakai Programmers’ Café 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 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 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 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 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:

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) Component1Component2 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:

16 More spring framework Sakai is currently using Spring –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?