1. Sakai Technical Overview Charles Severance Sakai Chief Architect November 7, 2005

2. The Ideal Sakai Deployment Take an empty Sakai system –Choose a set of 10-15 tools for your needs –Choose a set of Services (web services, etc) –Add some local customizations, look feel, language etc And you have a production ready system Tools and capabilities written by many different groups or individuals Sakai Framework Sakai Tool Library Sakai Service Library Local Customization

3. Sakai Goals Component based expandability Appearance of a single well-integrated application Flexible Presentation (HTML, Portals) Support for Web Services Flexibility in Expansion including non- Java Production-ready

4. Framework, Tools and Services Tools –Cannot do any type of persistence –Responsible for presentation (GUI) Services –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

5. Component Based Expansion

6. Sakai Service Rules Tool A X Data Model X API Service X Impl Tool B Y Data Model Y API Service Y Impl Tools can access Service APIs Services can access Service APIs We must be able to swap Service implementations

7. Substituting Service Implementations Tool A X API Service X WS Impl Tool B Y Data Model Y API Service Y Impl If a deployment chooses to implement Service X is using web services, there is no data model and any implementation-X specific access is no longer available. X Web Service

8. The Sakai Framework Sakai Service Sakai Service Sakai TPP Tool Sakai TPP Tool Sakai Framework Registration of tools and services Provides portability between environments where possible –HTML / Web Services Framework includes presentation elements as well to support tools

9. The Sakai Framework Sakai Service Sakai TPP Tool Functionality Flow Goal: no replication of code Code trends toward the broadest and most reusable are of the system –Framework –Service –Tools As long as it does not break the “rules” Sakai TPP Tool Sakai Service

10. Goal: Appear as Single Integrated Application

11. Why Build A Sakai Tool? Want your website under a button in Sakai? Want your PHP app to know the current logged in Sakai User? Want a servlet “in Sakai” but with a minimum of rework? Full blown Sakai tool - released separately? An optional part of the Sakai release? A core part of the Sakai release?

12. Sakai Goals (may conflict) A collaborative application –Reusable objects (Quiz Questions) across many tools –Component based - any component can be removed without harming the system Extremely easy to expand - reduce barriers to adding a new tool

13. Resources Presentation Samigo Melete Anouncements Current Reuse in 2.0

14. Resources Presentation Samigo Melete Anouncements Better Reuse

15. Resources Presentation Samigo Melete Anouncements Flexibility in reuse Scorm Authoring

16. Resources Presentation Samigo Melete Language Module Anouncements So you want to write a new tool? Scorm Authoring

17. Building Tools To meet the goals of Sakai it is not sufficient to simply build a stovepipe tool While much of what is described here is “optional”, the more “integrated” a tool intends to be, the more “required” these elements become

18. Two Layer Architecture Task Tool Task API Task API Impl. Task DB Task Tool Task DB Presentation Public Abstraction Persistence, Business Logic, ORM, etc…

19. To fully integrate into “Sakai Task Tool Task API Task API Impl. Placement Import/export Components Authorization Other Tools Web Services Sakai DB AutoDDL Helper Internationalization

20. Sakai 2.0 Framework

21. Sakai 2.0 Design Approach Significant re-factor of functionality –SAF - Kernel Components/Spring Session, Tool registry, Identity Support for Sakai tools, basic servlets, web services, and webdav Thread conditioning, Servlet filter Kernel enables the other services –SAF - Services Primary support APIs which for tool interactions –SAF - Presentation Services JSF, Velocity, Servlet Major goal: Clean support for servlets, web services, and webdav using the Kernel

22. SAF Design Documents Sakai Tool Model Sakai Sessions Sakai Request Flow Sakai Mercury Portal Sakai Use of Maven Sakai Configuration Sakai Charon Portal Sakai Component Model Sakai Authentication others These documents on collab.sakaiproject.org “Sakai Development”

23. SAF - Kernel Does not go “above” servlet level - “provisions” a Sakai servlet (and its thread) to fully operate Elements (6900 lines of code) –Components - Interaction with Spring to register/retrieve the Sakai API implementations with class-loader isolation –Session httpSession - shared Sakai-wide for user/login sakaiSession - shared Sakai-wide for user/login sakaiToolSession - scoped by user/login/placement –Tool registry - including support for “helpers” –Identity of current logged in user –Utilities including thread local support

24. SAF - Components It is like container-wide Spring components, each with their own class loader In Sakai 1.0 and 1.5 we placed components in webapps to get the class loader isolation, but we ended up with load-order problems In Sakai 1.0 and 1.5 we “bent” Spring to orchestrate Sakai components In Sakai 2.0 components simply appear “in Spring”

