Sakai Technical Overview Aaron Zeckoski From original slides by Chuck Severance and Ian Boston Creative Commons Attribution- NonCommercial-ShareAlike 2.5 License Sakai Programmer's Café Sakai Montreal CRIM Workshop

Technical Goals

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

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

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

High Level

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

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

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

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 Fitting Into the Sakai Framework

</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}" /> JSF Sakai Presentation Services

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)

Clear Abstraction Boundaries

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

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

Apple Portal

VB Portal

Plex PLE

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

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 Presentation Layer Goals

RSF –Becoming the recommended solution –Emerging and still waiting for proof in all areas JSF –Previously/Currently recommended solution –setter/getter pattern and support for reusable GUI components –Very challenging to work with and not flexible enough JSP –Ease of use, considered dated, only used in 1-2 tools Velocity –Legacy tools written in this –Simple, but abstraction is weak on the request-side Struts –Legacy Aggregator Presentation Tools Services Presentation Layer Goals

<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

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

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 Finding Abstraction in your Tomcat

Seamless Tool Integration

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.

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.

Resources Presentation Samigo Melete Anouncements Reuse in 2.1

Resources Presentation Samigo Melete Anouncements Reuse in 2.2 OSPortfolio

Resources Presentation Samigo Melete Anouncements Better Reuse OSPortfolio

Resources Presentation Samigo Melete Anouncements Flexibility in reuse Scorm Authoring OSPortfolio

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

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

Sakai Search

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

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

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

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.

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

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

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

Ease of Expansion Including non-Java Tools

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. Sakai Architecture Goals

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

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)

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

JVM Sakai Sakai APIs Samigo, ConceptTutor, Etc Sakai IMS Proxy Session And Services Bootstrap IMS TI Outcome Request Application Code Launch Outcome How IMS TI Works

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)

Hedrick Proxy

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

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

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

Local Configuration

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

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

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

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.

Emerging Integration Points CourseManagement ContentHosting Plugin Calendar Plugin

Questions..