Introduction to Sakai and Sakai Services Aaron Zeckoski

Introduction to Sakai and Sakai Services • Aaron Zeckoski • azeckoski@gmail. com From slides by Antanig Basman & Ian Boston Creative Commons Attribution. Non. Commercial-Share. Alike 2. 5 License Sakai Programmers’ Café

Sakai Technical Goals • Enterprise Production-ready • Abstraction boundaries between tools, services, framework, and presentation • Seamless integration across tools when appropriate • Component-based expandability with Class. Loader isolation • Data interoperability and ability to expand Sakai without using Java • Flexibility - Ease of local customization 2

The Sakai Enterprise Technologies Java 1. 5 Apache - SSL, mod_jk (optional) JSP, JSF, Velocity, RSF Presentation Tomcat 5. 5. x Spring Hibernate, JDBC App Delivery My. Sql Oracle Others? • 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. Database 3

Sakai Structure 1: Physical Deployment Load Balancer: Hardware or Software UM = Net. Scaler IU = Software IP Sprayer w/ Sticky Session Hot Spare App servers with identical software loads. UM = Sun. Fire V 480, Quad 900 MHz CPU, 20 GB RAM, 4 Stor. Edge 3310 SCSI RAID Arrays w/ 12 73 Gb disks (Oracle) Hot Spare Database Server App Server UM = 8 X Dell Power. Edge 2650, dual 2. 4 -3. 2 GHz CPU, 4 GB RAM File Server (optional) IU = Net. App File Server (opt) Database Server Hot Spare 4

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 5

Sakai Application Structure Web Browser WS Client Web Svcs Axis Framework WS Endpoint Portal New Portal Other Tools New Tool Presentation Tech Application Other Services Presentation Abstraction Service Interface (i. e. API) New Service Common Services DB Kernel DB 6

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 – User. Directory. Service – handles user information lookups – Session. Manager – handles user sessions – Security. Service – does authorization checks – Site. Service – allows integration with Sakai sites – Tool. Manager – allows finding out the location of a user and information about tools – Function. Manager – registers permissions for tools URL: http: //confluence. sakaiproject. org/confluence/display/BOOT/Sakai+Framework+Tips 7

Standardized Sakai Services • In addition to core services, Sakai also supports the use of providers for integration – User. Directory. Provider – map local user information into Sakai • (e. g. in LDAP, IMS Enterprise, Kerberos) – Group. Provider – map enrollments in groups into Sakai – Course. Management. Provider - 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… 8

What is in Sakai, where is it all? • The Sakai “container” is a lightly(ish) modified J 2 EE (Servlet) container – Tomcat, Web. Sphere, Web. Logic, 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 J 2 EE basics. 9

Class. Loaders • • Class. Loaders are the key means for code insulation and dynamism in Java Most other environments don’t have anything like them Class. Loader rules are poorly understood, even by Sun Unfortunately a working understanding is key to successful Sakai development 10

Class. Loaders in Tomcat (J 2 EE) • • Java Class. Loaders are (meant to) form a tree This is the standard layout for a Servlet container Note that Webapp Class. Loaders 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

Class. Loaders in Sakai APIs up here Components in here Tools in here • • • Component 1 Component 2 Sakai adds to the J 2 EE standard Class. Loader layout “Component” environments are just like Servlets (webapps) in many ways – Use URLClass. Loader – 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) 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 (application. Context. 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

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

Spring framework in Sakai • Sakai takes advantage of Spring to create service beans and load resources • Spring is primarily used for – Io. C (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/ 15

More spring framework • Sakai is currently using Spring 1. 2. 8 – Upgrade to 2. 0. 6 is in progress • Sakai Component. Manager 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 16

Questions? 17