25. tomcat/components component-1 WEB-INF components.xml classes lib component-2 WEB-INF components.xml classes lib tomcat/webapps/app1 ComponentManager or Spring tomcat/webapps/app2 ComponentManager or Spring common/lib spring sakaiComponentManager Each component looks like a webapp, but with no web.xml. Each has classes and its own “lib”. Their class loader uses common and shared. All globally registered components are available to Spring for injection (Interface names are the bean names) or via the Sakai ComponentManager API using Service Locator pattern. SAF- Components

26. SAF-Components Benefits Separate class loaders for each component, and each webapp Allows the jar footprint of one component not to be forced to overlap with all of the other components, tools, portal, etc. –Multiple conflicting xerxes can be kept separate –Adding/replacing a tool or component does not break things like the portal or other components Provides an EJB-like isolation but using Spring to connect components to client code

27. SAF - Session Tomcat Sessions leave much to be desired –Cross-context dispatch issues (fights between Pluto and Tomcat - changes between dot versions) –Not well suited for Web Services or WebDav when browser is not involved –Lifecycle issues - can’t always count on cleanup –Scope issues - Shared / Servlet / Portlet Sakai sessions solve all of these problems

28. SAF-Session Scenarios Browser A WebDav Client WS or WSRP Client Tool X1 Tool Y1 Browser B Tool X2 Tool Y2 Renderer Servlet Tool X (Portlet) Tool Y (Servlet) Filter WebDav Servlet Axis Servlet Sakai APIs need logged in user, current session, etc. Filter Cookie set via login or at SSO via WebISO Basic Auth (Cookie opt) WS Auth Session ID Re-dispatch Filter

29. Web Services

30. Web Services allow flexible reuse of API and services in contexts beyond the Sakai interfaces –WSRP presentation –SOAP - RPC Web Services Issues –Security –Performance –API needs to tend towards document-style rather than RPC-style

31. Web Services Web Services shipped in Sakai 2.0 Based on Axis 1.2 Release 2.0 includes sample PHP client Web Services Client Jakarta Axis Sakai APIs Sakai Kernel WS End Point Samples Only Available in Sakai 2.0

