Creative Commons Attribution- NonCommercial-ShareAlike 2.5 License Sakai Programmers’ Café Sakai NWU Workshop, South Africa Recap of Sakai Services Antranig Basman

2 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

3 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

4 Sakai Structure 2: Logical Artefacts 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

5 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

6 User Directory Provider Very mature - since Sakai 1.0 User type is controlled by provider - this controls the user template when the user is created Can provide fully populated User objects or just answer ID/PW queries Consulted at log-in Supports special “properties” known to the provider Sample providers in release 2.0: JLDAP, OpenLDAP, Kerberos, and IMS Enterprise in a database

7 Course Provider Does not auto-populate courses Provides the course list when instructor is making a new worksite Consulted during “New Site” operation More work needed here –Need to make into a Site provider –Need to be able to set site type from provider –Need to come up with auto population mechanism

8 Realm Provider (Role) Consulted at login What are the sites and roles within each site for this user If the system is using many different roles throughout, this code must feed the proper site the proper role Sakai internal tables are updated as changes from the provider are noticed.

9 Emerging Integration Points CourseManagement ContentHosting Plugin Calendar Plugin

10 Accessing and Defining Sakai Services Sakai services are implemented by a set of Spring beans held in the shared Spring context Each Sakai component advertises its services using a Spring-formatted file components.xml These are all read and pooled on Sakai startup, with dependencies automatically sorted and wired together

11 Sakai Services in Spring Sakai APIs are defined in terms of Java interfaces There is ONE implementation of each API interface in Sakai The name of the Spring bean in the Sakai Spring context (file components.xml ) is always the fully qualified interface name Classic example: the Sakai UserDirectoryService Lots more stuff here! Will learn about this later, but concentrate on the familiar elements and There is ONE global, shared Sakai application context holding beans for all Sakai services <bean id="org.sakaiproject.user.api.UserDirectoryService“ class="org.sakaiproject.user.impl.DbUserService" init-method="init"destroy-method="destroy" singleton="true">......

12 Writing Sakai Tools A Sakai tool is “nearly” like a normal Servlet, only with some oddities – (see morning’s talk) –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 Using a Sakai Service in an RSF tool Since RSF is itself written in Spring, consuming Sakai services is particularly direct and easy Every RSF entity is a Spring bean, services can be injected anywhere In this example we will be working only with the rendering layer (Producers), although it is more typical to inject services into the backing beans

14 Sakai Service to an RSF Producer No extra formality Add the setter to the producer, and away you go <property name=“userDirectoryService” ref="org.sakaiproject.user.api.UserDirectoryService”