Sakai Technical Overview Charles Severance Sakai Chief Architect

Sakai Technical Overview Charles Severance Sakai Chief Architect

Sakai Technical Overview Charles Severance Sakai Chief Architect November 7, 2005 The Ideal Sakai Deployment Take an empty Sakai system Choose a set of 10-15 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 Tool Library Sakai Framework 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 nonJava 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 API Service X Impl X Data Model Tool B

Y API Service Y Impl Y Data Model Tools can access Service APIs Services can access Service APIs We must be able to swap Service implementations Substituting Service Implementations Tool A

Tool B X API Service X WS Impl Y API Service Y Impl X Web Service Y Data Model 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. 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 Framework Sakai TPP Tool Sakai Service Sakai TPP Tool Sakai Service 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 The Sakai Framework Functionality Flow Sakai TPP Tool Sakai Service

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 Current Reuse in 2.0 Anouncements Presentation

Resources Samigo Melete Better Reuse Anouncements Presentation Resources Samigo

Melete Flexibility in reuse Anouncements Presentation Resources Samigo Melete Scorm Authoring

So you want to write a new tool? Anouncements Presentation Resources Samigo Language Module Melete 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 Tool Task DB

Task API Task API Impl. Task DB Presentation Public Abstraction Persistence, Business Logic, ORM, etc To fully integrate into Sakai Helper Task

Tool Other Tools Web Services Task API Internationalization Import/export Components Task API Impl. Sakai DB

AutoDDL Authorization Placement Sakai 2.0 Framework Sakai 2.0 Design Approach Significant re-factor of functionality SAF - Kernel Components/Spring Session, Tool registry, Identity

Support for Sakai tools, basic servlets, web services, and webdav Thread conditioning, Servlet filter Kernel enables the other services SAF - Services Primary support APIs which for tool interactions SAF - Presentation Services JSF, Velocity, Servlet Major goal: Clean support for servlets, web services, and webdav using the Kernel SAF Design Documents

Sakai Tool Model Sakai Sessions Sakai Request Flow Sakai Mercury Portal Sakai Use of Maven Sakai Configuration Sakai Charon Portal Sakai Component Model Sakai Authentication others These documents on collab.sakaiproject.org

Sakai Development SAF - Kernel Does not go above servlet level - provisions a Sakai servlet (and its thread) to fully operate Elements (6900 lines of code) Components - Interaction with Spring to register/retrieve the Sakai API implementations with class-loader isolation Session httpSession - shared Sakai-wide for user/login sakaiSession - shared Sakai-wide for user/login sakaiToolSession - scoped by user/login/placement Tool registry - including support for helpers Identity of current logged in user Utilities including thread local support SAF - Components It is like container-wide Spring components,

each with their own class loader In Sakai 1.0 and 1.5 we placed components in webapps to get the class loader isolation, but we ended up with load-order problems In Sakai 1.0 and 1.5 we bent Spring to orchestrate Sakai components In Sakai 2.0 components simply appear in Spring common/lib spring sakaiComponentManager tomcat/components component-1 WEB-INF components.xml classes lib

component-2 WEB-INF components.xml classes lib Each component looks like a webapp, but with no web.xml. Each has classes and its own lib. Their class loader uses common and shared. SAFComponents tomcat/webapps/app1 tomcat/webapps/app2

ComponentManager or Spring ComponentManager or Spring All globally registered components are available to Spring for injection (Interface names are the bean names) or via the Sakai ComponentManager API using Service Locator pattern. SAF-Components Benefits Separate class loaders for each component, and each webapp

Allows the jar footprint of one component not to be forced to overlap with all of the other components, tools, portal, etc. Multiple conflicting xerxes can be kept separate Adding/replacing a tool or component does not break things like the portal or other components Provides an EJB-like isolation but using Spring to connect components to client code SAF - Session Tomcat Sessions leave much to be desired Cross-context dispatch issues (fights between Pluto and Tomcat - changes between dot versions) Not well suited for Web Services or WebDav when browser is not involved Lifecycle issues - cant always count on cleanup Scope issues - Shared / Servlet / Portlet

