1. Charles Severance University of Michigan
From Your Course Syllabus to Earthquake Engineering: Collaboration using the CHEF Framework
Charles Severance
University of Michigan

2. Outline Collaborative Activities at UM CHEF Technology CHEF Features
CHEF Status
The Sakai Project
Sakai Technologies
Sakai Timeline

3. Science of CollaboratoriesUM
1998
1999
2000
2001
2002
2003
2004
2005
Sakai
NMI Grid Portal
NEESGrid
CHEF 1
CHEF 2
Science of Collaboratories
Worktools (Notes Based)
WTNG
Coursetools (Notes Based)
CTNG
SPARC

4. SPARC 2/2001 600 users 800 data sources
An advanced users view of SPARC; lots of information in multiple SPARC pages!
The typical SPARC collaboration features down the left hand side, page information, resource list, active user list, and chat
Streaming video in the lower left.
Lots of data and model views throughout the rest of the screen shot.
2/ users 800 data sources

5. CourseTools
Over 42,000 users at the end of 2003

6. WorkTools Over 9000 users (2000 active) at the end of 2003
Web-based file-system
Over 9000 users (2000 active) at the end of 2003

7. Science of Collaboratories
Digital libraries & documents
groups-to-
information
facilities
people-to-people
Communication,
Collaboration
Services
Distributed,
media-rich
technology
Remote instruments
NSF Funded ITR

8. CHEF 1.0 Fall 2001: CHEF Development begins
Generalized extensible framework for building collaboratories
“Best-of” CourseTools, SPARC, WorkTools
Integrate across current UM 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

9. 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

10. 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

11. CHEF General Tools Announcements Chat Threaded Discussion Calendar
Schedule
Archive
Resources (including WebDav)
Web-Frame
Worksite Setup
Profile
Notifications / Subscriptions
Public View
Anonymous Comment

12. CHEF - More tools Worktools Grid Technologies 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

13. Services Long-term lifecycle One instance
Must be aware that multiple users can use service
Can use memory resident information (often used for cache)
Contains as much of the implementation as possible
Pluggable implementations
Memory version
XML implementation
Web services implementation
Database implementation

14. Service Implementations
Web Svcs Service
Implementation
Service API
Tool
Portal
Engine
Database Service
Implementation
Clustered Service
Implementation
There are three elements to CHEF services which a teamlet interacts with:
The Service API which defines the properties and methods of the service.
The Service Component which is the actual implementation of the service.
Core Components are the objects which are exchanged between the services and the teamlets.
The properties file determines which Service Components are user for each Service API. At runtime, the Teamlet consults Turbine to get the Service API to the appropriate Service Component.
Turbine Service
Broker
chef.properties
The API is an Interface – There can be any number of different service implementations which implement the Interface. At run-time Turbine reads a configuration file and associates the appropriate service implementation with each API and provides lifecycle services to the service.

15. CHEF Implementation Architecture - More Detail
Tomcat Servlet Container
CHEF Implementation Architecture - More Detail
Jetspeed Portal
Velocity
CSS
Tool
Servlet
Turbine Framework
Turbine
Service
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.

16. Example Architecture - Resources
Tomcat Servlet Container
Example Architecture - Resources
HTTP
WEBDAV
Jetspeed Portal
Velocity
CSS
Resource
Tool
Access
Servlet
Webdav
Servlet
Turbine
Security
Service
Content
Service
User Dir.
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

17. Adding Grid Infrastructure to CHEF The value of a component based architecture
Grid Service API
Tools
Jetspeed
Tomcat / Apache
CHEF
Grid
Service
Component
MyProxy
COGs
Grid
UserDirectory
Provider
Service
UserDirectory
Provider
CHEF
UserDirectory
Service
Component
UserDirectory
Jetspeed
Login
The UserDirectory and GroupDirectory services also use Turbine to find the
appropriate UserDirectoryProvider and GroupDirectoryProvider at run-time
using the same configuration mechanism as the Service API and Service
Components.
Existing CHEF
New Code
User
IU Portlets
LDAP
GridFTP
Proxy
Existing GRID
IU Code

18. CHEF Applications CourseTools Next Generation
WorkTools Next Generation
NEESGrid
NSF National Middleware Grid Portal

19. CourseTools Next Generation
Over 5000 users at the end of 2003

20. Worktools Next Generation
New WorkTools Sites being created in WTNG as of 12/2003
Run on the same servers as CTNG.

21. NEESGrid - The Equipment
Network for Earthquake Engineering Simulation
NSF Funded.
NCSA, ANL, USC/ISI, UM, USC, Berkeley, MSU

22. CHEF-Based NEESGrid Software

