Sakai Technical Overview Charles Severance Sakai Chief Architect December 1,

The Ideal Sakai Deployment Take an empty Sakai system –Choose a set of tools for your needs –Choose a set of Services (web services, etc) –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 Sakai Tool Library Sakai Service Library Local Customization

Sakai Goals Component based expandability Appearance of a single well-integrated application Flexible Presentation (HTML, Portals) Support for Web Services Flexibility in Expansion including non- Java Production-ready

Framework, Tools and Services Tools –Cannot do any type of persistence –Responsible for presentation (GUI) Services –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

Component Based Expansion

Sakai Service Rules Tool A X Data Model X API Service X Impl Tool B Y Data Model Y API Service Y Impl Tools can access Service APIs Services can access Service APIs We must be able to swap Service implementations

Substituting Service Implementations Tool A X API Service X WS Impl Tool B Y Data Model Y API Service Y Impl If a deployment chooses to implement Service X is using web services, there is no data model and any implementation-X specific access is no longer available. X Web Service

The Sakai Framework Sakai Service Sakai Service Sakai TPP Tool Sakai TPP Tool Sakai Framework Registration of tools and services Provides portability between environments where possible –HTML / Web Services Framework includes presentation elements as well to support tools

The Sakai Framework Sakai Service Sakai TPP Tool Functionality Flow Goal: no replication of code Code trends toward the broadest and most reusable are of the system –Framework –Service –Tools As long as it does not break the “rules” Sakai TPP Tool Sakai Service

Goal: Appear as Single Integrated Application

Why Build A Sakai Tool? Want your website under a button in Sakai? Want your PHP app to know the current logged in Sakai User? Want a servlet “in Sakai” but with a minimum of rework? Full blown Sakai tool - released separately? An optional part of the Sakai release? A core part of the Sakai release?

Sakai Goals (may conflict) A collaborative application –Reusable objects (Quiz Questions) across many tools –Component based - any component can be removed without harming the system Extremely easy to expand - reduce barriers to adding a new tool

Resources Presentation Samigo Melete Anouncements Current Reuse in 2.0

Resources Presentation Samigo Melete Anouncements Better Reuse

Resources Presentation Samigo Melete Anouncements Flexibility in reuse Scorm Authoring

Resources Presentation Samigo Melete Language Module Anouncements So you want to write a new tool? Scorm Authoring

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

Two Layer Architecture Task Tool Task API Task API Impl. Task DB Task Tool Task DB Presentation Public Abstraction Persistence, Business Logic, ORM, etc…

To fully integrate into “Sakai Task Tool Task API Task API Impl. Placement Import/export Components Authorization Other Tools Web Services Sakai DB AutoDDL Helper Internationalization

Flexible Presentation

Aggregator Presentation Tools Services Client System The Abstract Sakai Environment Abstract Architecture To render a Sakai response, the tools, and services work with other elements –Presentation Support –Aggregation

The Sakai Framework Internal Aggregator Sakai Tool Presentation Sakai Tool Code Application Services Framework Services Presentation Support The Sakai Tool Environment External Aggregator System Writing a Tool Each tool describes its presentation needs in a generic fashion - the framework provides mechanisms to render the tool’s presentation The tool is unaware of any aggregation or final presentation Tools may produce “application” services related to the tools (chat tool / chat service) A service built for a particular tool should still operate through an API and be available to other tools

The Sakai Framework HTML Based Aggregator GUI layout (JSF/JSP) Schedule Tool (Java) Schedule API (Java) OSID Id API Sakai JSF Widget Set The Sakai Tool Environment uPortal via WSRP System An Example This is a tool written using the Sakai JSF widget set The tool builds its own API (Schedule) The tool makes use of framework APIs. The tool is rendered in HTML and displayed within uPortal via the Web Services for Remote Portlets (WSRP) protocol Outside the tool, there is great flexibility which is hidden to the tool

The Sakai Framework Servlet/HTML Renderer Java Server Faces in JSP Java Tool Logic Java Beans Sakai Application Services Sakai JSF Widget Set The Sakai Tool Environment Portals via iframe Sakai and/or OKI APIs Sakai iframe WSRP Renderer Sakai Non iframe Portals via WSRP JSR-168 Renderer uPortal via JSR-168 Rendering Flexibility

<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}" /> Tool Display in JSF

<h:inputText value="#{MyTool.userName}" /> <sakai:date_input value="#{MyTool.date}" /> MyTool.userName() { } MyTool.date() { } MyTool.processActionDoIt() { } Describing Actions in JSF

The Sakai Framework HTML Based Aggregator Java Server Faces in JSP Java Tool Logic Java Beans Sakai Application Services Hibernate Sakai JSF Widget Set The Sakai Tool Environment uPortal via iframe Velocity Templates Sakai Legacy Tools Sakai Legacy Services Sakai Framework APIs Sakai Velocity Support Layer The Sakai Legacy Environment Sakai Stand-Alone OKI OSIDs OKI OSID Legacy Covers Support For Velocity Tools

Login Branding Site Selection Tool Selection Tool Area Presence HTML Aggregator - Charon

Charon - Rendering Subsets

Charon Portal Kernel Tool Registry Charon Tool ATool BTool C Sakai Sites Request Filter

Mercury

Mercury Portal Kernel Tool Registry Mercury Tool ATool BTool C User’s Browser Request Filter

Sakai Portal Integration Steps Use iFrames and Charon –Highly Portable - manual configuration - separate rendering Sakai JSR-168 Web Service Portlet –Highly portable - automatic configuration - separate rendering Web Services for Remote Portlets (WSRP) –Highly portable - manual configuration - coordinated rendering Sakai integrated into uPortal 3.0 –Not portable - automatic configuration - coordinated rendering

