1. Sakai Technical Overview Charles Severance Download: www.dr-chuck.com/talks.php

2. Overview Video: http://www.dr-chuck.com/media.php?id=64 Sakai Overview Sakai is used for Collaboration, Teaching, and Learning Sakai Project started January 2004 Non-profit Sakai Foundation January 2006 Open Source - 100% free - Apache License Voluntary financial support from 100+ Higher Education organizations Six paid staff members Worldwide community with 100+ people active in developing and testing Sakai releases See www.sakaiproject.org

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

4. Enterprise Production-Ready

5. Sakai Enterprise Technologies Java 1.4 Oracle Apache - SSL, mod_jk, WEBISO, virtual hosting MySql 4.1 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. Sakai Tomcat 5.5 Spring Hibernate Java Server Faces Velocity (legacy)

6. Database Server IP Sprayer w/ Sticky Session Enterprise Scalability 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)

7. Sakai in Production Text 20+ Full scale installations

8. Sakai in Production 140 Sites in Production

9. Sakai in Production Text myUnisa: 1 Mar 2006 to 17 Mar 2006 Unique visitors: 72675 Number of visits: 169796 (2.33 visits/visitor) Pages: 10,086,589 Bandwidth: 66.13 GB (408.4 KB/visit)

10. Sakai in Production Text

11. High Level

12. Framework, Tools and Services 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

13. Component Based Expansion Take an empty Sakai system – Pick from the tool library – Include the appropriate services – 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 Service Library Customization Configuration Customization Configuration Tool Library

14. ToDo Presentation Persistence Browser ToDo Service Code My Monolithic ToDo List Servlet Browser Service Oriented Architecture Persistence Service Interface (i.e. API)

15. Fitting Into the Sakai Framework Framework Application SAF—Kernel SAF—Common Services Other Services ToDo Tool Code (Java) Service Interface (i.e. API) ToDo Service ToDo Tool Layout (JSP) SAF—Presentation Services Presentation Abstraction Browser

16. Sakai Presentation Services </sakai:button_bar> <sakai:date_input value="#{MyTool.date}" /> <h:inputText value="#{MyTool.userName}" /> <sakai:group_boxtitle="#{msgs.sample_one_groupbox}"> <sakai:instruction_message value="#{msgs.sample_one_instructions}" />

17. Web Services Framework Application ToDo Code ToDo Layout Presentation Framework WS Client Axis WS End Point Web Svcs Other Tools Layout Presentation Abstraction SAF—Kernel SAF—Common Services Other Services ToDo Service Service Interface (i.e. API)

18. Clear Abstraction Boundaries

19. Aggregator Presentation Tools Services Client System The Abstract Sakai Environment Abstract Architecture Sakai breaks its scope into distinct areas and builds strong abstractions between layers Goal is to be able to insert and remove implementations at any level without anyone noticing

20. Aggregator / Portal It assembles tools, buttons, tabs, etc and produces the final user interface The aggregator can completely transform the interface as it sees fit Receives and dispatches requests to tools after setting things like “context” Supports Sakai Tools as well as JSR- 168 portlets Aggregator Presentation Tools Services

23. Mercury

24. Apple Portal

25. VB Portal

26. Prototype of Sakai working in the Bodington Learning Management System

27. Plex PLE

28. Sakai and RSS Public/Anonymous or User-contextualized This can allow Sakai to be integrated into a wide range of applications including portals, browsers and desktop apps Feature added to Sakai 2.4 and will be back ported to Sakai 2.3

30. Sakai WorkGroup Portal Extend the Sakai “gateway” site which is displayed prior to log in to display more than one “site” Allows Sakai to be used as a simple Content Management System like Mambo or Plone Sakai Workgroup portal is released in Sakai 2.4 and will be back-ported to Sakai 2.3

31. Sakai Gateway Site

33. Use Cases for Sakai-168 Prepare a Pluto-style portlet war file and drop it into Sakai as a webapp - autoregister Users simply use Sakai’s Site Info tool to place portlets like any other Sakai tool It will be possible to use any Sakai API within a JSR-168 Portlet Sakai will provide a JSR-168 complaint classes so that portlets have the same look and feel as Sakai tools

34. Sakai Tool RequestFilter JSR-168 Tool PortletServlet Sakai Tool Registration Pluto Portlet Registration Sakai’s Aggregator Sakai Site Setup Pluto Container Sakai Tool Dispatch Pluto 1.1 Integrated into Sakai

35. JSR168 in Sakai

