1. Sakai Technical Overview Part II Charles Severance June 1, 2006 Download: www.dr-chuck.com/talks.php

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 class loader isolation Data interoperability and ability to expand Sakai without using Java Flexibility - Ease of Local Customization

3. Enterprise Production-Ready

4. 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)

5. 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)

6. Sakai in Production Text 20+ Full scale installations

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

8. Sakai in Production Text

9. High Level

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

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

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

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

14. 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}" />

15. 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)

16. Clear Abstraction Boundaries

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

18. 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” Aggregator Presentation Tools Services

19. Mercury

22. Apple Portal

23. VB Portal

24. Plex PLE

25. Upcoming Aggregators Cleaned up OSP Portal Hierarchy Portal - Astro Rumors and notions –Acetylene - Rumored RSF based portal –Iframe-free portal –PDA Aggregator –Better Desktop Portal Aggregator Presentation Tools Services

26. 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 Able to produce markup for multiple types of aggregators (Sakai, JSR-168, WSRP) 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,potentially under control of the end user Aggregator Presentation Tools Services

27. Presentation Technologies JSF –Current recommended solution because of setter/getter pattern and support for reusable GUI components –Challenging to work with Velocity –Legacy –Simple, but abstraction is weak on the request-side Struts –Legacy RSF –Emerging but still waiting for proof in all areas Aggregator Presentation Tools Services

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

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

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

31. Seamless Tool Integration

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

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

34. Resources Presentation Samigo Melete Anouncements Reuse in 2.1

35. Resources Presentation Samigo Melete Anouncements Reuse in 2.2 OSPortfolio

36. Resources Presentation Samigo Melete Anouncements Better Reuse OSPortfolio

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

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

39. HTML Sakai Entity APIs Existing Sakai Tools Legend Existing Sakai2.2 Work WebDav Web Sakai SOA APIs HTML Existing Sakai Tools Access perl php python.NET Sakai Services Search Service plone joomla External Sakai Entity APIs Import and Export SOAP

40. Sakai Search

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

42. Provisional Tools 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

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

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

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

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

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

48. Ease of Expansion Including non-Java Tools

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

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

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

52. 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 Uses web services and IFRAMES Roughly based on WebCT PowerLinks Does not require tools to be written in Java Currently in contrib space in Sakai

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

54. 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/

55. Hedrick Proxy

56. Going Forward We must “dramatically up our game” when it comes to support for data interoperability to allow external applications to fully participate in Sakai and work directly with Sakai’s data

57. HTML REST WebDav SOAP iCal SPARQL RSS CalDav Collaboration and Learning WebDav SOAP Collaboration and Learning Current Sakai Future Sakai Sakai “Swiss Army Knife”

58. HTML Sakai Object Bus Sakai Core Services Sakai Semantic Services New Semantic Tools Existing Sakai Services Existing Sakai Tools Legend Existing SakaiNew Work WebDav RSS REST SPARQL CalDav iCal SOAP Sakai SOA APIs Import and Export WebDav RSS REST SPARQL CalDav iCal SOAP Sakai Web 2.0

59. Local Configuration

60. 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 Role Provider User Provider Course/Site Provider

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

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

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

64. Many Skins… Text 20+ Full scale installations

65. Emerging Integration Points CourseManagement ContentHosting Plugin Calendar Plugin

66. Questions..