Sakai sessions solve all of these problems SAF-Session Scenarios Cookie set via login or at SSO via WebISO Browser A Browser B Tool X1 Tool X2 Tool Y1

Tool Y2 Filter Basic Auth (Cookie opt) WS Auth Session ID WebDav Client WS or WSRP Client Filter

Filter WebDav Servlet Axis Servlet Renderer Servlet Re-dispatch Filter Tool X (Portlet) Filter Tool Y

(Servlet) Sakai APIs need logged in user, current session, etc. Web Services 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 Client Jakarta Axis WS End Point Web Services shipped in Sakai 2.0 Based on Axis 1.2 Release 2.0 includes sample PHP client Sakai Kernel Sakai APIs

Available in Sakai 2.0 Samples Only Sakai Web Services Endpoint import org.sakaiproject.api.kernel.session.Session; import org.sakaiproject.api.kernel.session.cover.SessionManager; public class SakaiSession { public String checkSession(String id) { System.out.println("session id="+id); Session s = SessionManager.getSession(id); if (s == null) { System.out.println("no session established"); return "Session Null"; } else { String resp = "session: " + s.getId()

+ " user id: " + s.getUserId() + " user enterprise id: " + s.getUserEid() + " inactive after: " + s.getMaxInactiveInterval(); System.out.println(resp); return resp; } } } Sakai Web Services Client require_once('SOAP/Client.php'); if ( ! $_POST['url'] ) $_POST['url'] = "http://nightly2.sakaiproject.org/sakai-axis/"; if ( $_POST['login'] ) { $site_url = $_POST['url'] . 'SakaiLogin.jws?wsdl'; echo ("Loggging in to Sakai Web Services at ".$site_url); $wsdl=new SOAP_WSDL($site_url); // Create an object directly from the proxy code

$myProxy=$wsdl->getProxy(); $session=$myProxy->login("admin","admin"); echo ("Session:"); print_r ($session ); $_POST['session'] = $session; } Flexible Presentation Abstract Architecture Presentation Support Aggregation The Abstract Sakai Environment To render a Sakai response, the tools, and

services work with other elements Client Aggregator Presentation Tools Services System External Aggregator

Writing a Tool The Sakai Tool Environment Presentation Support The Sakai Framework Each tool describes its presentation needs in a generic fashion - the framework provides mechanisms to render the tools 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 Internal Aggregator Sakai Tool Presentation Sakai Tool Code Application Services Framework Services System uPortal via

WSRP An Example The Sakai Tool Environment Sakai JSF Widget Set The Sakai Framework 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 HTML Based Aggregator GUI layout (JSF/JSP) Schedule Tool (Java) Schedule API (Java) OSID Id API System

Sakai iframe Portals via iframe Sakai Non iframe WSRP Renderer Servlet/HTML Renderer uPortal via JSR-168

JSR-168 Renderer Sakai JSF Widget Set The Sakai Tool Environment The Sakai Framework Portals via WSRP Java Server Faces in JSP Java Tool Logic Java Beans Sakai Application Services

Sakai and/or OKI APIs Rendering Flexibility Tool Display in JSF Describing Actions in JSF MyTool.userName() { } MyTool.date() { }

action="#{MyTool.processActionDoIt} value="#{msgs.sample_one_cmd_go}" /> MyTool.processActionDoIt() { } Sakai Stand-Alone Support For Velocity Tools uPortal via iframe HTML Based

Aggregator Sakai JSF Widget Set Velocity Templates Sakai Legacy Tools Sakai Legacy Services Sakai Framework APIs OKI OSID Legacy Covers Hibernate

The Sakai Tool Environment The Sakai Legacy Environment The Sakai Framework Sakai Velocity Support Layer Java Server Faces in JSP Java Tool Logic Java Beans Sakai Application Services OKI OSIDs HTML Aggregator - Charon

Login Branding Site Selection Tool Selection Tool Area Presence Charon Portal Sakai Sites Charon Kernel Tool Registry

Request Filter Tool A Tool B Tool C Mercury 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 WSRP Use

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

P WSR HTTP HTTP tool WSRP tool tool Sakai HTTP