36. Upcoming Aggregators XSLT Based Portal Hierarchy Portal - Astro Rumors and notions –Acetylene - Rumored RSF based portal –iFrame-free portal –Better Desktop Portal Aggregator Presentation Tools Services

37. Presentation Layer Goals True abstraction between Presentation and Tools Tools should not be aware that they are in a web browser environment GUI Widget reusability Support multiple types of ultimate display devices (Browser, PDA, etc) Support internationalization and localization Be as flexible as possible - support CSS and allow transformability of the user interface, including under control of the end user Aggregator Presentation Tools Services

38. Presentation Technologies Java Server Faces - JSF –Current recommended solution because of setter/getter pattern and support for reusable GUI components –Challenging to work with Velocity –Simple, but abstraction is weak on the request-side Real Server Faces - RSF –Emerging as preferred approach with rich component reusability JSR-168 - Portlets –A well-established standard and simple to use –Suitable for simple tools –Portability between Sakai and other JSR-168 Portals Aggregator Presentation Tools Services

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}" /> JSF Patterns MyTool.processActionDoIt() { } Aggregator Presentation Tools Services

40. Tools and Services Tools –Written in Java and orchestrate the user interface –Have no persistence –Preferred pattern is Java object with getters and setters Services –Persistence –Business Objects –Business Logic Tools interact with services through published APIs Tools find the implementations of APIs at runtime using Spring and/or the ComponentManager Aggregator Presentation Tools Services

41. Finding Abstraction in your Tomcat tomcat/webapps/portal tomcat/webapps/mercury tomcat/webapps/osp-portal Aggregator Presentation Tools Services tomcat/webapp/sakai-user-tool tomcat/webapp/sakai-message-tool tomcat/shared/lib/site-api.jar tomcat/shared/lib/user-api.jar tomcat/components/sakai-authz-pack tomcat/components/sakai-user-pack

42. Sakai Tools

43. Many levels of Integration Want your website under a button in Sakai? Want your PHP app to know the current logged in Sakai User? Want build a self-contained that “cooperates” with Sakai? Full blown Sakai tool - released separately? An optional part of the Sakai release? A seamlessly integrated core part of the Sakai release? Integration with the rest of Sakai is just another aspect of any tool’s design. Tool writers choose how deeply their tool is to be integrated into Sakai. The community will likely value more highly integrated tools more.

44. Sakai Architecture Goals Two seemingly conflicting goals –Seamless integration across tools –Ability to expand Sakai without using Java In the short term, writing tools in Java and using Sakai framework elements directly is the path to seamless integration But in the long term, we must make 3P tools full peers in Sakai.

45. Resources Presentation Samigo Melete Anouncements Reuse in 2.1

46. Resources Presentation Samigo Melete Anouncements Reuse in 2.2 OSPortfolio

47. Resources Presentation Samigo Melete Anouncements Better Reuse OSPortfolio

48. Resources Presentation Samigo Melete Anouncements Flexibility in reuse Scorm Authoring OSPortfolio

49. Resources Presentation Samigo Melete Language Module Anouncements We are building a general way to do this…. Scorm Authoring OSPortfolio

50. Sakai Search

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

52. Tool

53. Moving Tools into the Sakai Release Should we include a tool in this release? –We needed something between “yes” and “no” Need to deeply involve the production users in the evaluation and testing of any new tool. Three stages –Contrib - Available - caveat emptor –Provisional - In the release, hidden, QA by developer team –Released - Full peer in terms of QA, etc. Increasing criteria as tools progress to encourage tools to meet Sakai’s tool architecture

54. Provisional Tool Criteria Community Support –Must have commit list and be in SVN –Must run in production at >=2 sites –Must have proper license –Must be willing to answer questions –Needs to be tracked in JIRA

55. Tool Criteria (cont) Technical –Support HSQL, MySql, Oracle –Use AutoDDL properly –Use sakai.properties –Do AUTHZ functions like the rest of Sakai –No patches to other elements –Must cluster –Use proper versions of Spring, Hibernate, etc.

56. Tool Criteria (cont.) Interaction and Visual Design –Inherit skins properly –Look “like” the rest of Sakai tools (fit in) –Follow interaction designs in style guide –Use JSF UI Components (if applicable) –Include help - properly added to the Sakai Help system QA test plans and specifications

57. Tool Criteria Desirable elements –Internationalized –Accessible (including a review) –Separation of persistence and business logic into a properly factored Sakai Component –Event generation as appropriate These are strongly suggested for full inclusion

58. *Sample* Attribute Matrix AnnounceMeleteJforumRwikiProfile AutoDDLYes PropertiesYes NoYes MySqlYes OracleYes No **Yes SkinnableYes NoYes ClusterYes??Yes ResourceYesNo YesNo I18NYes EventsYesNo