32. Sakai Web Services Endpoint import org.sakaiproject.api.kernel.session.Session; import org.sakaiproject.api.kernel.session.cover.SessionManager; public class SakaiSession { public String checkSession(String id) { System.out.println("session id="+id); Session s = SessionManager.getSession(id); if (s == null) { System.out.println("no session established"); return "Session Null"; } else { String resp = "session: " + s.getId() + " user id: " + s.getUserId() + " user enterprise id: " + s.getUserEid() + " inactive after: " + s.getMaxInactiveInterval(); System.out.println(resp); return resp; }

33. Sakai Web Services Client require_once('SOAP/Client.php'); if ( ! $_POST['url'] ) $_POST['url'] = "http://nightly2.sakaiproject.org/sakai-axis/"; if ( $_POST['login'] ) { $site_url = $_POST['url']. 'SakaiLogin.jws?wsdl'; echo ("Loggging in to Sakai Web Services at ".$site_url); $wsdl=new SOAP_WSDL($site_url); // Create an object directly from the proxy code $myProxy=$wsdl->getProxy(); $session=$myProxy->login("admin","admin"); echo ("Session:"); print_r ($session ); $_POST['session'] = $session; }

34. Flexible Presentation

35. Aggregator Presentation Tools Services Client System The Abstract Sakai Environment Abstract Architecture To render a Sakai response, the tools, and services work with other elements –Presentation Support –Aggregation

36. The Sakai Framework Internal Aggregator Sakai Tool Presentation Sakai Tool Code Application Services Framework Services Presentation Support The Sakai Tool Environment External Aggregator System Writing a Tool Each tool describes its presentation needs in a generic fashion - the framework provides mechanisms to render the tool’s presentation The tool is unaware of any aggregation or final presentation Tools may produce “application” services related to the tools (chat tool / chat service) A service built for a particular tool should still operate through an API and be available to other tools

37. The Sakai Framework HTML Based Aggregator GUI layout (JSF/JSP) Schedule Tool (Java) Schedule API (Java) OSID Id API Sakai JSF Widget Set The Sakai Tool Environment uPortal via WSRP System An Example This is a tool written using the Sakai JSF widget set The tool builds its own API (Schedule) The tool makes use of framework APIs. The tool is rendered in HTML and displayed within uPortal via the Web Services for Remote Portlets (WSRP) protocol Outside the tool, there is great flexibility which is hidden to the tool

38. The Sakai Framework Servlet/HTML Renderer Java Server Faces in JSP Java Tool Logic Java Beans Sakai Application Services Sakai JSF Widget Set The Sakai Tool Environment Portals via iframe Sakai and/or OKI APIs Sakai iframe WSRP Renderer Sakai Non iframe Portals via WSRP JSR-168 Renderer uPortal via JSR-168 Rendering Flexibility

39. <sakai:instruction_message value="#{msgs.sample_one_instructions}" /> <sakai:group_box title="#{msgs.sample_one_groupbox}"> <h:inputText value="#{MyTool.userName}" /> <sakai:date_input value="#{MyTool.date}" /> Tool Display in JSF

40. <h:inputText value="#{MyTool.userName}" /> <sakai:date_input value="#{MyTool.date}" /> MyTool.userName() { } MyTool.date() { } MyTool.processActionDoIt() { } Describing Actions in JSF

41. The Sakai Framework HTML Based Aggregator Java Server Faces in JSP Java Tool Logic Java Beans Sakai Application Services Hibernate Sakai JSF Widget Set The Sakai Tool Environment uPortal via iframe Velocity Templates Sakai Legacy Tools Sakai Legacy Services Sakai Framework APIs Sakai Velocity Support Layer The Sakai Legacy Environment Sakai Stand-Alone OKI OSIDs OKI OSID Legacy Covers Support For Velocity Tools

42. Login Branding Site Selection Tool Selection Tool Area Presence HTML Aggregator - Charon

43. Charon Portal Kernel Tool Registry Charon Tool ATool BTool C Sakai Sites Request Filter

44. Mercury

45. WSRP Activities SunGard-led and funded: Vishal Goenka Working with uPortal in their WSRP 3.0 effort As we really try to use WSRP, we identify issues in the standard and WSRP4J implementation Sakai and uPortal are becoming involved in WSRP standards activities and WSRP4J

46. Sakai tool HTTP WSRP Portal Sakai tool HTTP Sakai tool HTTP Non-Sakai Non-Java Tools tool WSRP Non-Sakai Tool WSRP WSRP Use Case

47. WSRP “Portal” Kernel Tool Registry Sakai WSRP Tool ATool BTool C Sakai Sites Request Filter Apache WSRP4J WSRP Consumer Portal Web Services WSRP Placements

48. WSRP Image

49. Visual Basic Portal Kernel Tool Registry Sites Web Service Tool ATool BTool C Sakai Sites Request Filter - Server - Site Tool + Site + Server

50. Visual Basic Portal - System X - Site Tool + Site + System Y Sakai X Sakai Y

51. QuickSakai: Apple Desktop

52. Many Portals.. Kernel Tool Registry Charon Tool ATool BTool C Browser Request Filter MercuryAstro ??WSRPWeb Svc Browser Desktop Portal Web Portal Browser Varuna Sedna Web Services

53. Ease of Expansion Including non-Java Tools

54. Sakai Goals (may conflict) A collaborative application –Reusable objects (Quiz Questions) across many tools –Component based - any component can be removed without harming the system Extremely easy to expand - reduce barriers to adding a new tool

55. Simpler Routes to New Tools May want to write in PHP, or some other language other than java May not want to comply with “Sakai” rules such as import/export, accessibility, or internationalization May just want very small distribution (I.e. not part of the Sakai release) Perhaps a very innovative early concept

56. IMS Tool Portability Group Focus is on making tools portable between systems (Sakai, WebCT, and Blackboard) Established to further the discussion with commercial and other CMS/CLE providers Uses web services and IFRAMES Does not require tools to be written in Java Working demonstration at the July 2005 Alt-I-lab with Samigo in Sakai, WebCT, and Blackboard

57. JVM Sakai Sakai APIs Samigo, ConceptTutor, Etc Sakai IMS Proxy Session And Services Bootstrap Sakai Web Services Application Code 1 2 3 4 5 6 7 Launch Outcome How IMS TI Works

58. Going Forward

59. Sakai 2.1 Expected December 1, 2005 Performance improvements and bug fixes Sections and Groups within a Site –Section Tool, Announcements, Gradebook, Samigo Provisional Tools –SU Tool, Roster Tool, Wiki, WSRP, TwinPeaks

60. Sakai 2.2 (best guess) Second Quarter 2006 Hierarchy Open Source Portfolio More tools Section Aware IMS Content Packaging Import and Export Provisional Tools (initial list) –Mail Tool, IU Discussion Tool, Melete, JSR-168 Portlet, IMS Tool Portability, Blog, JForums

61. Way Long Term Sakai / uPortal tightly integrated –JSR-168, WSRP Consumer, WSRP Producer JSR-170 - Java Content Repository IMS Common Cartridge All domain objects fully modeled with published Data models and RDF/OWL support

62. Summary / Questions Thank you for your time