Date post: | 19-Dec-2015 |
Category: |
Documents |
View: | 225 times |
Download: | 0 times |
Sakai Technical Overview
Aaron Zeckoski ([email protected])
From original slides by
Chuck Severance and Ian Boston
Creative Commons Attribution-NonCommercial-ShareAlike 2.5 License Sakai Programmer's Café
Sakai Montreal CRIM Workshop
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
• 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.
Java1.5
Oracle
Apache - SSL, mod_jk, WEBISO, virtual hosting
MySql 4.1
SakaiTomcat 5.5
SpringHibernate
Java Server FacesVelocity (legacy)
RSF
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)
• 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
Framework, Tools and Services
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
Persistence
ServiceInterface(i.e. API)
Service Oriented Architecture
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
Fitting Into the Sakai Framework
<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>
JSFSakai Presentation Services
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• 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
Abstract Architecture
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”
Aggregator
Presentation
Tools
Services
• Cleaned up OSP Portal
• Hierarchy Portals - Astro & Orcus
• Rumors and notions– Acetylene - Rumored RSF based portal– Iframe-free portal– PDA Aggregator– Better Desktop Portal
Aggregator
Presentation
Tools
Services
Upcoming Aggregators
• True abstraction between Presentation and Tools• Tools should not be aware that they are in a web browser
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
Aggregator
Presentation
Tools
Services
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
Presentation Layer Goals
<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
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
Finding Abstraction in your Tomcat
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
HT
ML
HT
ML
Sakai Entity APIs
ExistingSakaiTools
Legend Existing Sakai 2.2 Work
WebDav
Web
Sakai SOA APIs
HT
ML
HT
ML
ExistingSakaiTools
Access
perl
php
python
.NET
Sakai ServicesSearchService
plone
joomla
External
Sakai Entity APIs
Import and Export
SOAP
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, 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
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 Yes No
*Sample* Attribute Matrix
• 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.
Sakai Architecture Goals
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)
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
• Uses web services and IFRAMES• Roughly based on WebCT PowerLinks• Does not require tools to be written in Java• Currently in contrib space in Sakai
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
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/
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
HT
ML
H
TM
LR
ES
T
WebDavSOAP
iCal
SPARQL
RSSCalDav
Collaborationand
Learning
WebDavSOAP Collaborationand
Learning
Current Sakai
Future Sakai
Sakai “Swiss Army Knife”
HT
ML
HT
ML
HT
ML
HT
ML
Sakai Object Bus
SakaiCore
Services
SakaiSemanticServices
NewSemantic
Tools
ExistingSakai
Services
ExistingSakaiTools
Legend Existing Sakai New Work
WebDav
RSS
REST
SPARQL
CalDav
iCal
SOAP
Sakai SOA APIs
Import and Export WebDav
RSS
REST
SPARQL
CalDav
iCal
SOAP
Sakai Web 2.0
Providers inSakai
Sakai VelocityTools
Sakai JSFTools
Enterprise D
ataSakai JSFSupport
Sakai VelocitySupport
Sakai ServletTools
SakaiFramework
Services
SakaiApplicationServices
RoleProvider
UserProvider
Course/SiteProvider
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.