sakai technical overview charles severance download:
Post on 21-Dec-2015
230 views
TRANSCRIPT
Overview Video: http://www.dr-chuck.com/media.php?id=64
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 www.sakaiproject.org
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 TechnologiesJava1.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.
SakaiTomcat 5.5
SpringHibernate
Java Server FacesVelocity (legacy)
DatabaseServer
IP Sprayer w/Sticky Session
Enterprise ScalabilityHardware or SoftwareUM = NetScaler IU = Software
App servers with identical software loads.UM = 8X Dell PowerEdge 2650, dual 2.4-3.2 GHz CPU, 4 GB RAM
Database ServerUM = SunFire V480, Quad 900 MHz CPU, 20GB RAM, 4 StorEdge 3310 SCSI RAID Arrays w/ 12 73Gb disks (Oracle)
File Server (optional)IU = NetApp
Ap
p S
erv
er
Hot Spare
Hot Spare
Hot S
pare
FileServer(opt)
Sakai in Production
Text
myUnisa: 1 Mar 2006 to 17 Mar 2006Unique visitors: 72675Number of visits: 169796 (2.33 visits/visitor)Pages: 10,086,589Bandwidth: 66.13 GB (408.4 KB/visit)
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
SakaiFramework
ServiceLibrary
Customization
Configuration
Customization
Configuration
ToolLibrary
ToDoPresentation
Persistence
Browser
ToDo ServiceCode
MyMonolithicToDo ListServlet
Browser
Service Oriented Architecture
Persistence
ServiceInterface(i.e. API)
Fitting Into the Sakai Framework
Framework
Application
SAF—Kernel
SAF—Common Services
Other Services
ToDo Tool Code (Java)
ServiceInterface (i.e. API)
ToDo Service
ToDo Tool Layout (JSP)
SAF—Presentation Services
PresentationAbstraction
Browser
Sakai Presentation Services
<sakai:button_bar><sakai:button_bar><sakai:button_bar_item<sakai:button_bar_itemaction="#{MyTool.processActionDoIt}action="#{MyTool.processActionDoIt}value="#{msgs.sample_one_cmd_go}" />value="#{msgs.sample_one_cmd_go}" /></sakai:button_bar></sakai:button_bar>
<sakai:view_container title="#{msgs.sample_title}">
<sakai:date_input <sakai:date_input value="#{MyTool.date}" />value="#{MyTool.date}" />
<h:inputText <h:inputText value="#{MyTool.userName}" />value="#{MyTool.userName}" />
<sakai:group_box <sakai:group_box title="#{msgs.sample_one_groupbox}">title="#{msgs.sample_one_groupbox}">
<sakai:instruction_message<sakai:instruction_messagevalue="#{msgs.sample_one_instructions}" />value="#{msgs.sample_one_instructions}" />
<sakai:tool_bar> <sakai:tool_bar_item/> </sakai:tool_bar>
Web Services
Framework
Application
ToDo Code
ToDo Layout
Presentation FrameworkWS Client
Axis
WS End Point
Web Svcs
Other Tools
Layout
PresentationAbstraction
SAF—Kernel
SAF—Common Services
Other Services ToDo Service
ServiceInterface (i.e. API)
Aggregator
Presentation
Tools
Services
Client
SystemT
he A
bstr
act
Sak
ai E
nviro
nmen
t
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
QuickTime™ and aTIFF (Uncompressed) decompressor
are needed to see this picture.
Prototype of Sakai working in the Bodington Learning Management System
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
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
SakaiTool
RequestFilter
JSR-168Tool
PortletServlet
Sakai ToolRegistration
Pluto PortletRegistration
Sakai’s Aggregator SakaiSite Setup
Pluto Container
Sakai ToolDispatch
Pluto 1.1 Integrated into 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-168 - 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:view_container title="#{msgs.sample_title}">
<sakai:tool_bar> <sakai:tool_bar_item/> </sakai:tool_bar>
<sakai:instruction_messagevalue="#{msgs.sample_one_instructions}" />
<sakai:group_box title="#{msgs.sample_one_groupbox}">
<h:inputText value="#{MyTool.userName}" />
<sakai:date_input value="#{MyTool.date}" />
<sakai:button_bar><sakai:button_bar_itemaction="#{MyTool.processActionDoIt}value="#{msgs.sample_one_cmd_go}" /></sakai:button_bar>
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/portaltomcat/webapps/mercurytomcat/webapps/osp-portal
Aggregator
Presentation
Tools
Services
tomcat/webapp/sakai-user-tooltomcat/webapp/sakai-message-tool
tomcat/shared/lib/site-api.jartomcat/shared/lib/user-api.jar
tomcat/components/sakai-authz-packtomcat/components/sakai-user-pack
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
MeleteLanguageModule
Anouncements
We are building a general way to do
this….
ScormAuthoring
OSPortfolio
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
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
Announce Melete Jforum Rwiki Profile
AutoDDL Yes Yes Yes Yes Yes
Properties Yes Yes No Yes Yes
MySql Yes Yes Yes Yes Yes
Oracle Yes Yes No ** Yes Yes
Skinnable Yes Yes No Yes Yes
Cluster Yes ?? Yes Yes Yes
Resource Yes No No Yes No
I18N Yes Yes Yes Yes Yes
Events Yes No No No No
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
Sak
ai
Sakai APIs
Sam
igo,
Con
cept
Tut
or, E
tc
SakaiIMS Proxy
SessionAnd Services
Bootstrap
IMS TI OutcomeRequest
ApplicationCode
1
2
34
5
6
7
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
QuickTime™ and aTIFF (Uncompressed) decompressor
are needed to see this picture.
QuickTime™ and aTIFF (Uncompressed) decompressor
are needed to see this picture.
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/
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 FrameworkWS Client
Axis
WS End Point
Web Svcs
Other Tools
Layout
PresentationAbstraction
SAF—Kernel
SAF—Common Services
Other Services ToDo Service
ServiceInterface (i.e. API)
Installing Sakai
• Downloads– System Requirements– Documentation– Getting the Latest Source Code– Issue Tracking– Community– Getting Older Releases– License
• http://source.sakaiproject.org/release/2.3.1/
Providers inSakai
Sakai VelocityTools
Sakai JSFTools
Enterprise D
ataSakai JSFSupport
Sakai VelocitySupport
Sakai ServletTools
SakaiFramework
Services
SakaiApplicationServices
Roster/RoleProvider
User DirectoryProvider
Course/SiteProvider
https://source.sakaiproject.org/svn/providers/trunk/
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.
Developing a Skin for Sakai
• Documentation– https://source.sakaiproject.org/svn//
reference/trunk/docs/architecture/sakai_skin.doc
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é
• http://bugs.sakaiproject.org/confluence/display/BOOT/Home
Building a JSR-168 Portlet
• Download JSR-168 Specification– http://jcp.org/en/jsr/detail?id=168
• Development Documentation– http://developers.sun.com/portalserver/reference/
techart/jsr168/– http://portals.apache.org/pluto/v11/resources.html
• Portlets in Sakai– https://source.sakaiproject.org/contrib/portlets/trunk/– https://source.sakaiproject.org/svn//reference/
trunk/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– http://www.sakaiproject.org/imsti-test/
• IMS Tool Interoperability Portlet– https://source.sakaiproject.org/contrib/
portlets/trunk/
• TO DO:– Write IMS TI - Lite in PHP and Ruby