23. NEESGrid - Video as Data
Still Image / Camera Control ~
<
> ^
Control
Plugin
Thumbnail + Audio + Data
<
> +
Thumbnail
Process
Data Viewer

24. NMI / OGCE www.ogce.org NSF National Middleware Iniative
Indiana, UTexas, ANL, UM, NCSA

25. CHEF Status CHEF is stable and released Other derived variants of CHEF
CHEF 1.2 from
Workshops twice per year
Technical support mailing list
Collaborative site chefproject.org/chef/
Other derived variants of CHEF
NMI 1.0 Beta from
NEESGrid 2.1 from
CHEF has demonstrated its value as collaborative tool or integration fabric

26. Life is tough for a framework
The benefit of a framework is when many people adopt it and tools become built creating a “market” of tools
Frameworks combine off-the-shelf technology with value added “glue”
CHEF is based on Jetspeed / Velocity / Turbine
There are a lot of frameworks - all competing for mindshare
A successful framework needs several things:
Based on familiar off-the-shelf components which are “popular”
Many tools in place with at least one “killer application”
Demonstrated commitment on the part of a community who adopt it “all-the-way”
Understand that there will be many frameworks

27. 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 Initiative (OKI) needed full implementation
IMS standard such as Question and Testing Interoperability (QTI)
Why not coordinate this work , do the work once, and share each others solutions?
Integrate across projects at multiple institutions 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

28. MIT Stellar
MIT’s Stellar

29. Customizable page menu
Sites are accessed via their tab
Michigan’s CTNG
UM CTNG
Foreign Language support
Synoptic views
Customizable page menu
Presence

30. Indiana OnCourse
Indiana’s OnCourse

31. Stanford’s CourseWork
Stanford - CourseWork
Stanford’s CourseWork

32. uPortal
uPortal

33. OKI
OKI

34. SAKAI Overview "Best of" Refactoring Jan 04 July 04 May 05 Dec 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
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
"Best of"
Refactoring
Activity: Ongoing implementation work at local institution…
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

37. Relationship to Other Efforts
OKI
uPortal
IMS
JSF
Tomcat
IEEE
Sakai - A Profile + Implementation
Sakai is a consumer of standards, and technologies to be assembled into an implementation and a profile with some Sakai-specific value add in certain areas. As we work through development issues, we may identify new ideas/problems/extensions that we will suggest back to these groups by participating in those groups as a participant. Even though uPortal and OKI have received funding as part of the Sakai project it does not change the basic relationship between the projects.

38. Comparison to JISC eLearning Program
Similar in scope but very complimentary
Sakai
Conservative, production oriented, Java APIs, little new pedagogy, large project
JISC eLearning
Research oriented, web services and multiple languages, explores pedagogy, series of small projects

39. Technical Coord. Committee Chair
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
Educational
Partners
Jim Farmer
Local Teams
Local Teams
Indiana Univ.
U of Michigan
MIT
Stanford
uPortal
Indiana Univ.
U of Michigan
MIT
Stanford
uPortal
DeAnza
Berkeley
Yale

40. Sakai Educational Partner’s Program
Membership Fee: US$10K per year, 3 years
Access to SEPP staff
Community development manager
SEPP developers, documentation writers
Knowledgebase
Developer training for the TPP
Exchange for partner-developed tools
Strategy and implementation workshops
Early access to pre-release code
Official launch date for SEPP services is 1 March The Core Sakai institutions will develop ensure the project deliverables are met during the 2 years of the Sakai Project. The SEPP is the long-term community to ensure Sakai’s continuing evolution and value.
Over a dozen partner institution commitments already committed to SEPP as of January 2004 (announcements soon).
Note that some estimate licensing costs of a course management system are approximately 20% of the total cost of ownership. The open source nature of Sakai means that any institution can use the Sakai software with no licensing costs or any fees whatsoever for the code. The Sakai Educational Partner’s Program provides a community to help address the other 80% of the cost of a CMS or other Sakai tool.

41. FAQ: Educational Partners
Is the SEPP program buying access to the source code?
No - the source code will be published openly and freely according to the Sakai project plan. SEPP partners will see the releases several weeks before the public release so they can review, comment, and generally help with the release process. SEPP members will be invited to a pre-release workshop to examine the release and interact directly with the Sakai core team.
Is the SEPP program buying a “vote” in the governance of Sakai or the consensus process developing specification for Sakai?
No - as specifications are developed and initial versions are released comments are welcome from anyone. We hope that there is never a “vote” throughout the entire Sakai project - we hope that this is about making the right technical choices and that the proper choice will bubble up through active discussion with as wide a range of people as possible.

