2004 01 10 Chef Sa V01
-
Upload
jiali-zhang -
Category
Technology
-
view
1.220 -
download
2
description
Transcript of 2004 01 10 Chef Sa V01
Collaboration tools: The CHEF and Sakai Projects
Charles Severance
University of Michigan
Goals
• Briefly cover our open source learning management and collaborative systems
• Focus on our Open Source experiences in these projects
Outline
• Collaborative Activities at UM
• CHEF Technology
• CHEF Features
• CHEF Status
• The Sakai Project
• Sakai Technologies
• Sakai Timeline
Collaboration @ UM
19981991 - 1997 1999 2000 2001 2002 2003 2004 2005
SPARC
Science of Collaboratories
Sakai
Worktools (Notes Based) WTNG
Coursetools (Notes Based) CTNG
CHEF 1 CHEF 2
NMI Grid Portal
NEESGrid
Portal TechnologyJetspeed 2.0uPortal 3.0
Websphere É
Channels, Teamlets
JSR-168 Portlets
CHEF Services
JSR-168 Technology
OKI Services
Legacy
SakaiTeamlet
OtherServices
Sakai GUI
SakaiTeamlet
Sakai GUI
Java Swing
SPARC
2/2001 600 users 800 data sources
CourseTools
Michigan’s Coursetools has 42,000 users (2003)Indiana University’s OnCourse has 80000 users
WorkTools
Over 9000 users (2000 active) at the end of 2003
Digital libraries & documents
groups-to-information
groups-to-facilities
people-to-people
Communication,Collaboration
Services
Distributed,media-richinformationtechnology
Remote instruments
http://www.scienceofcollaboratories.org/
Science of Collaboratories
NSF Funded.
CHEF 1.0
• Fall 2001: CHEF Development begins – Generalized extensible framework for building collaboratories– “Best-of” CourseTools, SPARC, WorkTools
• Integrate across projects and adopt relevant standards• Funded internally at UM as replacement for CourseTools• All JAVA - Open Source
– Jakarta Jetspeed Portal– Jakarta Tomcat Servlet Container– Jakarta Turbine Service Container
• Build community of developers through workshops and outreach
CHEF Technology
• Provide a mechanism for software development which will allow organizations to share and re-use each other’s work
• Utilize existing technologies wherever possible and add value rather than invent all new
• Enable code reuse across multiple organizations• Lead to portal technology - Jetspeed
Not “just” a portal
• Portals are a framework to deploy tools (aka rectangles) and focus on how the user wants to arrange their own “rectangles”
• While CHEF technically is a portal, the goal is for the tools to work together closely and seem to really be parts of a larger “tool”
• CHEF has a lot of features, (services, presence, notification, etc..) which bridge the gap between portal and application framework
CHEF Implementation Architecture - More Detail
Tomcat Servlet Container
Jetspeed Portal
Turbine Framework Tool
TurbineService
VelocityCSS
TurbineService
TurbineService
Servlet
In addition to Jetspeed, CHEF operates within a Servlet container called Jakarta Tomcat. Whereas portlets operate in one “recatangle” which is a subset of the screen, Servlets control the entire HTTP response or even talk non-HTTP protocols.
Example Architecture - Resources
Tomcat Servlet Container
Jetspeed Portal
Turbine
Resource Tool
SecurityService
VelocityCSS
ContentService
User Dir.Service
AccessServlet
src/java/org/chefproject/actions/ResourceAction.javasrc/vm/chef_resources_show.vm (plus 10 more)src/java/org/chefproject/service/component/BaseContentService.javasrc/java/org/chefproject/service/component/BaseUserDirectoryService.javasrc/java/org/chefproject/service/component/ChefSecurity.javasrc/java/org/chefproject/servlet/ChefdavServlet.javasrc/java/org/chefproject/servlet/AccessServlet.java
HTTP
WebdavServlet
WEB
DA
V
PERL-GridPort
Teamlets:
Grid
Service A
PI
CHEFGrid
ServiceComponent
UserD
irectory
CHEFUserDirectory
ServiceComponent
GridUserDirectory
ProviderService
UserD
irectory
Pro
vider
NEESTeamlet
OGSA
Existing CHEF UM Code
Existing GRIDIU Portlets
LDAPGridFTP
Proxy
Jetspeed
UserJakarta IU Code
JetspeedLogin
COGsMyProxy
Perl-C
GI
Ap
ache
UT Code
Credentials
CHEF ArchitectureFlexibility: NMI
CHEF General Tools
– Announcements– Chat– Threaded Discussion– Calendar– Schedule– E-Mail Archive– Resources (including WebDav)– Web-Frame– Worksite Setup– Profile– Notifications / Subscriptions– Public View– Anonymous Comment
CHEF - More tools
• Course Management– Assignments– Drop Box
• Worktools– Data Viewers (Live/Stored)– Telepresense– Video as Data– Electronic Notebook
• Grid Technologies– Grid sign on using myproxy– Grid computational portal– GridFTP– ..Many more
DT Main System
Video as data: User ViewsStill Image / Camera Control
~
< >^
^
< >
Still Image Viewer
< >
Camera ControlGateway
Data Viewer
Thumbnail + Audio + Data
< > +
CHEF Applications
• CourseTools Next Generation
• WorkTools Next Generation
• NEESGrid
• NSF National Middleware Grid Portal
CourseTools Next Generation
Over 5000 users at the end of 2003http://coursetools.ummu.umich.edu/
Worktools Next Generation
New WorkTools Sites being created in WTNG as of 12/2003Run on the same servers as CTNG.
NEESGrid - The EquipmentNetwork for Earthquake Engineering Simulation
NSF Funded. NCSA, ANL, USC/ISI, UM, USC, Berkeley, MSU
CHEF-Based NEESGrid Software
NMI / OGCE www.ogce.org
NSF National Middleware IniativeIndiana, UTexas, ANL, UM, NCSA
CHEF Status
• CHEF is stable and released– CHEF 1.2 from www.chefproject.org– Workshops twice per year– Technical support mailing list– Collaborative site chefproject.org/chef/
• Other derived variants of CHEF– NMI 1.0 Beta from www.ogce.org– NEESGrid 2.1 from www.neesgrid.org
What is Next: SAKAI• U Michigan, Indiana U, MIT, Stanford, uPortal
– All have built portals / course management systems– JSR-168 portlet standard requires us all to re-tool and look at new approach to
portals
• Course Management System Standards– Open Knowledge Iniative (OKI) needed full implementation– IMS standard such as Question and Testing Interoperability (QTI)– SCORM Course Content Standard
• Why not coordinate this work , do the work once, and share each others solutions?
• Integrate across projects and adopt relevant standards• Collaboration at the next frontier - implementation• Tool Portability Profile (TPP)
– Truly portable tools and services– Tools built at different places look and feel the same and share data and services– This is difficult - Interoperability is harder than portability
• Mellon Foundation funding
Sakai Organization
• To some, the real innovation is the organization• To get these schools/institutions to adopt a central
authority (Sakai Board) for resource allocation of internal as well as grant resources
• Goes beyond resources from grant• Required for closely coupled open source
development, the ‘seed’ software?• Part of the open source experimentation
Board Joseph Hardin, UM, Chair & Project Manager
Brad Wheeler, IU, Vice ChairJeff Merriman, MIT-OKI
Amitava ’Babi’ Mitra, MIT- AMPSCarl Jacobson -JASIGLois Brooks, Stanford
Technical Coord. Committee ChairChuck Severance
Local Teams
ToolsRob Lowden
ArchitectureGlenn Golden
Local Members
Indi
ana
Uni
v.
U o
f M
ich
igan
MIT
Sta
nfor
d
uPo
rta
l
Indi
ana
Uni
v.
U o
f M
ich
igan
MIT
Sta
nfor
d
uPo
rta
l
Open/Open Licensing
• “..all work products under the scope of the Sakai initiative for which a member is counting matching contribution and any Mellon Sakai funding” will be open source software and documentation licensed for both education and commercial use without licensing fees.
Significant difference between a “product” and a “component”Unlimited redistribution is an important aspect of a license.
Jan 04 July 04 May 05
Michigan•CHEF Framework•CourseTools•WorkTools
Indiana•Navigo Assessment•Eden Workflow•Oncourse
MIT•Stellar
Stanford•CourseWork•Assessment
OKI•OSIDs
uPortal
SAKAI 1.0 Release•Tool Portability Profile•Framework•Services-based Portal•Refined OSIDs & implementations
SAKAI Tools•Complete CMS•Assessment
SAKAI 2.0 Release•Tool Portability Profile•Framework•Services-based Portal
SAKAI Tools•Complete CMS•Assessment•Workflow•Research Tools•Authoring Tools
Primary SAKAI ActivityArchitecting for JSR-168 Portlets,
Refactoring “best of” features for toolsConforming tools to Tool Portability Profile
Primary SAKAI ActivityRefining SAKAI Framework,
Tuning and conforming additional toolsIntensive community building/training
Activity: Ongoing implementation work at local institution…
Dec 05
Activity: Maintenance &
Transition from aproject to
a community
SAKAI Overview
Portability Profile (as of today)
• Tools– JSF or XUL GUI Layer– JSR 168 Portlet– JSR Servlet Standard
• Services– Level 1-3 Inversion of Control– Avalon, Turbine, OKI, Spring, Pico
• J2EE / EJB / Jboss - Enterprise Services– Stateless Session– Entity beans for clustering and scaling
• This is in progress
Sakai Architecture
Portal TechnologyuPortal 3.0
PortalConfiguration
Implementations
Channels, Teamlets
JSR-168 Portlets
CHEF Services
JSR-168 Technology
OKI Services
Legacy
SakaiPortlet
SakaiServices
Sakai GUI
Portable code
Sakai Service Layer
Sakai GUI Layer
Mega-portable code
Sakai TimelineDec 15SAKAI 1.0 WhitepaperPre-alpha release of SAKAI’d CHEFArchitect Discussions: getting it right across schools
Oct ‘03 Oct ‘04Jan ‘04 Apr ‘04 July ‘04
Architecture and Tool Development
Tool Development
July 1 SAKAI 1.0 available for testing by production facilitiesFeb 15
SAKAI 0.5 available for tool development
July 1 Final tool delivery to participating schools
Feb 1Deliver full spec to programmers
Feb 15Developers’ Workshop: Coding SAKAI 1.0 using SAKAI 0.05Nov 15
Requirements, Functional Design, UI, Full Spec
Aug 1 Tools running in SAKAI 1.0 pilot/production environment at participating schools
CHEF Project PersonnelMichelle Bejian Lotia Jim EngRichard EllisGlenn GoldenDavid HainesJoseph HardinJohn JohnstonLouis KingDan KiskisPeter KnoopJohn LeasiaHans MasingBrett Miller
Daphne OgleDiana PerpichZhen QianHannah ReevesMarco RoccoLars SchumannCharles SeveranceGonzalo SilverioJoanne Yuanyuan SuiStephanie TeasleyTerry WeymouthDavid WhiteheadElizabeth Wilson
Summary Points• In the long term, thinking about a learning management system as a product is
too limiting– Campus Portal– Learning Management– Collaborative activity in large and small groups
• There are three phases of Open Source Development - it is hard to skip them– Adopt and tinker– Build your own, “sell it”, and recruit users and helpers (influenced by the late 1990’s in
the US)– Become part of something larger - release control to group - truly collaborative
development - Easier when you have “won” in the previous step and it was not as fun as you thought…
• We must get beyond the notion that we are building a self-contained “product” and really we are building parts of an overall solution that others will reuse in ways we cannot imagine
• Open source development is not preparation for an IPO• Measure success when something that someone else develops extends *your*
software.• In many ways Open Source Development is like Research - combination of a set
of very deep skills where the value is in the aggregation of the skills rather than one individual.