59. Ease of Expansion Including non-Java Tools

60. Sakai Architecture Goals Two seemingly conflicting goals –Seamless integration across tools –Ability to expand Sakai without using Java In the short term, writing tools in Java and using Sakai framework elements directly is the path to seamless integration But in the long term, we must make 3P tools full peers in Sakai.

61. IMS Tool Interoperability Focus is on making tools portable between systems (Sakai, WebCT, and Blackboard) Established to further the discussion with commercial and other CMS/CLE providers IMS Tool Interoperability Version 1.0 Uses web services and IFRAMES Roughly based on WebCT PowerLinks Does not require tools to be written in Java IMS Tool Interoperbility Version 2.0 Work is underway - hope to imitate PowerLinks Web Services

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

64. Sakai IMS TI Implementations Sakai Tool (Anthony) –Fully compliant –Multiple tools per placement –Rich persistence JSR-168 Portlet (Chuck) –Does not support Outcome Request –Users JSR-168 preferences as persistence –Portable between Sakai and Portals –Extensions IMS TI Lite - SOAP Lite Load Descriptor from URL

66. Tool Interoperability (REST) Several sites have written “proxy tools” –UNISA, Indiana, UM … As part of integrating CAPA and other tools at Rutgers - Chuck Hedrick has written one that is intended to be flexible, reusable and powerful Similar to IMS Tool Interoperability - but using REST approaches (I.e. easier) https://source.sakaiproject.org/contrib/rutgers/linktool/

67. Hedrick Proxy

68. Sakai Web Services 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

69. Web Services Framework Application ToDo Code ToDo Layout Presentation Framework WS Client Axis WS End Point Web Svcs Other Tools Layout Presentation Abstraction SAF—Kernel SAF—Common Services Other Services ToDo Service Service Interface (i.e. API)

70. Installation and Configuration

71. Installing Sakai Downloads –System Requirements –Documentation –Getting the Latest Source Code –Issue Tracking –Community –Getting Older Releases –License http://source.sakaiproject.org/release/2.3.1/

73. Providers in Sakai Sakai Velocity Tools Sakai JSF Tools Enterprise Data Sakai JSF Support Sakai Velocity Support Sakai Servlet Tools Sakai Framework Services Sakai Application Services Roster/Role Provider User Directory Provider Course/Site Provider https://source.sakaiproject.org/svn/providers/trunk/

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

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

76. Realm Provider (Group/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.

77. Emerging Integration Points CourseManagement ContentHosting Plugin Calendar Plugin

78. Developing a Skin for Sakai Documentation –https://source.sakaiproject.org/svn//referen ce/trunk/docs/architecture/sakai_skin.doc

79. Many Skins… Text 20+ Full scale installations

80. Developing for Sakai

81. Choices… Native Sakai Tool JSR-168 Portlet Integrate an Existing Tool

82. When to write a native tool When you want to be part of the Sakai release When you have a complex user interface and need to reuse UI Widgets When you want make use of other tools (we call these helpers) When you want to work closely with the rest of the system (like search)

83. When to write a JSR-168 Portlet? When your tool is pretty simple and has a simple user interface When your tool has simple persistence needs - particularly when you can use properties When the tool is self-contained and has potential reuse outside of Sakai

84. When to Integrate a tool? When you already have an established tool that is well-developed When you do not want to write in Java. When you want to keep your tool stand-alone as well as inside of Sakai When your tool has very low interaction with Sakai components other than user identity, user roles, and context (site/course)

85. Building a Sakai Tool Sakai Programmer’s Café http://bugs.sakaiproject.org/confluence/ display/BOOT/Home

86. Building a JSR-168 Portlet Download JSR-168 Specification –http://jcp.org/en/jsr/detail?id=168 Development Documentation –http://developers.sun.com/portalserver/reference/t echart/jsr168/ –http://portals.apache.org/pluto/v11/resources.html Portlets in Sakai –https://source.sakaiproject.org/contrib/portlets/trun k/ –https://source.sakaiproject.org/svn//reference/trunk /docs/architecture/sakai-168-portlet-tool.doc

87. Integrating a tool using IMS TI Documentation still in progress since this is a recent addition to Sakai –http://www.sakaiproject.org/imsti-test/ IMS Tool Interoperability Portlet –https://source.sakaiproject.org/contrib/portl ets/trunk/ TO DO: –Write IMS TI - Lite in PHP and Ruby

88. Discussion and Examples