42. SEPP FAQ Continued..
So, I don’t need to pay for source and I am not buying a vote - sounds like I should not join the SEPP
Wrong - By joining the SEPP, you become an active part of the Sakai team
The SEPP staff will keep you apprised of all Sakai activities and bring important issues to your attention.
The SEPP staff attend all major meetings and if you let them know your requirements, and needs, the SEPP staff will make sure that your requirements are considered at the exact moment that the discussions and decisions are being made
I know members of the Sakai core team - they are nice people - why don’t they just do this instead of making a big fuss about the SEPP?
Yes - you are right about them being nice people. But they need to focus on the outrageous timeline forced upon them by the funding agency and the (really mean) Sakai board. Given that pressure, even nice people might conveniently forget about your requirements at crunch time. By having SEPP staff who have no line project responsibility, they remain focused on the needs of the SEPP members - even when things get a little hectic.
Running a project with as much public interest as Sakai requires dedicated resources for communication or the project is in danger of failing - depending on developers to perform this role is very dangerous.

43. SEPP FAQ Continued… (last slide)
So does this mean that the Sakai core team is sequestered and that I as a SEPP member never get to talk to the core team?
Again, you are incorrect - the Sakai team is interested in interacting with anyone who has a significant comment, problem or issue so that it can be resolved as quickly as practical. We are all motivated for the Sakai product to be “right” - if something is wrong we need to hear about it quickly and directly. The SEPP staff will bring in the relevant members of the core team into the discussion whenever it is appropriate. (Because the SEPP is part is every significant meeting, they know exactly who is the lead in any area of the project at any given moment)
The Sakai core team engages in discussions with anyone who can shed light on issues regardless of whether or not they are in the SEPP - the difference for SEPP members is that you are kept in the loop in terms of what the current questions are.
Is this about the money?
No. The expected revenue from the SEPP funds is somewhere between 5% and 2% of the expected expenditures in the project (depending on whether you look at minimum required match or the approximate expected match respectively)

44. Hewlett Grant Announcement Partners – Feb 9, 2004
Carnegie Mellon University
Columbia University
Cornell University
Foothill-DeAnza Community Colleges
Harvard University
Northwestern University
Princeton University
Tufts University
University of Colorado
University of California-Berkeley
University of California-Davis
University of California-LA
University of California-Merced
University of Hawaii
University of Oklahoma
University of Virginia
University of Washington
University of Wisconsin-Madison
Yale University
sakaiproject.org

45. A Diverse Team Learn from each institution’s strengths
OKI - Life in the public eye
UM / uPortal - Building for others to use
MIT - Content focused CMS approach
MIT - Experience with OCW and OKI
Stanford - Assessment
IU / Stanford - Requirements and design methodology
IU - Open Source Profile Initiative

46. Project Philosophies
Consensus decision making - hopefully the right answer will prevail through open discussion
Board is the “court of last resort”
We are a 30+ person startup for the next two years
We will make pragmatic decisions to move forward toward our goals
Success = a product which is equal to or better than commercial products

47. 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.

48. The good of the many…
This is not about foisting existing solutions across the partners
Each university will let go of their CMS by 2005 (really)
Indiana is dropping their University portal effort (OneStart)
uPortal is changing their whole portal to use JSR Their current interface will be an “adapter”

49. Sakai Enhancement Process
Focus
Groups
1 to 1
Conversations
Development
Lead
Prioritized
Feature
List
Falcon
Tools
Lead
Sakai
Board
Online CMS
Suggestions
Suggestions
Collected
Documented
Tracking # assigned
Sakai
Enhancement
Institution Representative
Rob Lowden, 2/19/04

50. Sakai All-Hands Developer Meeting February 19-20, Stanford

51. Portability Profile (as of today)
Tools
JSF GUI Layer - JSP Document (looking at XML)
JSR 168 Portlet
JSR Servlet Standard
Services
Setter dependency injection and service location
Spring, OKI, Avalon
Looking for Enterprise Storage Technology
Oracle XML / CMP EJBs / Hibernate (big ??)
High performance for clustering and scaling
This is in progress - so it may change

52. Sakai Framework/Config
uPortal / JSR - 168
Sakai Framework/Config
JSF Render
JSP Layout
<sakai:toolbar>
< …
JSP Layout
<sakai:toolbar>
< … …
Tool
Config Beans
View Beans
Action
Action
Service
Config Beans
Method
Service
Config Beans
Method
The Slide.

53. uPortal Portlet Roadmap
Support Portlets (JSR-168) via adapter
uPortal 3.0
Implement Portlet Specification (JSR-168)
Support IChannel via adapter
Framework
Chan
Chan
Framework
Pluto
Portlet
Portlet
Chan
Chan
Adapter
Portlet
Portlet
Adapter
Pluto
Portlet
Portlet
Chan
Chan
Feb 19, 2004
SAKAI Developer’s Workshop, Stanford University