Sakai Portlet JSR-168 Portlet iFrame

How it Works uPortal, Pluto, or GridSphere Sakai Web Svcs Charon Portal Sakai Portlet Login SiteList

uPortal Thanks to Marcus Christie, Indiana University for the uPortal screen shot

GridSphere Thanks to Marcus Christie, Indiana University for the GridSphere screen shot

WSRP Activities SunGard-led and funded: Vishal Goenka Working with uPortal in their WSRP 3.0 effort As we really try to use WSRP, we identify issues in the standard and WSRP4J implementation Sakai and uPortal are becoming involved in WSRP standards activities and WSRP4J

Sakai tool HTTP WSRP Portal Sakai tool HTTP Sakai tool HTTP Non-Sakai Non-Java Tools tool WSRP Non-Sakai Tool WSRP WSRP Use Case

WSRP “Portal” Kernel Tool Registry Sakai WSRP Tool ATool BTool C Sakai Sites Request Filter Apache WSRP4J WSRP Consumer Portal Web Services WSRP Placements

WSRP Image

The Sakai Framework Servlet/HTML Renderer Java Server Faces in JSP Java Tool Logic Java Beans Sakai Application Services Sakai JSF Widget Set The Sakai Tool Environment Portals via iframe Sakai and/or OKI APIs Sakai iframe WSRP Renderer Sakai Non iframe Portals via WSRP JSR-168 Renderer uPortal via JSR-168 Rendering Flexibility

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 Web Services shipped in Sakai 2.0 Based on Axis 1.2 Release 2.0 includes sample PHP client Web Services Client Jakarta Axis Sakai APIs Sakai Kernel WS End Point Samples Only Available in Sakai 2.0

Ease of Expansion Including non-Java Tools

Why Build A Sakai Tool? Want your website under a button in Sakai? Want your PHP app to know the current logged in Sakai User? Want a servlet “in Sakai” but with a minimum of rework? Full blown Sakai tool - released separately? An optional part of the Sakai release? A core part of the Sakai release? (Review)

Sakai Goals (may conflict) A collaborative application –Reusable objects (Quiz Questions) across many tools –Component based - any component can be removed without harming the system Extremely easy to expand - reduce barriers to adding a new tool

Simpler Routes to New Tools May want to write in PHP, or some other language other than java May not want to comply with “Sakai” rules such as import/export, accessibility, or internationalization May just want very small distribution (I.e. not part of the Sakai release) Perhaps a very innovative early concept

JVM The Sakai Framework HTTML Based Aggregator Java Server Faces in JSP Java Tool Logic Java Beans Sakai Application Services Sakai JSF Widget Set The Sakai Tool Environment uPortal via iframe Sakai/OKI APIs Sakai Stand-Alone Java Tool Logic Application Services Non-Sakai Web Application Presentation Sakai Commponents Sakai Request Filter Integrating A Servlet

Java Tool Logic Presentation AUTHN Provider AUTHZ Provider Group Provider Storage Group Provider Application Services Java Tool Logic Presentation Sakai Components Sakai Request Filter AUTHN Provider AUTHZ Provider Group Provider Storage Group Provider Application Services Group Provider Group Provider Web Application Container (Tomcat) Stand Alone OperationOperating Within Sakai

Current Servlet Integration Samigo and Gradebook - Hybrid JSF Spring MVC - OSP 2.0 Struts - UNISA These are not long term approaches and gently discouraged in releases

IMS Tool Portability Group 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 Does not require tools to be written in Java Working demonstration at the July 2005 Alt-I-lab with Samigo in Sakai, WebCT, and Blackboard Will be released as part of Sakai 2.1

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

Local Configuration

Providers in Sakai Sakai Velocity Tools Sakai JSF Tools Enterprise Data Sakai JSF Support Sakai Velocity Support Sakai Servlet Tools Sakai Kernel and RequestFilter Sakai Common Services 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.

Production Configurations

Important Production Choices Operating System –Linux (*), Solaris, X/Serve, AIX, Windows Data Base –Oracle (*), MySql, HSQL Configuration –One System –Separate DB Server –Clustered application servers (*)

Deployment Configurations Developer/Demo - Hypersonic SQL MySql –Medium sized systems Oracle –Large systems Clustered –Multiple application servers

Developer WorkStation Sakai HSQL Database Developer Environment HSQL database –In memory –On file Easy to use/configure HSQL is Open Source so it can be included with Sakai’s distribution Sometimes runs “too fast” because it is in memory

Server Sakai MySql Database Small/Medium Production System MySql database Application and database can be on same server Placing on same server simplifies some performance tuning Pair of fast 2-CPU systems or one 4-CPU system should support 200+ simultaneous users Database Server Application Server Sakai MySql Database

Server Sakai Oracle Database Sakai Application Server Cluster IP Sprayer Large Production Environment

Going Forward

Sakai 2.1 Expected December 1, 2005 Performance improvements and bug fixes Sections and Groups within a Site –Section Tool, Announcements, Gradebook, Samigo Provisional Tools –SU Tool, Roster Tool, Wiki, WSRP, TwinPeaks

Sakai 2.2 (best guess) Second Quarter 2006 Hierarchy Open Source Portfolio More tools Section Aware IMS Content Packaging Import and Export Provisional Tools (initial list) –Mail Tool, IU Discussion Tool, Melete, JSR-168 Portlet, IMS Tool Portability, Blog, JForums

Way Long Term Sakai / uPortal tightly integrated –JSR-168, WSRP Consumer, WSRP Producer JSR Java Content Repository IMS Common Cartridge All domain objects fully modeled with published Data models and RDF/OWL support

Summary / Questions Thank you for your time