Collaboration tools: The CHEF and Sakai Projects

Download Report

Transcript Collaboration tools: The CHEF and Sakai Projects

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
Portal Technology
Jetspeed 2.0
uPortal 3.0
Websphere Й
Java
Swing
JSR-168 Technology
Legacy
Channels,
Teamlets
CHEF
Services
JSR-168
Portlets
Sakai GUI
Sakai GUI
Sakai
Teamlet
Sakai
Teamlet
OKI
Services
Sakai
Other
Services
NMI Grid Portal
NEESGrid
CHEF 1
CHEF 2
Science of Collaboratories
Worktools (Notes Based)
WTNG
CTNG
Coursetools (Notes Based)
SPARC
1991 - 1997 1998
1999
2000
2001
2002
2003
2004
2005
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
Science of Collaboratories
people-to-people
Communication,
Collaboration
Services
groups-toinformation
Distributed,
media-rich
information
technology
Digital libraries &
documents
http://www.scienceofcollaboratories.org/
NSF Funded.
groups-tofacilities
Remote
instruments
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
Tomcat Servlet Container
Jetspeed Portal
CHEF Implementation
Architecture
- More Detail
Velocity
CSS
Turbine Framework
Turbine
Service
Tool
Servlet
Turbine
Service
Turbine
Service
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.
HTTP
Example Architecture Velocity Resources
WEBDAV
Tomcat Servlet Container
Jetspeed Portal
CSS
Turbine
Security
Service
Resource
Tool
Access
Servlet
Content
Service
src/java/org/chefproject/actions/ResourceAction.java
src/vm/chef_resources_show.vm (plus 10 more)
src/java/org/chefproject/service/component/BaseContentService.java
src/java/org/chefproject/service/component/BaseUserDirectoryService.java
src/java/org/chefproject/service/component/ChefSecurity.java
src/java/org/chefproject/servlet/ChefdavServlet.java
src/java/org/chefproject/servlet/AccessServlet.java
Webdav
Servlet
User Dir.
Service
CHEF
Grid
Service
Component
Teamlets:
OGSA
Jetspeed
Login
Jakarta
UT Code
IU Code
IU Portlets
LDAP
GridFTP
Proxy
User
UM Code
Apache
NEES
Teamlet
Jetspeed
Existing CHEF
CHEF
UserDirectory
Service
Component
UserDirectory
UserDirectory
Provider
Grid
UserDirectory
Provider
Service
PERL-GridPort
Grid Service API
COGs
MyProxy
Existing GRID
Credentials
Perl-CGI
CHEF Architecture
Flexibility: 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
Video as data: User Views
Still Image / Camera Control
Camera Control
Gateway
^
< >
Still Image Viewer
^
–
–
–
–
~ < >
< >
DT Main System
Thumbnail + Audio + Data
Data Viewer
< > +
CHEF Applications
•
•
•
•
CourseTools Next Generation
WorkTools Next Generation
NEESGrid
NSF National Middleware Grid Portal
CourseTools Next Generation
Over 5000 users at the end of 2003
http://coursetools.ummu.umich.edu/
Worktools Next Generation
New WorkTools Sites being created in WTNG as of 12/2003
Run on the same servers as CTNG.
NEESGrid - The Equipment
Network for
Earthquake
Engineering
Simulation
NSF Funded.
NCSA, ANL, USC/ISI, UM, USC, Berkeley, MSU
CHEF-Based NEESGrid
Software
Grid
Service
Stubs
Portal
Portlets
And
Teamlets
Service
API
Grid
Protocols
Grid
Services
NMI / OGCE
Local
Portal
Services
Remote
Content
Services
HTTP
Remote
Content
Servers
Jetspeed
Internal
Services
Figure 4: The revised portal architecture will provide a unified interface for
portal services.
NSF National Middleware Iniative
Indiana, UTexas, ANL, UM, NCSA
www.ogce.org
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 Chair
Jeff Merriman, MIT-OKI
Amitava ’Babi’ Mitra, MIT- AMPS
Carl Jacobson -JASIG
Lois Brooks, Stanford
Technical Coord.
Committee Chair
Chuck Severance
Tools
Rob Lowden
Architecture
Glenn Golden
uPortal
Stanford
MIT
U of Michigan
Indiana Univ.
Local Members
uPortal
Stanford
MIT
U of Michigan
Indiana Univ.
Local Teams
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.
SAKAI Overview
July 04
Jan 04
May 05
Activity:
Maintenance &
Transition from a
project to
a community
Michigan
•CHEF Framework
•CourseTools
•WorkTools
Indiana
•Navigo Assessment
•Eden Workflow
•Oncourse
MIT
•Stellar
Stanford
•CourseWork
•Assessment
OKI
•OSIDs
Dec 05
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
Activity: Ongoing implementation work at local institution…
uPortal
Primary SAKAI Activity
Architecting for JSR-168 Portlets,
Refactoring “best of” features for tools
Conforming tools to Tool Portability Profile
Primary SAKAI Activity
Refining SAKAI Framework,
Tuning and conforming additional tools
Intensive community building/training
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
Configuration
Implementations
Portal Technology
uPortal 3.0
JSR-168 Technology
Legacy
Sakai GUI
Portable code
Sakai Service Layer
Channels,
Teamlets
JSR-168
Portlets
Sakai
Portlet
Sakai GUI Layer
Mega-portable code
CHEF
Services
OKI
Services
Sakai
Services
Architecture and Tool Development
Dec 15
SAKAI 1.0 Whitepaper
Pre-alpha release of SAKAI’d CHEF
Architect Discussions: getting it right
across schools
Sakai Timeline
July 1
SAKAI 1.0 available for testing by
production facilities
Feb 15
SAKAI 0.5 available for tool
development
Oct ‘03
Jan ‘04
Nov 15
Requirements, Functional Design,
UI, Full Spec
Apr ‘04
Feb 15
Developers’ Workshop: Coding SAKAI 1.0 using
SAKAI 0.05
July ‘04
Oct ‘04
Aug 1
Tools running in SAKAI 1.0
pilot/production environment at
participating schools
Feb 1
Deliver full spec to programmers
July 1
Final tool delivery to participating
schools
Tool Development
CHEF Project Personnel
Michelle Bejian Lotia
Jim Eng
Richard Ellis
Glenn Golden
David Haines
Joseph Hardin
John Johnston
Louis King
Dan Kiskis
Peter Knoop
John Leasia
Hans Masing
Brett Miller
Daphne Ogle
Diana Perpich
Zhen Qian
Hannah Reeves
Marco Rocco
Lars Schumann
Charles Severance
Gonzalo Silverio
Joanne Yuanyuan Sui
Stephanie Teasley
Terry Weymouth
David Whitehead
Elizabeth Wilson
Summary Points
•
In the long term, thinking about a learning management system as a product is
too limiting
–
–
–
•
There are three phases of Open Source Development - it is hard to skip them
–
–
–
•
•
•
•
Campus Portal
Learning Management
Collaborative activity in large and small groups
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.