1 / 66

Sakai Technical Overview Part II - Achieving Enterprise Production-Ready Goals

Learn about Sakai's technical goals for enterprise production-readiness, including seamless integration, component-based expandability, and flexibility through local customization. Discover the high-level framework, tools, and services, along with Sakai's system aggregator and presentation layer goals.

lmidgley
Download Presentation

Sakai Technical Overview Part II - Achieving Enterprise Production-Ready Goals

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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

  20. Apple Portal

  21. VB Portal

  22. Plex PLE

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

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

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

  26. 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() { }

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

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

  29. Seamless Tool Integration

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

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

  32. Reuse in 2.1 Anouncements Presentation Resources Samigo Melete

  33. Reuse in 2.2 Anouncements OSPortfolio Presentation Resources Samigo Melete

  34. BetterReuse Anouncements OSPortfolio Presentation Resources Samigo Melete

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

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

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

  38. Sakai Search

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

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

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

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

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

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

  45. *Sample* Attribute Matrix

  46. Ease of Expansion Including non-Java Tools

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

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

More Related