1. Creative Commons Attribution- NonCommercial-ShareAlike 2.5 License Sakai Programmers’ Café Sakai NWU Workshop, South Africa Introduction to Sakai and Sakai Services Antranig Basman antranig@caret.cam.ac.uk

2. 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. 3 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. Java 1.5 Apache - SSL, mod_jk MySql 4.1 Tomcat 5.5 Spring Hibernate (JSF, Velocity) RSF Oracle

4. 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 File Server (opt)

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

6. 6 Sakai Structure 2: 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. 7 Standardised Sakai Services In addition to “free” APIs defined by services, Sakai recognises particular standard varieties of service – some core examples: –UserDirectoryProvider – map your local user information (eg in LDAP, IMS Enterprise, Kerberos) into Sakai –GroupProvider –CourseManagementProvider –PortalHandler (new in Sakai 2.4) – register new top-level handlers in the Sakai portal URL space –EntityProducer – export primary entities handled by your service as 1st-class Sakai “Entities” (resolvable by URLs, addressible by Events, searchable, &c) Look these up in the Sakai JavaDocs, or better still in your Sakai source

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

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

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

11. 11 ClassLoaders in Sakai 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) Component1Component2 APIs up here Components in here Tools in here

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

13. 13 Writing Sakai Components/Services A Sakai component is divided into two parts –An API module containing (generally) only Java interface definitions and constants forms a JAR which is sent to the shared area –An 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

14. 14 The App Builder Plugin Can automate the creation of simple (skeleton) Sakai tools and components Will look today at building a simple Sakai tool and modifying it Over to Åz