Sakai Technical Overview Aaron Zeckoski azeckoskigmail com From

Sakai Technical Overview Aaron Zeckoski (azeckoski@gmail. com) From original slides by Chuck Severance and Ian Boston Sakai Montreal CRIM Workshop Creative Commons Attribution. Non. Commercial-Share. Alike 2. 5 License Sakai Programmer's Café

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 Java 1. 5 Apache - SSL, mod_jk, WEBISO, virtual hosting Sakai Tomcat 5. 5 Spring Hibernate Java Server Faces Velocity (legacy) RSF My. Sql 4. 1 Oracle • 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.

Enterprise Scalability Hardware or Software UM = Net. Scaler IU = Software IP Sprayer w/ Sticky Session Hot Spare App servers with identical software loads. UM = Sun. Fire V 480, Quad 900 MHz CPU, 20 GB RAM, 4 Stor. Edge 3310 SCSI RAID Arrays w/ 12 73 Gb disks (Oracle) Hot Spare Database Server App Server UM = 8 X Dell Power. Edge 2650, dual 2. 4 -3. 2 GHz CPU, 4 GB RAM File Server (optional) IU = Net. App File Server (opt) Database Server Hot Spare

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 Tool Library Sakai Framework Service Library Customization Configuration

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

Fitting Into the Sakai Framework SAF—Presentation Services Browser Presentation Abstraction To. Do Tool Layout (JSP) Framework To. Do Tool Code (Java) Service Interface (i. e. API) Application Other Services SAF—Common Services SAF—Kernel To. Do Service

Sakai Presentation Services <sakai: view_container title="#{msgs. sample_title}"> <sakai: tool_bar_item/> </sakai: tool_bar> <sakai: instruction_message value="#{msgs. sample_one_instructions}" /> <sakai: group_box title="#{msgs. sample_one_groupbox}"> <h: input. Text value="#{My. Tool. user. Name}" /> <sakai: date_input value="#{My. Tool. date}" /> <sakai: button_bar_item action="#{My. Tool. process. Action. Do. It} value="#{msgs. sample_one_cmd_go}" /> </sakai: button_bar> JSF

Web Services WS Client Presentation Framework Presentation Abstraction Web Svcs Axis Layout To. Do Layout Framework WS End Point Other Tools To. Do Code Application Other Services SAF—Common Services SAF—Kernel To. Do Service Interface (i. e. API)

Clear Abstraction Boundaries

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

Aggregator / Portal Presentation Tools • 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” Services

Apple Portal

VB Portal

Plex PLE

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

Presentation Layer Goals Aggregator Presentation • True abstraction between Presentation and Tools • Tools should not be aware that they are in a web browser Services 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

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

JSF Patterns Aggregator Presentation <sakai: view_container title="#{msgs. sample_title}"> Tools <sakai: tool_bar> <sakai: tool_bar_item/> </sakai: tool_bar> Services <sakai: instruction_message value="#{msgs. sample_one_instructions}" /> <sakai: group_box title="#{msgs. sample_one_groupbox}"> <h: input. Text value="#{My. Tool. user. Name}" /> <sakai: button_bar_item action="#{My. Tool. process. Action. Do. It} value="#{msgs. sample_one_cmd_go}" /> </sakai: button_bar> <sakai: date_input value="#{My. Tool. date}" /> My. Tool. process. Action. Do. It() { }

Aggregator Tools and Services Presentation Tools • 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 Component. Manager Services

Finding Abstraction in your Tomcat Aggregator tomcat/webapps/portal tomcat/webapps/mercury tomcat/webapps/osp-portal Presentation tomcat/webapp/sakai-user-tool tomcat/webapp/sakai-message-tool Tools tomcat/shared/lib/site-api. jar tomcat/shared/lib/user-api. jar Services tomcat/components/sakai-authz-pack tomcat/components/sakai-user-pack

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 3 P tools full peers in Sakai.

Reuse in 2. 1 Anouncements Presentation Resources Samigo Melete

Reuse in 2. 2 Anouncements OSPortfolio Presentation Resources Samigo Melete

Better Reuse Anouncements OSPortfolio Presentation Resources Samigo Melete

Flexibility in reuse Anouncements OSPortfolio Presentation Resources Samigo Melete Scorm Authoring

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

HTML Sakai Entity APIs Existing Sakai Tools plone perl Sakai SOA APIs Search Service SOAP Web Sakai Services python Web. Dav Access Sakai Entity APIs Existing Sakai 2. 2 Work . NET joomla Import and Export Legend php External

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, My. Sql, Oracle Use Auto. DDL 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 Announce Melete Jforum Rwiki Profile Auto. DDL Yes Yes Yes Properties Yes No Yes My. Sql Yes Yes Yes Oracle Yes No ** Yes Skinnable Yes No Yes Cluster Yes ? ? Yes Yes Resource Yes No No Yes No I 18 N Yes Yes Yes Events Yes No No Yes No

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 3 P tools full peers in 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 WS Client Presentation Framework Presentation Abstraction Web Svcs Axis Layout To. Do Layout Framework WS End Point Other Tools To. Do Code Application Other Services SAF—Common Services SAF—Kernel To. Do Service Interface (i. e. API)

IMS Tool Interoperability • Focus is on making tools portable between systems (Sakai, Web. CT, and Blackboard) • Established to further the discussion with commercial and other CMS/CLE providers • Uses web services and IFRAMES • Roughly based on Web. CT Power. Links • Does not require tools to be written in Java • Currently in contrib space in Sakai

How IMS TI Works 1 6 7 IMS TI Outcome Request Sakai Outcome 5 Sakai IMS Proxy Sakai APIs 4 Launch 2 Application Code Session And Services Bootstrap 3 Samigo, Concept. Tutor, Etc JVM

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) • https: //source. sakaiproject. org/contrib/rutgers/linktool/

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

Web. Dav Current Sakai HTML Collaboration and Learning S SOAP al Collaboration and Learning l. D av i. C SOAP Ca REST HTML Sakai “Swiss Army Knife” S S R Web. Dav PA RQ Future Sakai L

HTML SOAP New Semantic Tools Existing Sakai Tools Cal. Dav Sakai SOA APIs i. Cal SPARQL Sakai Semantic Services Sakai Core Services Existing Sakai SPARQL REST Web. Dav Import and Export Legend Cal. Dav RSS Sakai Object Bus Web. Dav SOAP i. Cal REST RSS Sakai Web 2. 0 New Work

Local Configuration

Sakai Velocity Support Sakai JSF Support Sakai Velocity Tools Sakai JSF Tools Providers in Sakai Servlet Tools Sakai Application Services Sakai Framework Services Role Provider Course/Site Provider Enterprise Data User 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, Open. LDAP, 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 • Course. Management • Content. Hosting Plugin • Calendar Plugin

Questions. .