tool tool Sakai tool WSRP Portal WSRP Consumer Portal Apache WSRP4J WSRP Placements

Sakai WSRP Sakai Sites Kernel Tool Registry Request Filter Tool A Web Services Tool B Tool C WSRP Image

Visual Basic Portal - Server - Site Tool Tool + Site + Server Sakai Sites Sites Web Service Kernel Tool Registry Request Filter Tool A

Tool B Tool C Visual Basic Portal - System X - Site Tool Tool + Site + System Y Sakai X Sakai

Y QuickSakai: Apple Desktop Many Portals.. Browser Sedna Charon Mercury Astro ?? Browser Browser

Web Portal Desktop Portal WSRP Web Svc Varuna Kernel Tool Registry Request Filter Tool A Web Services

Tool B Tool C Ease of Expansion Including non-Java Tools 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 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 How IMS TI Works 1 6 7 Sakai Web Services Sakai

Outcome 5 Sakai IMS Proxy Sakai APIs 4 Launch 2 Application Code Session And Services

Bootstrap 3 Samigo, ConceptTutor, Etc JVM 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-170 - 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

Recently Viewed Presentations

  • Helium Charge Exchange Recombination Spectroscopy on Alcator C-Mod

    Helium Charge Exchange Recombination Spectroscopy on Alcator C-Mod

    TEM and ITG transport impurities in opposite directions. Shot Database. Helium CXRS on Alcator C-Mod Tokamak /40. Turbulent Transport. Transport. 1179 time points from 123 shots. ... At low minority fraction, standing wave pattern independent of minority profile, and local...
  • Trust But Verify How can a community learn

    Trust But Verify How can a community learn

    Trust But Verify How can a community learn the facts about the pipelines that run through them? What do the facts mean? Why would communities want information?
  • Chapter 7: Animal Biotechnology

    Chapter 7: Animal Biotechnology

    Chapter 7 Animal Biotechnology ... Dogs (lungs and cardiovascular system) Cats Pigs (PPL Therapeutics- delete a gene which causes hyperacute rejection of pig-to-human organ transplantation) Primates (HIV and AIDs research, geriatric research) Animals in Research Alternatives to Animal Models ...
  • CSE490i Advanced Internet Systems

    CSE490i Advanced Internet Systems

    Five Key Requirements Standard way to represent data XML Common, extensible, message format SOAP Common, extensible, service description language WSDL Way to discover services on a particular Web site DISCO A way to discover service providers UDDI What Is XML?...
  • Powerpoint Slides for the Standard Version of Starting Out ...

    Powerpoint Slides for the Standard Version of Starting Out ...

    Standard Version of Starting Out with C++, 4th Edition ... i < SIZE;i++) cout << tests[i] << endl; Global vs. Local Array Global array all elements initialized to 0 Local array all elements uninitialized by default 7.3 No Bounds Checking...
  • Isotope Hydrology: CFC, SF6 dating Peter Schlosser, February

    Isotope Hydrology: CFC, SF6 dating Peter Schlosser, February

    In the early literature, CFC 11 and CFC 12 were also called chlorofluoromethanes due to their methane-type structure. The trade name of CFCs (DuPond) is Freon (F 11, F 12, F 113). The main use of CFCs is summarized in...
  • Astro 25 - Spring 2017 - Cabrillo College

    Astro 25 - Spring 2017 - Cabrillo College

    "This remote monument, traversed by the San Andreas Fault which has carved valleys, created and moved mountains, and yet up close, is seen in subtle alignment of ridges, ravines and normally dry ponds. Prominent features on the monument include the...
  • CHAPTER OUTLINE Benefits of Skill -Related Fitnes s

    CHAPTER OUTLINE Benefits of Skill -Related Fitnes s

    Specific Exercise Considerations: Heat Cramps Specific Exercise Considerations: Heat Exhaustion Specific Exercise Considerations: Heat Stroke Specific Exercise Considerations: Heat Stroke Specific Exercise Considerations: Heat Stroke Exercise-Related Injuries The four most common causes of injuries High-impact activities Rapid conditioning ...