From Your Course Syllabus to Earthquake Engineering: Collaboration

using the CHEF Framework

Charles Severance

University of Michigan

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

Over 42,000 users at the end of 2003

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 ITR

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

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

Services

• Long-term lifecycle• One instance (Singleton)

– 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

Service Implementations

Tool

Service A

PI

Clustered ServiceImplementation

PortalEngine

Web Svcs ServiceImplementation

Database ServiceImplementation

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.

Turbine ServiceBroker chef.properties

Tools

Grid

Service A

PI

CHEFGrid

ServiceComponent

UserD

irectory

CHEFUserDirectory

ServiceComponent

GridUserDirectory

ProviderService

UserD

irectory

Pro

vider

Existing CHEF New Code

Existing GRIDIU Portlets

LDAPGridFTP

Proxy

Jetspeed

UserIU Code

JetspeedLogin

COGsMyProxy

To

mcat / A

pach

eAdding Grid Infrastructure to CHEF

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)

• 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 - Interoperbility is harder than portability

• Mellon Foundation funding

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.

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 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 - so it may change

Sakai Architecture

Portal TechnologyuPortal 3.0

PortalConfiguration

Implementations

Channels, Teamlets

JSR-168 Portlets

CHEF Services

JSR-168 Technology

OKI Services

Legacy

SakaiTeamlet

OtherServices

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

Summary