54. FAQ: uPortal and Sakai
Is Sakai telling uPortal what to do because uPortal receives funding through the Sakai project
A little bit - JSR-168 is critical to the Sakai project so Sakai has requested JSR-168 support as part of uPortal’s version 2.3 and 3.0
Note 1: That request assumed that supporting JSR-168 would be part of the strategic direction of uPortal whether or not Sakai existed. We feel that without JSR-168 support uPortal’s complete dominance of the open-source portal space would erode rather rapidly

55. uPortal / Sakai FAQ (cont)
Is Sakai telling uPortal what to do because uPortal receives funding through the Sakai project?
No - The entire implementation detail of uPortal’s JSR-168 is up to uPortal and every other design decision regarding uPortal is made in the same manner as it has always been done in uPortal - Sakai acts as just another member of the uPortal community in that respect
Note: Part of the reason that uPortal is a partner in Sakai is because of its strong open source process and strong community of users. Sakai hopes to learn best practices in running an open source project from the uPortal group.

56. uPortal / Sakai FAQ (cont)
Will uPortal drop support or break the iChannel, cWebProxy interface?
Absolutely not - The iChannel interface and all of the Channel implementations which already exist in the uPortal community are highly valued as Sakai explores the blending of collaborative/learning management systems with enterprise portals.
Any other thoughts on uPortal?
Yes - there are a number of elements of uPortal which Sakai feels are unique advantages of uPortal compared other portals: The flexible skinning using XML/XSLT, the ground breaking work on building an internationalized portal, the flexibility of the portal presentation beyond just images and skins (tab/column, tree-view, etc..)

57. Sakai: Plenty of Questions
How to handle many repositories (Local, DSpace, Fedora, JSR-170) with different semantics though one API?
As we implement the OSIDs, how to store information in a way that is both efficient/fast/scalable and flexible/reusable - perhaps using RDF/URI as a way to search/use content “at a distance” - what about access control though?
How to take the OKI APIs and add sufficient detail (out-of-band-agreements) so as to make it clear how to write tools?
How to make AUTHZ scalable, fast, portable, and interoperable?
How to make this extendible in languages other than JAVA?
What is the role for web services in this project? Why not just define everything in UML and WSDL?

58. Lots of Thorny Issues on a Board

59. Major Project Phases
Architecture and Technology Research (12/ /04)
Small group (~8) lots of communication
Selecting, testing, and gluing underlying components
Early Development (03/ /04)
Medium sized group (~16)
Development of 2-3 tools with a focus on validating the architecture and technology components
Full development of requirements begins
Deep research into OKI DR AUTHN and AUTHZ implementations
Full Development (07/ /05)
Full group compliment ( )
Development driven by requirements in “steady-state” mode
All tools rebuilt and new tools built
SEPP members will volunteer for and begin building tools

60. Sakai 1.0 Contents (07/04)
Complete Framework including JSF to Portlet Rendering and JSR-168 version of uPortal
All of the CHEF tools and services in legacy mode
Several new TPP compliant tools: Navigo (Assessment), DR Tool
Seamless look and feel between legacy and TTP-compliant tools
Complete Portability Profile “book”
Ready to deploy as LMS (looks a lot like CHEF 1.2 plus)
Ready to use as a development platform with rich sample applications
Nearly complete implementation of OKI OSIDs, façade classes, and full interoperability with CHEF services
Goal: Deployable in production at UM, Pilot at the other institutions

61. Sakai 2.0 (2Q05) Complete replacement of CHEF-based (legacy) tools
TPP Compliant, using OKI and Sakai APIs
Specs based on the TFS - tools will be richer and deeper
Each partner institution will focus on a set of tools to develop
SEPP partners will be involved in the new tool development based on ability and commitment.

62. A Vision
We will create an open-source learning management system, but at the same time create a portal framework, market, clearinghouse, cadre of skilled programmers, and documentation necessary to enable many organizations to focus their energy in developing capabilities/tools which advance the pedagogy and effectiveness of technology-enhanced teaching, learning, and collaboration rather than just building another threaded discussion tool as a LMS.

63. Summary
Think of learning management systems, campus portals, and problem solving environments as very similar activities and perhaps components and frameworks can be developed which can be used in more than one application space
Organizational collaboration is about letting go of local totems and truly depending on one another
If successful, the Sakai project may well create whole new ways for IT organizations to work together - our LMS may be a very small part of its overall impact.
Imagine a time, where 20 Universities, each with IT staff set out to solve some common problem together.
That is ~1500 professional, paid developers with a common goal - if you were in charge, what would you have them do?