Sakai Technical Overview Part II

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

5. Enterprise Scalability IP Sprayer w/ Sticky Session Hot Spare 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 File Server (opt) Database Server Hot Spare

6. Sakai in Production Text 20+ Full scale installations

7. Sakai in Production 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) Text

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 Tool Library • 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

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

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

14. Sakai Presentation Services <sakai:view_container title="#{msgs.sample_title}"> <sakai:tool_bar> <sakai:tool_bar_item/> </sakai:tool_bar> <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}" /> <sakai:button_bar> <sakai:button_bar_item action="#{MyTool.processActionDoIt} value="#{msgs.sample_one_cmd_go}" /> </sakai:button_bar>

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

16. Clear Abstraction Boundaries

17. Abstract Architecture Client The Abstract Sakai Environment Aggregator • 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 Presentation Tools Services System

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

19. Mercury

22. Apple Portal

23. VB Portal

24. Plex PLE

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

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

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

28. Aggregator Presentation Tools Services JSF Patterns <sakai:view_container title="#{msgs.sample_title}"> <sakai:tool_bar> <sakai:tool_bar_item/> </sakai:tool_bar> <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}" /> <sakai:button_bar> <sakai:button_bar_item action="#{MyTool.processActionDoIt} value="#{msgs.sample_one_cmd_go}" /> </sakai:button_bar> MyTool.processActionDoIt() { }

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

30. Aggregator Presentation Tools Services Finding Abstraction in your Tomcat tomcat/webapps/portal tomcat/webapps/mercury tomcat/webapps/osp-portal 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. Reuse in 2.1 Anouncements Presentation Resources Samigo Melete

35. Reuse in 2.2 Anouncements OSPortfolio Presentation Resources Samigo Melete

36. BetterReuse Anouncements OSPortfolio Presentation Resources Samigo Melete

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

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

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

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

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