Sakai Technical Overview Charles Severance Download:

Overview Video: Sakai Overview Sakai is used for Collaboration, Teaching, and Learning Sakai Project started January 2004 Non-profit Sakai Foundation January 2006 Open Source - 100% free - Apache License Voluntary financial support from 100+ Higher Education organizations Six paid staff members Worldwide community with 100+ people active in developing and testing Sakai releases See

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

Enterprise Production-Ready

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

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)

Sakai in Production Text 20+ Full scale installations

Sakai in Production 140 Sites in Production

Sakai in Production Text myUnisa: 1 Mar 2006 to 17 Mar 2006 Unique visitors: Number of visits: (2.33 visits/visitor) Pages: 10,086,589 Bandwidth: GB (408.4 KB/visit)

Sakai in Production Text

High Level

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

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 Service Oriented Architecture Persistence Service Interface (i.e. API)

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

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

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 Abstract Architecture 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

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” Supports Sakai Tools as well as JSR- 168 portlets Aggregator Presentation Tools Services

Mercury

Apple Portal

VB Portal

Prototype of Sakai working in the Bodington Learning Management System

Plex PLE

Sakai and RSS Public/Anonymous or User-contextualized This can allow Sakai to be integrated into a wide range of applications including portals, browsers and desktop apps Feature added to Sakai 2.4 and will be back ported to Sakai 2.3

Sakai WorkGroup Portal Extend the Sakai “gateway” site which is displayed prior to log in to display more than one “site” Allows Sakai to be used as a simple Content Management System like Mambo or Plone Sakai Workgroup portal is released in Sakai 2.4 and will be back-ported to Sakai 2.3

Sakai Gateway Site

Use Cases for Sakai-168 Prepare a Pluto-style portlet war file and drop it into Sakai as a webapp - autoregister Users simply use Sakai’s Site Info tool to place portlets like any other Sakai tool It will be possible to use any Sakai API within a JSR-168 Portlet Sakai will provide a JSR-168 complaint classes so that portlets have the same look and feel as Sakai tools

Sakai Tool RequestFilter JSR-168 Tool PortletServlet Sakai Tool Registration Pluto Portlet Registration Sakai’s Aggregator Sakai Site Setup Pluto Container Sakai Tool Dispatch Pluto 1.1 Integrated into Sakai

JSR168 in Sakai

Upcoming Aggregators XSLT Based Portal Hierarchy Portal - Astro Rumors and notions –Acetylene - Rumored RSF based portal –iFrame-free portal –Better Desktop Portal 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 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, including under control of the end user Aggregator Presentation Tools Services

Presentation Technologies Java Server Faces - JSF –Current recommended solution because of setter/getter pattern and support for reusable GUI components –Challenging to work with Velocity –Simple, but abstraction is weak on the request-side Real Server Faces - RSF –Emerging as preferred approach with rich component reusability JSR Portlets –A well-established standard and simple to use –Suitable for simple tools –Portability between Sakai and other JSR-168 Portals Aggregator Presentation Tools Services

<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

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

Sakai Tools

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

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

Tool

Moving Tools into the Sakai Release 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

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

Ease of Expansion Including non-Java Tools

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.

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 IMS Tool Interoperability Version 1.0 Uses web services and IFRAMES Roughly based on WebCT PowerLinks Does not require tools to be written in Java IMS Tool Interoperbility Version 2.0 Work is underway - hope to imitate PowerLinks Web Services

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

Sakai IMS TI Implementations Sakai Tool (Anthony) –Fully compliant –Multiple tools per placement –Rich persistence JSR-168 Portlet (Chuck) –Does not support Outcome Request –Users JSR-168 preferences as persistence –Portable between Sakai and Portals –Extensions IMS TI Lite - SOAP Lite Load Descriptor from URL

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

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

Installation and Configuration

Installing Sakai Downloads –System Requirements –Documentation –Getting the Latest Source Code –Issue Tracking –Community –Getting Older Releases –License

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 Roster/Role Provider User Directory 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 (Group/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

Developing a Skin for Sakai Documentation – ce/trunk/docs/architecture/sakai_skin.doc

Many Skins… Text 20+ Full scale installations

Developing for Sakai

Choices… Native Sakai Tool JSR-168 Portlet Integrate an Existing Tool

When to write a native tool When you want to be part of the Sakai release When you have a complex user interface and need to reuse UI Widgets When you want make use of other tools (we call these helpers) When you want to work closely with the rest of the system (like search)

When to write a JSR-168 Portlet? When your tool is pretty simple and has a simple user interface When your tool has simple persistence needs - particularly when you can use properties When the tool is self-contained and has potential reuse outside of Sakai

When to Integrate a tool? When you already have an established tool that is well-developed When you do not want to write in Java. When you want to keep your tool stand-alone as well as inside of Sakai When your tool has very low interaction with Sakai components other than user identity, user roles, and context (site/course)

Building a Sakai Tool Sakai Programmer’s Café display/BOOT/Home

Building a JSR-168 Portlet Download JSR-168 Specification – Development Documentation – echart/jsr168/ – Portlets in Sakai – k/ – /docs/architecture/sakai-168-portlet-tool.doc

Integrating a tool using IMS TI Documentation still in progress since this is a recent addition to Sakai – IMS Tool Interoperability Portlet – ets/trunk/ TO DO: –Write IMS TI - Lite in PHP and Ruby

Discussion and Examples