logging in or signing up 2005 06 09 sepp v05 Hufflepuff Download Post to : URL : Related Presentations : Share Add to Flag Embed Email Send to Blogs and Networks Add to Channel Uploaded from authorPOINT Insert YouTube videos in PowerPont slides with aS Desktop Copy embed code: (To copy code, click on the text box) Embed: URL: Thumbnail: WordPress Embed Customize Embed The presentation is successfully added In Your Favorites. Views: 235 Category: Education License: All Rights Reserved Like it (0) Dislike it (0) Added: June 24, 2007 This Presentation is Public Favorites: 0 Presentation Description No description available. Comments Posting comment... Premium member Presentation Transcript Sakai Architecture: Sakai Architecture Charles Severance Sakai Chief Architect June 8, 2005 A Bit of History: A Bit of History The first 'release' of Sakai was 12/03 Sakai was funded 01/04 Sakai 1.0 Alpha 02/04 A number of groups reviewed it technically and concluded that its internal structure was 'icky' Framework II proposed - 08/04 A cleanup/rewrite of the Sakai framework 08/04 We did not have time to stop and rewrite… FWII - Research/Design 08/04 - 01/05 More History: More History Sakai 1.0 released 10/04 Old framework - improved performance and reliability Sakai 1.5 was 02/05 Old framework - Samigo integrated Framework II started 01/04 Overlapped with 1.5 and 1.5.1 - slowly split focus and resources. Release 2.0: Release 2.0 Framework II kernel in place Integrated - Gradebook and Samigo Legacy tools internationalized Legacy tools improved to be partially compliant with the style guide. In summary, just about every end-user GUI element has been touched or is new. Web services The storage and services are still very 1.5-like New skin Release 2.0: Release 2.0 Framework II kernel in place Integrated - Gradebook and Samigo Legacy tools internationalized Legacy tools improved to be partially compliant with the style guide. In summary, just about every end-user GUI element has been touched or is new. Web services The storage and services are still very 1.5-like New skin Release Process 2.0: Release Process 2.0 Integration Week - May 16 - 20 Resulted in Release 2.0 Alpha 1 QA Led by Carol Dippel Both core and volunteer QA were centrally coordinated JIRA - bug tracking and release planning Release 2.0 Packaging: Release 2.0 Packaging Demo Unpack and start - one command Use Case: 'show your boss' Includes everything else: 60MB + Zip for Windows and tar.gz for UNIX Source Intended to configure and install for production - providers, skins, database connection, etc etc. Does not include pre-requisites Binary Pre-compiled version of source ready to drop into your Tomcat and configure Still to come…: Still to come… The new Common API portion of Framework II Hierarchy Sections and Groups (framework and tool changes) Improved Enterprise Integration including OSIDs WSRP portal integration More significant tool re-factor and redesign Producing uniform storage approach which works both for OSPI and Sakai IMS Tool Interoperability launcher Framework I: Framework I Framework I: Framework I Organically grown over five years Heavily influenced by Jakarta Jetspeed and CHEF During year one speed to release was of the essence Framework I = CHEF - Jetspeed and Turbine + Spring and JSF Used web app to store components to get class loader isolation Used Tomcat-specific advanced (and recent) features Sakai 1.5 Internal Design: Sakai 1.5 Internal Design Sakai 1.0 and 1.5 would be best characterized as 'monolithic Kernels' Good design and factoring between tools and Services Within the services - good use of interfaces throughout, but factoring is sub-optimal and dependencies are too complex Sakai 1.0 has User and role plug insn Sakai 1.5 adds course/site and improves role plug ins Sakai 1.5 had simple support for raw servlets developed at the last minute - used for Samigo and Xwiki Sakai 1.0: Sakai Service Implementations Sakai 1.0 Sakai Velocity Tools Sakai JSF Tools Sakai JSF Support Sakai Velocity Support Enterprise Data User Provider Role Provider Sakai 1.5: Sakai 1.5 Sakai Velocity Tools Sakai JSF Tools Sakai Service Implementations Sakai JSF Support Sakai Velocity Support Sakai Servlet Tools Sakai Servlet Filter Enterprise Data Role Provider User Provider Course Provider Framework II: Framework II Sakai 2.0 Internal Design: Sakai 2.0 Internal Design Significant re-factor of functionality SAF - Kernel Components/Spring Session, Tool registry, Identity Support for Sakai tools, basic servlets, web services, and webdav Thread conditioning, Servlet filter Kernel enables the other services SAF - Services Primary support APIs which for tool interactions SAF - Presentation Services JSF, Velocity, Servlet Major goal: Support for servlets, web services, and webdav using the Kernel SAF Design Documents: SAF Design Documents Sakai Tool Model Sakai Sessions Sakai Request Flow Sakai Mercury Portal Sakai Use of Maven Sakai Configuration Sakai Charon Portal Sakai Component Model Sakai Authentication These documents on collab.sakaiproject.org 'Sakai Development' Sakai 2.0 Services: Sakai 2.0 Services The Sakai Services are also re-factored SAF - Common Services File system, authentication, authorization, hierarchy, sites SAF - Framework Services Events, Portal, Navigation SAF - Application Services Chat, Discussion, Grading, Course Management, … Sakai 2.0Factoring: Sakai 2.0 Factoring Sakai Velocity Tools Sakai JSF Tools Enterprise Data Sakai JSF Support Sakai Velocity Support Sakai Servlet Tools Sakai Kernel and RequestFilter Sakai Common Services Sakai Framework Services Sakai Application Services Role Provider User Provider Course Provider SAF - Kernel: SAF - Kernel Does not go 'above' servlet level - 'provisions' a Sakai servlet (and its thread) to fully operate Elements (6900 lines of code) Components - Interaction with Spring to register/retrieve the Sakai API implementations with class-loader isolation Session httpSession - shared Sakai-wide for user/login sakaiSession - shared Sakai-wide for user/login sakaiToolSession - scoped by user/login/placement Tool registry - including support for 'helpers' Identity of current logged in user Utilities including thread local support SAF - Components: SAF - Components It is like container-wide Spring components, each with their own class loader In Sakai 1.0 and 1.5 we placed components in webapps to get the class loader isolation, but we ended up with load-order problems In Sakai 1.0 and 1.5 we 'bent' Spring to orchestrate Sakai components In Sakai 2.0 components simply appear 'in Spring' SAF-Components: tomcat/components component-1 WEB-INF components.xml classes lib component-2 WEB-INF components.xml classes lib tomcat/webapps/app1 WEB-INF web.xml ContextListener tomcat/webapps/app2 ComponentManager or Spring common/lib spring sakaiComponentManager Each component looks like a webapp, but with no web.xml. Each has classes and its own 'lib'. Their class loader uses common and shared. While it is not preferred, come components live in webapps. A ContextLoaderListener loads all of the components from a webapp. All globally registered components are available to Spring for injection (Interface names are the bean names) or via the Sakai ComponentManager API using Service Locator pattern. SAF-Components SAF-Components Benefits: SAF-Components Benefits Separate class loaders for each component, and each webapp Allows the jar footprint of one component not to be forced to overlap with all of the other components, tools, portal, etc. Multiple conflicting xerxes can be kept separate Adding/replacing a tool or component does not break things like the portal or other components Provides an EJB-like isolation but using Spring to connect components to client code SAF - Session: SAF - Session Tomcat Sessions leave much to be desired Cross-context dispatch issues (fights between Pluto and Tomcat - changes between dot versions) Not well suited for Web Services or WebDav when browser is not involved Lifecycle issues - can’t always count on cleanup Scope issues - Shared / Servlet / Portlet Sakai sessions solve all of these problems SAF-Session Scenarios: SAF-Session Scenarios Browser A WebDav Client WS or WSRP Client Tool X1 Tool Y1 Browser B Tool X2 Tool Y2 Renderer Servlet Tool X (Portlet) Tool Y (Servlet) Filter WebDav Servlet Axis Servlet Sakai APIs need logged in user, current session, etc. Filter Filter Cookie set via login or at SSO via WebISO Basic Auth (Cookie opt) WS Auth Session ID Re-dispatch Filter Filter Sakai Tool Registry: Sakai Tool Registry Each tool is self-contained in the source tree Tools self-deploy Kernel provides tool registry for portals to find tools and tools to find one another Helper model is presentation agnostic andlt;registrationandgt; andlt;tool id='sakai.presentation' title='Presentation' description='Presentation' andgt; andlt;category name='course' /andgt; andlt;category name='project' /andgt; andlt;/toolandgt; andlt;/registrationandgt; Goal: Isolate non-Portable stuff to Kernel: Goal: Isolate non-Portable stuff to Kernel SAF - Kernel + Filter Session, Identity, Components, Thread Setup Sakai Velocity Tools Sakai JSF Tools Sakai JSF Support Sakai Velocity Support Sakai Servlet Tools Sakai Common Services Sakai Framework Services Sakai Application Services Sakai 2.0 Elements: Sakai 2.0 Elements New Skin: New Skin Enterprise Integration: Enterprise Integration User, Realm, and Course plug ins Plug in APIs are still legacy Sample providers in release: JLDAP, OpenLDAP, Kerberos, and IMS Enterprise in a database Documentation needs to be improved for Realm and Course providers Will evolve this capability in the Enterprise WG Java Server Faces: Java Server Faces Most of the 2.0 effort was focused support of Samigo, Gradebook, and Melete - this evolved into the 'sakaix' tags Support for both MyFaces and Sun Reference Implementation Need to merge the sakai and sakaix tag set post 2.0 and complete cleanup Need to revisit the style guide now that we have some experience with style guide Web Services: Web Services Based on Axis 1.2 Release 2.0 includes sample PHP client Web Services Client Jakarta Axis Sakai APIs Sakai Kernel WS End Point Sakai Web Services Endpoint: Sakai Web Services Endpoint import org.sakaiproject.api.kernel.session.Session; import org.sakaiproject.api.kernel.session.cover.SessionManager; public class SakaiSession { public String checkSession(String id) { System.out.println('session id='+id); Session s = SessionManager.getSession(id); if (s == null) { System.out.println('no session established'); return 'Session Null'; } else { String resp = 'session: ' + s.getId() + ' user id: ' + s.getUserId() + ' user enterprise id: ' + s.getUserEid() + ' inactive after: ' + s.getMaxInactiveInterval(); System.out.println(resp); return resp; } } } Sakai Web Services Client: Sakai Web Services Client require_once('SOAP/Client.php'); if ( ! $_POST['url'] ) $_POST['url'] = 'http://nightly2.sakaiproject.org/sakai-axis/'; if ( $_POST['login'] ) { $site_url = $_POST['url'] . 'SakaiLogin.jws?wsdl'; echo ('Loggging in to Sakai Web Services at '.$site_url); $wsdl=new SOAP_WSDL($site_url); // Create an object directly from the proxy code $myProxy=$wsdl-andgt;getProxy(); $session=$myProxy-andgt;login('admin','admin'); echo ('Session:'); print_r ($session ); $_POST['session'] = $session; } Web Services Image: Web Services Image ~/dev/sakai2 csev$ find . -name '*.php' ./webservices/axis/test/basic/sakai_basic_test.php ~/dev/sakai2 csev$ RenderingArchitecture: Rendering Architecture Kernel Tool Registry Renderer Tool A Tool B Tool C Layout/Placement Information User’s Browser Request Filter Tool Dispatch and Helpers: Tool Dispatch and Helpers Kernel Tool Registry Renderer Tool Helper User’s Browser Request Filter To make use of a helper, a tool finds the helper by tool ID and then re-dispatches requests to the helper. Mercury: Mercury MercuryPortal: Mercury Portal Kernel Tool Registry Mercury Tool A Tool B Tool C User’s Browser Request Filter Charon Image: Charon Image CharonPortal: Charon Portal Kernel Tool Registry Charon Tool A Tool B Tool C Sakai Sites User’s Browser Request Filter Many Portals..: Many Portals.. Kernel Tool Registry Charon Tool A Tool B Tool C Browser Request Filter Mercury TILE? WSRP JSR-168 Browser uPortal Portal Browser Varuna Sedna Web Services Courier: Courier Based on XMLHttpRequest No more clicks! No more spinning browser icons. Not part of the portal - part of each tool Flexible in terms of timing - 60 seconds for presence - 10 seconds for chat Acessibility improved I18N and L10N: I18N and L10N JSF tools are bundle based University de Ledia - Added bundles to legacy tools This is just a start Need preferences and configuration L10N will identify flaws in the I18N Several languages are starting right away Discussion Group - Beth Kirshner and Alex Batiste Developer Issues: Developer Issues All in one CVS All one Eclipse - Eclipse files are nicely maintained nicely maintained Dependencies re-factored Can drop tools and components in and out trivially Demo = CVS + 'maven sakai' + zip A Few Concerns: A Few Concerns Change Courier to be Accessible, Accessible Rendering, Integrate hierarchy throughout - both features and throughout the legacy services - change context from 'Site Id' to 'Hierarchy Position' throughout, Url Mapping and a site navigator which shows children recursively, Build Sakai Filing and Repository APIs, Performance test hibernate for clustered applications, Build OSID covers for Sakai APIs and document OBAs, WSRP Integration, IMS Tool Portability - develop spec, write reference implementation, IMS Content Import throughout as necessary, IMS Enterprise support?, Gradebook - Finish / Rewrite, Samigo - Finish - Integrate with Gradebook, Refactor CVS to make solid core module and more optional modules - build and make process to assemble these automatically to make a release, Build connections between legacy and Sakai APIs - understand and solve impedance mismatches, Course Management API throughout, Hierarchy Management tools and building, Build OKI OSID plug in capabilities, Sakai APIs need to support plugins, Review and Revise Framework Further, Make sure to use Servlet Filters throughout and eliminate tunneling, Wholistic review of site info and worksite setup in terms of flow and usability, Re-Evaluate the use of locks (especially Site edit ting, Worksite setup, and all the admin tools), Evaluate legacy APIs for possible promotion, Support Search Throughout, Internationalization, Rewriting old tools, Accessibility throughout, Design and implement Helper Mode in JSF Tools - 'cross-tool navigation', Support for MS-SQL, Support for DC, and LOM and generic Metadata throughout with configurable Metadata editor and metadata editor helper, Take some time and get to the point where we truly bake in RDF, Design the low level resource model, Enhance the development, and debugging process. A Few Concerns: A Few Concerns Change Courier to be Accessible, Accessible Rendering, Integrate hierarchy throughout - both features and throughout the legacy services - change context from 'Site Id' to 'Hierarchy Position' throughout, Url Mapping and a site navigator which shows children recursively, Build Sakai Filing and Repository APIs, Performance test hibernate for clustered applications, Build OSID covers for Sakai APIs and document OBAs, WSRP Integration, IMS Tool Portability - develop spec, write reference implementation, IMS Content Import throughout as necessary, IMS Enterprise support?, Gradebook - Finish / Rewrite, Samigo - Finish - Integrate with Gradebook, Refactor CVS to make solid core module and more optional modules - build and make process to assemble these automatically to make a release, Build connections between legacy and Sakai APIs - understand and solve impedance mismatches, Course Management API throughout, Hierarchy Management tools and building, Build OKI OSID plug in capabilities, Sakai APIs need to support plugins, Review and Revise Framework Further, Make sure to use Servlet Filters throughout and eliminate tunneling, Wholistic review of site info and worksite setup in terms of flow and usability, Re-Evaluate the use of locks (especially Site edit ting, Worksite setup, and all the admin tools), Evaluate legacy APIs for possible promotion, Support Search Throughout, Internationalization, Rewriting old tools, Accessibility throughout, Design and implement Helper Mode in JSF Tools - 'cross-tool navigation', Support for MS-SQL, Support for DC, and LOM and generic Metadata throughout with configurable Metadata editor and metadata editor helper, Take some time and get to the point where we truly bake in RDF, Design the low level resource model, Enhance the development, and debugging process. Summary: Summary Important DG/WG’s: Important DG/WG’s I18N and L10N Enterprise Integration Framework Portal Integration Research Applications Content Library Technical Futures: Technical Futures Rob Lowden / Chuck Severance June 10, 2005 Sakai Beyond 2.0 - Features: Sakai Beyond 2.0 - Features None of this is a commitment - just the topics that will be on the minds of the development team after 2.0. Timeline: Timeline Sakai 2.0 is the right thing to run for the 2005-2006 school year 2.0.x releases will happen - bugs etc. Sakai 2.1 October/November timeframe May want to ignore this release T.O.S. Schools will likely run in January Sakai 3.0 will be Spring 2006 for Fall 2006 deploy This is now the general pattern. Is the numbering right? Users and Groups: Users and Groups This is a wide range of modifications to tools to make them 'Group Aware' Post an announcement to Whole site Group A Group B Set of tools to define groups (part of site - all you need is maintain role) Discussion Tool: Discussion Tool Needs to be improved *Everyone* has an opinion as to how to fix this Foothill is working on a discussion tool FYI: Look at Flowtalk - A simple E-Mail enhanced discussion tool that works in Sakai, CourseWork, etc. Melete Image: Melete Image Melete will be independently released as a 'drop-in' for 2.0. TwinPeaks: TwinPeaks Allows for pluggable search of online content repositories Include content in the WYSWIG editor Developed at Indiana University, DR OSID support added by MIT/OKI Demonstration by Jeff Kahn Slide56: Search as part of WYSIWYG Editor Slide57: Import / Export: Import / Export Needs to be much cleaner Syllabus profile gradebook Needs to be IMS Content Some code already exists in Melete Sakai Beyond 2.0 - Framework: Sakai Beyond 2.0 - Framework None of this is a commitment - just the topics that will be on the minds of the development team after 2.0. Hierarchy and Common APIs: Hierarchy and Common APIs Related to user’s and groups, but different - this is more infrastructure and access control inheritance up and down trees of sites Define user with read access to all courses in engineering Navigate to all engineering courses (up, down) Common APIs Agent, Authorization, etc. will get far more focus after 2.0 Providers will change Wide scale deployment likely to be Fall 2006 Accessiblity: Accessiblity Build iFrame free portal Portal part is relatively straightforward Tool use of frames (Chat, Discussion) needs to be handled Also investigating ways to make iFrames friendly (I.e. within Charon) Accessible notification Flexible presentation (like TILE) IMS Tool Portability Group: IMS Tool Portability Group To work on ‘interoperability’ between and among CMS’s/CLE’s Focus is on making tools portable between systems (Sakai, WebCT, and Blackboard) Established to further the discussion with commercial and other CMS/CLE providers Will use web services and IFRAMES Will show working demonstration at the July 2005 Alt-I-lab with Samigo in Sakai, WebCT, and Blackboard Sakai, IMS,and WebServices: Header Tool Area Button Button Button Button Button Button External Web Application Launch Control Session And Services Bootstrap Web Services Application Code 1 2 3 4 5 6 7 CLE Environment HTML/HTTP Web Services Sakai, IMS, and Web Services Sakai 1.5 and OSPI 2.0: Sakai 1.5 and OSPI 2.0 Sakai Resource Sakai Access Sakai WebDav Sakai Content API OSPI Resource OSPI Access OSPI WebDav OSPI Repo API OSPI Publish OSPI Tools Goal State Sakai/OSPI: Goal State Sakai/OSPI Superset Resource Superset Access Superset WebDav Superset Repo API OSPI Publish OSPI Tools Modified WSRP Activities: WSRP Activities SunGard-led and funded: Vishal Goenka Working with uPortal in their WSRP 3.0 effort As we really try to use WSRP, we identify issues in the standard and WSRP4J implementation Sakai and uPortal are becoming involved in WSRP standards activities and WSRP4J WSRP“Portal”: WSRP 'Portal' Kernel Tool Registry Sakai WSRP Tool A Tool B Tool C Sakai Sites Request Filter Apache WSRP4J WSRP Consumer Portal Web Services WSRP Placements WSRP Image: WSRP Image JSR-168: JSR-168 Goal state: Some of the Sakai tools operate as channels in uPortal Not trivially portable to other portals WSRP delivers the portability between portals WSRP is clearing the path in the architecture Working on summit similar to WSRP summit - really uPortal needs to be the lead here Because Kernel transparently sets up session, user identity, and thread in ways are opaque to the Sakai Tools and Services, we can create a new version of the Kernel to operate in a uPortal/JSR-168 environment.: Because Kernel transparently sets up session, user identity, and thread in ways are opaque to the Sakai Tools and Services, we can create a new version of the Kernel to operate in a uPortal/JSR-168 environment. uPortal’s JVM Sakai Velocity Tool Sakai JSF Tool uPortal Sakai Services, APIs, Components JSR-168 Velocity to JSR-168 JSF to JSR-168 SAF - Kernel - uPortal Version uPortal User, Site, Role Plug-ins Now You Are Just Talking Crazy!: Now You Are Just Talking Crazy! None of this is really on a schedule of any kind but we think about it when we get a free moment. The Future..: The Future.. In February, the board asked me to do a thought experiment… What if we had five more years with funding at $10 million per year? Cross Tool Search: Cross Tool Search It would be nice to add Lucene throughout This is 'Resource Object Model Stuff' This further breaks down stovepipes Access Control must be maintained How do we make sure that search includes your question pools, Melete modules, uploaded word files, chat messages, OSPI structured objects… New API Implementations: New API Implementations Chat Jabber Notification Jabber Calendar iCalendar Sakai, IMS,and WebServices: Header Tool Area Button Button Button Button Button Button External Web Application Launch Control Session And Services Bootstrap Web Services Application Code 1 2 3 4 5 6 7 CLE Environment HTML/HTTP Web Services Sakai, IMS, and Web Services Moodle: Moodle Tomcat Sakai Tool Moodle Tool Sakai Shim Apache IMS Launch Moodle Launch Header Tool Area Button Button Button Button Button Button HTML/HTTP Web Services This is a crazy idea with no way to figure out if this will work without giving it a try. Probably the most challenging will be storing back to Sakai. Sakai and Institutional Repositories: Sakai and Institutional Repositories Sakai will function as a collaborative environment in a wide range of applications Teaching and Learning Research and Cyber Infrastructure Ad hoc collaboration Increasingly these collaborative activities are considered to be producing valuable digital 'assets' and information worthy of long term storage and curation There is a natural synergy between Sakai and institutional repositories Inbound Object Flow: Inbound Object Flow Ingest Create and use in native form Prepare for storage Data Model Store Curate, convert, update and maintain over time Index Lens Search View Reuse IR Sakai The IR establishes a data model for 'site' objects. The CLE hands sites to the IR. The IR may have to do 'model' or content cleanup before completing the ingest process. The lens or disseminator understands the data model and is capable of rendering the objects. The lens is part of the IR. Outbound Object Flow: Outbound Object Flow Data Model Index Lens Search View Reuse IR Sakai Sakai can find and re-use objects in the repository. Data Model Lens View Search Reuse JSR-170 - Content Repository: JSR-170 - Content Repository Java Content Repository File-system plus metadata Replaces our ContentHosting API with a standard API Provides promise of plug ability of implementation including vendor-provided repositories JSR-170 Repository Sakai Other Apps IR …. June 2006: June 2006 Sakai running at 30 institutions, with 2 million daily users who are each using Sakai 20 times per day…. Making 10 million new 'learning resources' per day What do we do with these resources? How do we manage them? How do we find them? How do we reuse the resources? How do we recombine them to make new 'objects'? This is *not* Google - because these learning objects are all fine grained access controlled.. June 2006: June 2006 Sakai running at 30 institutions, with 2 million daily users who are each using Sakai 20 times per day…. Making 10 million new 'learning resources' per day What do we do with these resources? How do we manage them? How do we find them? How do we reuse the resources? How do we recombine them to make new 'objects'? This is *not* Google - because these resources are all fine grained access controlled.. Data Portability - Format Agnostic RDF - Resource Definition Format RDF Chicken or Egg?: RDF Chicken or Egg? RDF Protocols and Formats Sources of RDF Information Infrastructure JENA, etc.. Consumers of RDF Information * Infrastructure JENA, etc.. Sakai/RDF Dspace Fedora PiggyBank Haystack Annotea Data and Metadata Blogs Simile Simile RDFizers Longwell * A common approach in RDF is that consumers often consume, add value, and re-produce. RDF Chicken or Egg?: RDF Chicken or Egg? RDF Protocols and Formats Sources of RDF Information Infrastructure JENA, etc.. Consumers of RDF Information * Infrastructure JENA, etc.. Sakai/RDF Dspace Fedora PiggyBank Haystack Annotea Data and Metadata Blogs Simile Simile RDFizers Longwell * A common approach in RDF is that consumers often consume, add value, and re-produce. getData() RDF Producers: RDF Producers Adding RDF to repositories will make existing 'Curated Resources' available via RDF DSPACE Fedora EduCommons OCW Adding RDF to Sakai would create a massive source of 'Organic' Resources Interesting information - personal information, calendar entries, chat messages, e-Mail Educational objects Fine-grain access control More Ideas…: More Ideas… Add video conferencing orchestration to Sakai - VRVS ? Federated Sakai - Bringing together placements from many Sakai’s to one 'portal' through WSRP Offline Sakai - Download all of the data in a site, work with it off-line, upload and resynchronize Ajax Portal and JSF Render Kit Flash Portal Non-Web Clients - Desktop versions of Sakai ….. New Sakai Funding: New Sakai Funding Good News: Our funding is extended $10 Million per year - 5 years 400 * 2.5 * $100K = $10M Turn to the person sitting next to you and say 'thank you for the software.' There is a bit of an organizational problem yet to be solved… Summary: Summary Locally motivated distributed efforts Distributed Ownership Coordination is still needed - control not How to Contribute (now): How to Contribute (now) Distributed Leaders I give someone a picture on a napkin and tell them that 'you have 6 months' - keep in touch Individual contributors with committer mentors An existing committer runs interference does commits, helps fit into schedules, etc The next six months - the existing committers will be busy - but less so than the past 6 months - more time for mentors… Moodle: Moodle Tomcat Sakai Tool Moodle Tool Sakai Shim Apache IMS Launch Moodle Launch Header Tool Area Button Button Button Button Button Button HTML/HTTP Web Services This is a crazy idea with no way to figure out if this will work without giving it a try. Probably the most challenging will be storing back to Sakai. How to Communicate: How to Communicate Don’t be shy on the dev list! Matchmaker service - find others interested in the same thing When in doubt - ask. csev@umich.edu or Rob or a Board Member Q & A: Q andamp; A Any questions? Just do it! You do not have the permission to view this presentation. In order to view it, please contact the author of the presentation.
2005 06 09 sepp v05 Hufflepuff Download Post to : URL : Related Presentations : Share Add to Flag Embed Email Send to Blogs and Networks Add to Channel Uploaded from authorPOINT Insert YouTube videos in PowerPont slides with aS Desktop Copy embed code: (To copy code, click on the text box) Embed: URL: Thumbnail: WordPress Embed Customize Embed The presentation is successfully added In Your Favorites. Views: 235 Category: Education License: All Rights Reserved Like it (0) Dislike it (0) Added: June 24, 2007 This Presentation is Public Favorites: 0 Presentation Description No description available. Comments Posting comment... Premium member Presentation Transcript Sakai Architecture: Sakai Architecture Charles Severance Sakai Chief Architect June 8, 2005 A Bit of History: A Bit of History The first 'release' of Sakai was 12/03 Sakai was funded 01/04 Sakai 1.0 Alpha 02/04 A number of groups reviewed it technically and concluded that its internal structure was 'icky' Framework II proposed - 08/04 A cleanup/rewrite of the Sakai framework 08/04 We did not have time to stop and rewrite… FWII - Research/Design 08/04 - 01/05 More History: More History Sakai 1.0 released 10/04 Old framework - improved performance and reliability Sakai 1.5 was 02/05 Old framework - Samigo integrated Framework II started 01/04 Overlapped with 1.5 and 1.5.1 - slowly split focus and resources. Release 2.0: Release 2.0 Framework II kernel in place Integrated - Gradebook and Samigo Legacy tools internationalized Legacy tools improved to be partially compliant with the style guide. In summary, just about every end-user GUI element has been touched or is new. Web services The storage and services are still very 1.5-like New skin Release 2.0: Release 2.0 Framework II kernel in place Integrated - Gradebook and Samigo Legacy tools internationalized Legacy tools improved to be partially compliant with the style guide. In summary, just about every end-user GUI element has been touched or is new. Web services The storage and services are still very 1.5-like New skin Release Process 2.0: Release Process 2.0 Integration Week - May 16 - 20 Resulted in Release 2.0 Alpha 1 QA Led by Carol Dippel Both core and volunteer QA were centrally coordinated JIRA - bug tracking and release planning Release 2.0 Packaging: Release 2.0 Packaging Demo Unpack and start - one command Use Case: 'show your boss' Includes everything else: 60MB + Zip for Windows and tar.gz for UNIX Source Intended to configure and install for production - providers, skins, database connection, etc etc. Does not include pre-requisites Binary Pre-compiled version of source ready to drop into your Tomcat and configure Still to come…: Still to come… The new Common API portion of Framework II Hierarchy Sections and Groups (framework and tool changes) Improved Enterprise Integration including OSIDs WSRP portal integration More significant tool re-factor and redesign Producing uniform storage approach which works both for OSPI and Sakai IMS Tool Interoperability launcher Framework I: Framework I Framework I: Framework I Organically grown over five years Heavily influenced by Jakarta Jetspeed and CHEF During year one speed to release was of the essence Framework I = CHEF - Jetspeed and Turbine + Spring and JSF Used web app to store components to get class loader isolation Used Tomcat-specific advanced (and recent) features Sakai 1.5 Internal Design: Sakai 1.5 Internal Design Sakai 1.0 and 1.5 would be best characterized as 'monolithic Kernels' Good design and factoring between tools and Services Within the services - good use of interfaces throughout, but factoring is sub-optimal and dependencies are too complex Sakai 1.0 has User and role plug insn Sakai 1.5 adds course/site and improves role plug ins Sakai 1.5 had simple support for raw servlets developed at the last minute - used for Samigo and Xwiki Sakai 1.0: Sakai Service Implementations Sakai 1.0 Sakai Velocity Tools Sakai JSF Tools Sakai JSF Support Sakai Velocity Support Enterprise Data User Provider Role Provider Sakai 1.5: Sakai 1.5 Sakai Velocity Tools Sakai JSF Tools Sakai Service Implementations Sakai JSF Support Sakai Velocity Support Sakai Servlet Tools Sakai Servlet Filter Enterprise Data Role Provider User Provider Course Provider Framework II: Framework II Sakai 2.0 Internal Design: Sakai 2.0 Internal Design Significant re-factor of functionality SAF - Kernel Components/Spring Session, Tool registry, Identity Support for Sakai tools, basic servlets, web services, and webdav Thread conditioning, Servlet filter Kernel enables the other services SAF - Services Primary support APIs which for tool interactions SAF - Presentation Services JSF, Velocity, Servlet Major goal: Support for servlets, web services, and webdav using the Kernel SAF Design Documents: SAF Design Documents Sakai Tool Model Sakai Sessions Sakai Request Flow Sakai Mercury Portal Sakai Use of Maven Sakai Configuration Sakai Charon Portal Sakai Component Model Sakai Authentication These documents on collab.sakaiproject.org 'Sakai Development' Sakai 2.0 Services: Sakai 2.0 Services The Sakai Services are also re-factored SAF - Common Services File system, authentication, authorization, hierarchy, sites SAF - Framework Services Events, Portal, Navigation SAF - Application Services Chat, Discussion, Grading, Course Management, … Sakai 2.0Factoring: Sakai 2.0 Factoring Sakai Velocity Tools Sakai JSF Tools Enterprise Data Sakai JSF Support Sakai Velocity Support Sakai Servlet Tools Sakai Kernel and RequestFilter Sakai Common Services Sakai Framework Services Sakai Application Services Role Provider User Provider Course Provider SAF - Kernel: SAF - Kernel Does not go 'above' servlet level - 'provisions' a Sakai servlet (and its thread) to fully operate Elements (6900 lines of code) Components - Interaction with Spring to register/retrieve the Sakai API implementations with class-loader isolation Session httpSession - shared Sakai-wide for user/login sakaiSession - shared Sakai-wide for user/login sakaiToolSession - scoped by user/login/placement Tool registry - including support for 'helpers' Identity of current logged in user Utilities including thread local support SAF - Components: SAF - Components It is like container-wide Spring components, each with their own class loader In Sakai 1.0 and 1.5 we placed components in webapps to get the class loader isolation, but we ended up with load-order problems In Sakai 1.0 and 1.5 we 'bent' Spring to orchestrate Sakai components In Sakai 2.0 components simply appear 'in Spring' SAF-Components: tomcat/components component-1 WEB-INF components.xml classes lib component-2 WEB-INF components.xml classes lib tomcat/webapps/app1 WEB-INF web.xml ContextListener tomcat/webapps/app2 ComponentManager or Spring common/lib spring sakaiComponentManager Each component looks like a webapp, but with no web.xml. Each has classes and its own 'lib'. Their class loader uses common and shared. While it is not preferred, come components live in webapps. A ContextLoaderListener loads all of the components from a webapp. All globally registered components are available to Spring for injection (Interface names are the bean names) or via the Sakai ComponentManager API using Service Locator pattern. SAF-Components SAF-Components Benefits: SAF-Components Benefits Separate class loaders for each component, and each webapp Allows the jar footprint of one component not to be forced to overlap with all of the other components, tools, portal, etc. Multiple conflicting xerxes can be kept separate Adding/replacing a tool or component does not break things like the portal or other components Provides an EJB-like isolation but using Spring to connect components to client code SAF - Session: SAF - Session Tomcat Sessions leave much to be desired Cross-context dispatch issues (fights between Pluto and Tomcat - changes between dot versions) Not well suited for Web Services or WebDav when browser is not involved Lifecycle issues - can’t always count on cleanup Scope issues - Shared / Servlet / Portlet Sakai sessions solve all of these problems SAF-Session Scenarios: SAF-Session Scenarios Browser A WebDav Client WS or WSRP Client Tool X1 Tool Y1 Browser B Tool X2 Tool Y2 Renderer Servlet Tool X (Portlet) Tool Y (Servlet) Filter WebDav Servlet Axis Servlet Sakai APIs need logged in user, current session, etc. Filter Filter Cookie set via login or at SSO via WebISO Basic Auth (Cookie opt) WS Auth Session ID Re-dispatch Filter Filter Sakai Tool Registry: Sakai Tool Registry Each tool is self-contained in the source tree Tools self-deploy Kernel provides tool registry for portals to find tools and tools to find one another Helper model is presentation agnostic andlt;registrationandgt; andlt;tool id='sakai.presentation' title='Presentation' description='Presentation' andgt; andlt;category name='course' /andgt; andlt;category name='project' /andgt; andlt;/toolandgt; andlt;/registrationandgt; Goal: Isolate non-Portable stuff to Kernel: Goal: Isolate non-Portable stuff to Kernel SAF - Kernel + Filter Session, Identity, Components, Thread Setup Sakai Velocity Tools Sakai JSF Tools Sakai JSF Support Sakai Velocity Support Sakai Servlet Tools Sakai Common Services Sakai Framework Services Sakai Application Services Sakai 2.0 Elements: Sakai 2.0 Elements New Skin: New Skin Enterprise Integration: Enterprise Integration User, Realm, and Course plug ins Plug in APIs are still legacy Sample providers in release: JLDAP, OpenLDAP, Kerberos, and IMS Enterprise in a database Documentation needs to be improved for Realm and Course providers Will evolve this capability in the Enterprise WG Java Server Faces: Java Server Faces Most of the 2.0 effort was focused support of Samigo, Gradebook, and Melete - this evolved into the 'sakaix' tags Support for both MyFaces and Sun Reference Implementation Need to merge the sakai and sakaix tag set post 2.0 and complete cleanup Need to revisit the style guide now that we have some experience with style guide Web Services: Web Services Based on Axis 1.2 Release 2.0 includes sample PHP client Web Services Client Jakarta Axis Sakai APIs Sakai Kernel WS End Point Sakai Web Services Endpoint: Sakai Web Services Endpoint import org.sakaiproject.api.kernel.session.Session; import org.sakaiproject.api.kernel.session.cover.SessionManager; public class SakaiSession { public String checkSession(String id) { System.out.println('session id='+id); Session s = SessionManager.getSession(id); if (s == null) { System.out.println('no session established'); return 'Session Null'; } else { String resp = 'session: ' + s.getId() + ' user id: ' + s.getUserId() + ' user enterprise id: ' + s.getUserEid() + ' inactive after: ' + s.getMaxInactiveInterval(); System.out.println(resp); return resp; } } } Sakai Web Services Client: Sakai Web Services Client require_once('SOAP/Client.php'); if ( ! $_POST['url'] ) $_POST['url'] = 'http://nightly2.sakaiproject.org/sakai-axis/'; if ( $_POST['login'] ) { $site_url = $_POST['url'] . 'SakaiLogin.jws?wsdl'; echo ('Loggging in to Sakai Web Services at '.$site_url); $wsdl=new SOAP_WSDL($site_url); // Create an object directly from the proxy code $myProxy=$wsdl-andgt;getProxy(); $session=$myProxy-andgt;login('admin','admin'); echo ('Session:'); print_r ($session ); $_POST['session'] = $session; } Web Services Image: Web Services Image ~/dev/sakai2 csev$ find . -name '*.php' ./webservices/axis/test/basic/sakai_basic_test.php ~/dev/sakai2 csev$ RenderingArchitecture: Rendering Architecture Kernel Tool Registry Renderer Tool A Tool B Tool C Layout/Placement Information User’s Browser Request Filter Tool Dispatch and Helpers: Tool Dispatch and Helpers Kernel Tool Registry Renderer Tool Helper User’s Browser Request Filter To make use of a helper, a tool finds the helper by tool ID and then re-dispatches requests to the helper. Mercury: Mercury MercuryPortal: Mercury Portal Kernel Tool Registry Mercury Tool A Tool B Tool C User’s Browser Request Filter Charon Image: Charon Image CharonPortal: Charon Portal Kernel Tool Registry Charon Tool A Tool B Tool C Sakai Sites User’s Browser Request Filter Many Portals..: Many Portals.. Kernel Tool Registry Charon Tool A Tool B Tool C Browser Request Filter Mercury TILE? WSRP JSR-168 Browser uPortal Portal Browser Varuna Sedna Web Services Courier: Courier Based on XMLHttpRequest No more clicks! No more spinning browser icons. Not part of the portal - part of each tool Flexible in terms of timing - 60 seconds for presence - 10 seconds for chat Acessibility improved I18N and L10N: I18N and L10N JSF tools are bundle based University de Ledia - Added bundles to legacy tools This is just a start Need preferences and configuration L10N will identify flaws in the I18N Several languages are starting right away Discussion Group - Beth Kirshner and Alex Batiste Developer Issues: Developer Issues All in one CVS All one Eclipse - Eclipse files are nicely maintained nicely maintained Dependencies re-factored Can drop tools and components in and out trivially Demo = CVS + 'maven sakai' + zip A Few Concerns: A Few Concerns Change Courier to be Accessible, Accessible Rendering, Integrate hierarchy throughout - both features and throughout the legacy services - change context from 'Site Id' to 'Hierarchy Position' throughout, Url Mapping and a site navigator which shows children recursively, Build Sakai Filing and Repository APIs, Performance test hibernate for clustered applications, Build OSID covers for Sakai APIs and document OBAs, WSRP Integration, IMS Tool Portability - develop spec, write reference implementation, IMS Content Import throughout as necessary, IMS Enterprise support?, Gradebook - Finish / Rewrite, Samigo - Finish - Integrate with Gradebook, Refactor CVS to make solid core module and more optional modules - build and make process to assemble these automatically to make a release, Build connections between legacy and Sakai APIs - understand and solve impedance mismatches, Course Management API throughout, Hierarchy Management tools and building, Build OKI OSID plug in capabilities, Sakai APIs need to support plugins, Review and Revise Framework Further, Make sure to use Servlet Filters throughout and eliminate tunneling, Wholistic review of site info and worksite setup in terms of flow and usability, Re-Evaluate the use of locks (especially Site edit ting, Worksite setup, and all the admin tools), Evaluate legacy APIs for possible promotion, Support Search Throughout, Internationalization, Rewriting old tools, Accessibility throughout, Design and implement Helper Mode in JSF Tools - 'cross-tool navigation', Support for MS-SQL, Support for DC, and LOM and generic Metadata throughout with configurable Metadata editor and metadata editor helper, Take some time and get to the point where we truly bake in RDF, Design the low level resource model, Enhance the development, and debugging process. A Few Concerns: A Few Concerns Change Courier to be Accessible, Accessible Rendering, Integrate hierarchy throughout - both features and throughout the legacy services - change context from 'Site Id' to 'Hierarchy Position' throughout, Url Mapping and a site navigator which shows children recursively, Build Sakai Filing and Repository APIs, Performance test hibernate for clustered applications, Build OSID covers for Sakai APIs and document OBAs, WSRP Integration, IMS Tool Portability - develop spec, write reference implementation, IMS Content Import throughout as necessary, IMS Enterprise support?, Gradebook - Finish / Rewrite, Samigo - Finish - Integrate with Gradebook, Refactor CVS to make solid core module and more optional modules - build and make process to assemble these automatically to make a release, Build connections between legacy and Sakai APIs - understand and solve impedance mismatches, Course Management API throughout, Hierarchy Management tools and building, Build OKI OSID plug in capabilities, Sakai APIs need to support plugins, Review and Revise Framework Further, Make sure to use Servlet Filters throughout and eliminate tunneling, Wholistic review of site info and worksite setup in terms of flow and usability, Re-Evaluate the use of locks (especially Site edit ting, Worksite setup, and all the admin tools), Evaluate legacy APIs for possible promotion, Support Search Throughout, Internationalization, Rewriting old tools, Accessibility throughout, Design and implement Helper Mode in JSF Tools - 'cross-tool navigation', Support for MS-SQL, Support for DC, and LOM and generic Metadata throughout with configurable Metadata editor and metadata editor helper, Take some time and get to the point where we truly bake in RDF, Design the low level resource model, Enhance the development, and debugging process. Summary: Summary Important DG/WG’s: Important DG/WG’s I18N and L10N Enterprise Integration Framework Portal Integration Research Applications Content Library Technical Futures: Technical Futures Rob Lowden / Chuck Severance June 10, 2005 Sakai Beyond 2.0 - Features: Sakai Beyond 2.0 - Features None of this is a commitment - just the topics that will be on the minds of the development team after 2.0. Timeline: Timeline Sakai 2.0 is the right thing to run for the 2005-2006 school year 2.0.x releases will happen - bugs etc. Sakai 2.1 October/November timeframe May want to ignore this release T.O.S. Schools will likely run in January Sakai 3.0 will be Spring 2006 for Fall 2006 deploy This is now the general pattern. Is the numbering right? Users and Groups: Users and Groups This is a wide range of modifications to tools to make them 'Group Aware' Post an announcement to Whole site Group A Group B Set of tools to define groups (part of site - all you need is maintain role) Discussion Tool: Discussion Tool Needs to be improved *Everyone* has an opinion as to how to fix this Foothill is working on a discussion tool FYI: Look at Flowtalk - A simple E-Mail enhanced discussion tool that works in Sakai, CourseWork, etc. Melete Image: Melete Image Melete will be independently released as a 'drop-in' for 2.0. TwinPeaks: TwinPeaks Allows for pluggable search of online content repositories Include content in the WYSWIG editor Developed at Indiana University, DR OSID support added by MIT/OKI Demonstration by Jeff Kahn Slide56: Search as part of WYSIWYG Editor Slide57: Import / Export: Import / Export Needs to be much cleaner Syllabus profile gradebook Needs to be IMS Content Some code already exists in Melete Sakai Beyond 2.0 - Framework: Sakai Beyond 2.0 - Framework None of this is a commitment - just the topics that will be on the minds of the development team after 2.0. Hierarchy and Common APIs: Hierarchy and Common APIs Related to user’s and groups, but different - this is more infrastructure and access control inheritance up and down trees of sites Define user with read access to all courses in engineering Navigate to all engineering courses (up, down) Common APIs Agent, Authorization, etc. will get far more focus after 2.0 Providers will change Wide scale deployment likely to be Fall 2006 Accessiblity: Accessiblity Build iFrame free portal Portal part is relatively straightforward Tool use of frames (Chat, Discussion) needs to be handled Also investigating ways to make iFrames friendly (I.e. within Charon) Accessible notification Flexible presentation (like TILE) IMS Tool Portability Group: IMS Tool Portability Group To work on ‘interoperability’ between and among CMS’s/CLE’s Focus is on making tools portable between systems (Sakai, WebCT, and Blackboard) Established to further the discussion with commercial and other CMS/CLE providers Will use web services and IFRAMES Will show working demonstration at the July 2005 Alt-I-lab with Samigo in Sakai, WebCT, and Blackboard Sakai, IMS,and WebServices: Header Tool Area Button Button Button Button Button Button External Web Application Launch Control Session And Services Bootstrap Web Services Application Code 1 2 3 4 5 6 7 CLE Environment HTML/HTTP Web Services Sakai, IMS, and Web Services Sakai 1.5 and OSPI 2.0: Sakai 1.5 and OSPI 2.0 Sakai Resource Sakai Access Sakai WebDav Sakai Content API OSPI Resource OSPI Access OSPI WebDav OSPI Repo API OSPI Publish OSPI Tools Goal State Sakai/OSPI: Goal State Sakai/OSPI Superset Resource Superset Access Superset WebDav Superset Repo API OSPI Publish OSPI Tools Modified WSRP Activities: WSRP Activities SunGard-led and funded: Vishal Goenka Working with uPortal in their WSRP 3.0 effort As we really try to use WSRP, we identify issues in the standard and WSRP4J implementation Sakai and uPortal are becoming involved in WSRP standards activities and WSRP4J WSRP“Portal”: WSRP 'Portal' Kernel Tool Registry Sakai WSRP Tool A Tool B Tool C Sakai Sites Request Filter Apache WSRP4J WSRP Consumer Portal Web Services WSRP Placements WSRP Image: WSRP Image JSR-168: JSR-168 Goal state: Some of the Sakai tools operate as channels in uPortal Not trivially portable to other portals WSRP delivers the portability between portals WSRP is clearing the path in the architecture Working on summit similar to WSRP summit - really uPortal needs to be the lead here Because Kernel transparently sets up session, user identity, and thread in ways are opaque to the Sakai Tools and Services, we can create a new version of the Kernel to operate in a uPortal/JSR-168 environment.: Because Kernel transparently sets up session, user identity, and thread in ways are opaque to the Sakai Tools and Services, we can create a new version of the Kernel to operate in a uPortal/JSR-168 environment. uPortal’s JVM Sakai Velocity Tool Sakai JSF Tool uPortal Sakai Services, APIs, Components JSR-168 Velocity to JSR-168 JSF to JSR-168 SAF - Kernel - uPortal Version uPortal User, Site, Role Plug-ins Now You Are Just Talking Crazy!: Now You Are Just Talking Crazy! None of this is really on a schedule of any kind but we think about it when we get a free moment. The Future..: The Future.. In February, the board asked me to do a thought experiment… What if we had five more years with funding at $10 million per year? Cross Tool Search: Cross Tool Search It would be nice to add Lucene throughout This is 'Resource Object Model Stuff' This further breaks down stovepipes Access Control must be maintained How do we make sure that search includes your question pools, Melete modules, uploaded word files, chat messages, OSPI structured objects… New API Implementations: New API Implementations Chat Jabber Notification Jabber Calendar iCalendar Sakai, IMS,and WebServices: Header Tool Area Button Button Button Button Button Button External Web Application Launch Control Session And Services Bootstrap Web Services Application Code 1 2 3 4 5 6 7 CLE Environment HTML/HTTP Web Services Sakai, IMS, and Web Services Moodle: Moodle Tomcat Sakai Tool Moodle Tool Sakai Shim Apache IMS Launch Moodle Launch Header Tool Area Button Button Button Button Button Button HTML/HTTP Web Services This is a crazy idea with no way to figure out if this will work without giving it a try. Probably the most challenging will be storing back to Sakai. Sakai and Institutional Repositories: Sakai and Institutional Repositories Sakai will function as a collaborative environment in a wide range of applications Teaching and Learning Research and Cyber Infrastructure Ad hoc collaboration Increasingly these collaborative activities are considered to be producing valuable digital 'assets' and information worthy of long term storage and curation There is a natural synergy between Sakai and institutional repositories Inbound Object Flow: Inbound Object Flow Ingest Create and use in native form Prepare for storage Data Model Store Curate, convert, update and maintain over time Index Lens Search View Reuse IR Sakai The IR establishes a data model for 'site' objects. The CLE hands sites to the IR. The IR may have to do 'model' or content cleanup before completing the ingest process. The lens or disseminator understands the data model and is capable of rendering the objects. The lens is part of the IR. Outbound Object Flow: Outbound Object Flow Data Model Index Lens Search View Reuse IR Sakai Sakai can find and re-use objects in the repository. Data Model Lens View Search Reuse JSR-170 - Content Repository: JSR-170 - Content Repository Java Content Repository File-system plus metadata Replaces our ContentHosting API with a standard API Provides promise of plug ability of implementation including vendor-provided repositories JSR-170 Repository Sakai Other Apps IR …. June 2006: June 2006 Sakai running at 30 institutions, with 2 million daily users who are each using Sakai 20 times per day…. Making 10 million new 'learning resources' per day What do we do with these resources? How do we manage them? How do we find them? How do we reuse the resources? How do we recombine them to make new 'objects'? This is *not* Google - because these learning objects are all fine grained access controlled.. June 2006: June 2006 Sakai running at 30 institutions, with 2 million daily users who are each using Sakai 20 times per day…. Making 10 million new 'learning resources' per day What do we do with these resources? How do we manage them? How do we find them? How do we reuse the resources? How do we recombine them to make new 'objects'? This is *not* Google - because these resources are all fine grained access controlled.. Data Portability - Format Agnostic RDF - Resource Definition Format RDF Chicken or Egg?: RDF Chicken or Egg? RDF Protocols and Formats Sources of RDF Information Infrastructure JENA, etc.. Consumers of RDF Information * Infrastructure JENA, etc.. Sakai/RDF Dspace Fedora PiggyBank Haystack Annotea Data and Metadata Blogs Simile Simile RDFizers Longwell * A common approach in RDF is that consumers often consume, add value, and re-produce. RDF Chicken or Egg?: RDF Chicken or Egg? RDF Protocols and Formats Sources of RDF Information Infrastructure JENA, etc.. Consumers of RDF Information * Infrastructure JENA, etc.. Sakai/RDF Dspace Fedora PiggyBank Haystack Annotea Data and Metadata Blogs Simile Simile RDFizers Longwell * A common approach in RDF is that consumers often consume, add value, and re-produce. getData() RDF Producers: RDF Producers Adding RDF to repositories will make existing 'Curated Resources' available via RDF DSPACE Fedora EduCommons OCW Adding RDF to Sakai would create a massive source of 'Organic' Resources Interesting information - personal information, calendar entries, chat messages, e-Mail Educational objects Fine-grain access control More Ideas…: More Ideas… Add video conferencing orchestration to Sakai - VRVS ? Federated Sakai - Bringing together placements from many Sakai’s to one 'portal' through WSRP Offline Sakai - Download all of the data in a site, work with it off-line, upload and resynchronize Ajax Portal and JSF Render Kit Flash Portal Non-Web Clients - Desktop versions of Sakai ….. New Sakai Funding: New Sakai Funding Good News: Our funding is extended $10 Million per year - 5 years 400 * 2.5 * $100K = $10M Turn to the person sitting next to you and say 'thank you for the software.' There is a bit of an organizational problem yet to be solved… Summary: Summary Locally motivated distributed efforts Distributed Ownership Coordination is still needed - control not How to Contribute (now): How to Contribute (now) Distributed Leaders I give someone a picture on a napkin and tell them that 'you have 6 months' - keep in touch Individual contributors with committer mentors An existing committer runs interference does commits, helps fit into schedules, etc The next six months - the existing committers will be busy - but less so than the past 6 months - more time for mentors… Moodle: Moodle Tomcat Sakai Tool Moodle Tool Sakai Shim Apache IMS Launch Moodle Launch Header Tool Area Button Button Button Button Button Button HTML/HTTP Web Services This is a crazy idea with no way to figure out if this will work without giving it a try. Probably the most challenging will be storing back to Sakai. How to Communicate: How to Communicate Don’t be shy on the dev list! Matchmaker service - find others interested in the same thing When in doubt - ask. csev@umich.edu or Rob or a Board Member Q & A: Q andamp; A Any questions? Just do it!