Sakai Technical Update and Futures Charles Severance Sakai Chief Architect September 15,

Release 2.0 New kernel in place New learning-oriented tools 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 Integration Week - May –Resulted in Release 2.0 Alpha 1 QA –Led by Carol Dippel –Both core and volunteer QA were centrally coordinated JIRA - heavily used bug tracking and release management Released June 15, 2005

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

Sakai 2.0 Framework Changes

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: Clean support for servlets, web services, and webdav using the Kernel

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 others These documents on collab.sakaiproject.org “Sakai Development”

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

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, some 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 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 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 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 Cookie set via login or at SSO via WebISO Basic Auth (Cookie opt) WS Auth Session ID Re-dispatch Filter

Web Services Web Services allow flexible reuse of API and services in contexts beyond the Sakai interfaces –WSRP presentation –SOAP - RPC Web Services Issues –Security –Performance –API needs to tend towards document-style rather than RPC-style

Web Services Web Services shipped in Sakai 2.0 Based on Axis 1.2 Release 2.0 includes sample PHP client Web Services Client Jakarta Axis Sakai APIs Sakai Kernel WS End Point Samples Only Available in Sakai 2.0

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 require_once('SOAP/Client.php'); if ( ! $_POST['url'] ) $_POST['url'] = " 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->getProxy(); $session=$myProxy->login("admin","admin"); echo ("Session:"); print_r ($session ); $_POST['session'] = $session; }

Rendering Architecture Kernel Tool Registry Renderer Tool ATool BTool C Layout/Placement Information User’s Browser Request Filter

Mercury

Mercury Portal Kernel Tool Registry Mercury Tool ATool BTool C User’s Browser Request Filter

Charon Image

Charon Portal Kernel Tool Registry Charon Tool ATool BTool C Sakai Sites Request Filter

Many Portals.. Kernel Tool Registry Charon Tool ATool BTool C Browser Request Filter MercuryTILE?WSRPJSR-168 Browser uPortalPortal Browser Varuna Sedna Web Services

Sakai 2.0 New Elements

Visible Aspects New Skin Style Guide Significantly Improved WorkStite Setup –Pretty much can completely admin a site without the admin tools Resources Tool Metadata Internationalization Improved Courier

New Skin

Style Guide

Metadata on all Resources

Courier - Event Delivery 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 Login timeout now 30 minutes Acessibility improved

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

Configuring Sakai 2.0 Locally

Providers in Sakai 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/Site Provider

User Directory Provider Very mature - since Sakai 1.0 User type is controlled by provider - this controls the user template when the user is created Can provide fully populated User objects or just answer ID/PW queries Consulted at log-in Supports special “properties” known to the provider Sample providers in release 2.0: JLDAP, OpenLDAP, Kerberos, and IMS Enterprise in a database

Course Provider Does not auto-populate courses Provides the course list when instructor is making a new worksite Consulted during “New Site” operation Significant work needed here –Need to make into a Site provider –Need to be able to set site type from provider –Need to come up with auto population mechanism

public List getInstructorCourses(String instructorId, String termYear, String termTerm) ID: 2005,FALL,,SMPL,001,001 TERMID: FALL 2005 TITLE: Sample Course

Exploding the Course ID AT UM 2005,FALL,A,SMPL,001,001 Course SectionUnit Campus This is like a GUID - Not the user visible Title. public String getCourseName(String courseId) Are there any semantics on this ID beyond a GUID?

2002,2,A,EDUC,504,[001,002,003,004,006]+2002,2,A,LSA,101,[002,003] Two External “Courses” Five Sections Two Sections When Multiple Course ID’s are checked…

Exploding the External Provider ID 2002,2,A,EDUC,504,[001,002,003,004,006]+2002,2,A,LSA,101,[002,003] Realm Information comes from these Course ID’s: 2002,2,A,EDUC,504, ,2,A,EDUC,504, ,2,A,EDUC,504, ,2,A,EDUC,504, ,2,A,EDUC,504, ,2,A,LSA,101, ,2,A,LSA,101,003

Realm Provider (Role) Consulted at login What are the sites and roles within each site for this user If the system is using many different roles throughout, this code must feed the proper site the proper role Sakai internal tables are updated as changes from the provider are noticed.

Site: FFEB Type: Course Realm: /site/FFEB E-Provider: 2002,2,A,EDUC,504,[00 1,002,003,004,006]+ 2002,2,A,LSA,101,[002, 003] Title: SI Student: chat.read Instructor: chat.read, chat.delete Chuck is Maintain Active/Internal 2002,2,A,EDUC,504,[001,002,003,004,006]+2002,2,A,LSA,101,[002,003] When Worksite Setup is Done

Site: FFEB Type: Course Realm: /site/FFEB E-Provider: 2002,2,A,EDUC,504,[00 1,002,003,004,006]+ 2002,2,A,LSA,101,[002, 003] Title: SI Student: chat.read Instructor: chat.read, chat.delete Chuck Maintain Active/Internal Glenn is Student Active/External David is StudentDavid is TA Active/Internal Internal wins Zhen is Student Inactive/Internal Glenn is Student Zhen is Student Internal wins to protect. Inactive over rides Provided roles

Production Configurations

Important Production Choices Operating System –Linux (*), Solaris, X/Serve, AIX, Windows Data Base –Oracle (*), MySql, HSQL Configuration –One System –Separate DB Server –Clustered application servers (*)

Deployment Configurations Developer/Demo - Hypersonic SQL MySql –Medium sized systems Oracle –Large systems Clustered –Multiple application servers

Developer WorkStation Sakai HSQL Database Developer Environment HSQL database –In memory –On file Easy to use/configure HSQL is Open Source so it can be included with Sakai’s distribution Sometimes runs “too fast” because it is in memory

Server Sakai MySql Database Small/Medium Production System MySql database Application and database can be on same server Placing on same server simplifies some performance tuning Pair of fast 2-CPU systems or one 4-CPU system should support 200+ simultaneous users Database Server Application Server Sakai MySql Database

Server Sakai Oracle Database Sakai Application Server Cluster IP Sprayer Large Production Environment

Sakai Beyond Framework

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 resource model approach which works both for OSP and Sakai IMS Tool Interoperability launcher

Top Priority for 2.1 The ability to define subsections within a class The ability to control the display or sorting of objects (like announcements) based on section membership The ability to sort and filter data within tools (like the grade book) based on section membership and other section information such as role The ability to control within Sakai the membership and roles of sections within courses. This is called the “Section Tool”.

Group Scoped Permissions Essentially in Sakai 2.0, each site has one “participant list” and each participant gets a “permission set/role” In Sakai 2.1 we will make it possible to create, maintain, and manage multiple “participant lists” per site - in a learning context these new lists would be though of as sections For the rest of this document I will call these “sections” just for simplicity but the concepts apply equally to groups within sites.

Current 2.0 Structures Site: CS1 Roster: CS1 dogle zhen csev lance marc In TA St In: rwd TA: rw St: r ID: F05 CS1 A dogle csev lance In TA St ID: F05 CS1 B dogle zhen marc In TA St Course/Realm Providers

Structures in 2.1 Site: CS1 Roster: CS1 B dogle csev lance In TA St Roster: CS1 A dogle zhen marc In TA St In: rwd TA: rwd St: r In: rwd TA: rwd St: r Roster: CS1 dogle zhen csev lance marc In TA St In: rwd TA: r St: r ID: F05 CS1 A dogle csev lance In TA St ID: F05 CS1 B dogle zhen marc In TA St

Section Tool Site: CS1 Roster: CS1 B dogle csev lance In TA St Roster: CS1 A dogle zhen marc In TA St In: rwd TA: rwd St: r In: rwd TA: rwd St: r Roster: CS1 dogle zhen csev lance marc In TA St In: rwd TA: r St: r ID: F05 CS1 Section Tool

Sakai 2.1 Section Aware GUI - Subgroup Publishing Display to Non-Members Display to Members (default) Display to Selected SubGroups Section 001 Section 002 Section 003

Security Implications Site: CS1 R:SEC 002 R:CS1 R:SEC 001 R:SEC 003 A51 A52 Selected SubGroups SEC 001 SEC 002 SEC 003 Display to Members Selected SubGroups SEC 001 SEC 002 SEC 003 Display to Members Selected SubGroups Display to Members A57

GUI Pseudo Code - Inst List View Filter by CS1 SEC 001 SEC 002 SEC 003 CreatorTitle InstWelcome to All Students revise | delete TA 001Handouts now at Kinkos revise | delete TA 002Meeting location: MUJO revise | delete INSTSwap rooms for sections 002 and 003 revise | delete NEW

TA 002 List View Filter by CS1 SEC 002 CreatorTitle InstWelcome to All Students TA 002Meeting location: MUJO revise | delete INSTSwap rooms for sections 002 and 003 NEW

Student 002 List View Filter by CS1 SEC 002 CreatorTitle InstWelcome to All Students TA 002Meeting location: MUJO INSTSwap rooms for sections 002 and 003

Instructor New Announcement Display to Non-Members Display to Members (default) Display to Selected SubGroups Section 001 Section 002 Section 003

TA 002 New Announcement

TA 002/003 New Announcement Display to Selected SubGroups Section 002 Section 003

Lots of Flexibility While the examples were somewhat simple, there is a lot of flexiblity in this approach. –When a TA has multiple sections, they could use these capabilities across their sections –A person can be a student in one section and a TA in another section and things continue to work –The mapping between sections and external provider IDs can be as flexible as worksite setup’s GUI can handle (or as flexible as your web-services admin code wants to be).

Moving to Hierarchy This approach is compatible with hierarchy - the course- wide/site-wide roster will be the roster which participates in the hierarchical inheritance. With hierarchy *and* sections/groups we will have great flexibility in multi-section situations –Map all sections to a single site –Map all sections to a single site with sub-rosters –Map all sections to a course site and create a sub-site for each section with inheritance –Map all sections to a course site with sub-rosters and still create section-scoped sub-sites for each section

N20 N17N19 G50 access G49 maintain G49 maintain N18 G50/TA G50/Learner maintain access Hierarchical Objects/ Entities A53 A51 A52 Selected SubGroups N17/G50 N18/G51 N19/G52 Display to Members Selected SubGroups N17/G50 N18/G51 N19/G52 Display to Members Selected SubGroups Display to Members A56 A57

N1 N15 N16 N20 N17N19 S15 ANNC Sched G50 access G49 maintain access N18 G50/TA G50/Learner maintain access Adding un- Blockable grants G51 G52 G52/TA G52/Learner maintain access G86 access G85 *.* G87 S11 ANNC Sched maintain

Sakai Beyond Features

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 Focus is on making tools portable between systems (Sakai, WebCT, and Blackboard) Established to further the discussion with commercial and other CMS/CLE providers Uses web services and IFRAMES Does not require tools to be written in Java Working demonstration at the July 2005 Alt-I-lab with Samigo in Sakai, WebCT, Moodle, and Blackboard Will be released as part of Sakai 2.1

JVM Sakai Sakai APIs Samigo, ConceptTutor, Etc Sakai IMS Proxy Session And Services Bootstrap Sakai Web Services Application Code Launch Outcome

IMS Common Cartridge Goal: Produce specification describing one identical IMS Content Package which can be imported into Sakai, WebCT, Blackboard and others Requirement: Richer capabilities –Files –Discussion Threads –QTI (improved profile) –Modules (Melete) Weekly meetings - focused on demo at Alt-I-Lab 2006 Progress is good - WebCT is taking leadership in building specification

TwinPeaks Allows for pluggable search of data repositories for use in Sakai sites in various contexts Developed at Indiana University, DR OSID support added by MIT/OKI –Include content in the WYSWIG editor Should be in release may be part of the resource picker and usable across the entire system.

Search as part of WYSIWYG Editor TwinPeaks: Searching Data Repositories

Open Source Portfolio (OSP) In Sakai 1.0 and Sakai 1.5, the related OSP release was a “permanent” fork –Separate QA effort –Each new OSP release starts from “scratch” After Sakai 2.0, OSP needed framework changes are added to the Sakai 2.1 SVN Future OSP releases will not be “fork-style” releases

Sakai 1.5 and OSP 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/OSP Superset Resource Superset Access Superset WebDav Superset Repo API OSPI Publish OSPI Tools Modified

Structured Objects Structured Object OSP Structured Objects in Sakai

Sakai Portal and Repository Integration Approach

Sakai’s Initial Value Proposition Collaboration Software

Sakai’s Real Scope Data Repositories Resources Portals Collaboration Software

Integration Portal –WSRP - Web Services for Remote Portals –JSR Portlet API Data Repositories –Data –Library

Collaboration.vs. Portal Basic organization is about the thing it represents - Teragrid, NVO Site customization is based on the resource owners Sometimes there is an individual customization aspect Many small rectangles to provide a great deal of information on a single screen Portals think of rectangles operating independently - like windows Think “Dashboard” Basic organization is about the shape of the people and groups Customization based on the “group leaders” New groups form quickly and organically Doing one thing at a time - chat, upload - perhaps multiple active windows on a desktop Very interactive Think of navigation as picking a tool or switching from one class to another Think “Application”

Sakai Portal Integration Steps Use iFrames and Charon –Highly Portable - manual configuration - separate rendering Sakai JSR-168 Web Service Portlet –Highly portable - automatic configuration - separate rendering Web Services for Remote Portlets (WSRP) –Highly portable - manual configuration - coordinated rendering Sakai integrated into uPortal 3.0 –Not portable - automatic configuration - coordinated rendering

Login Branding Site Selection Tool Selection Tool Area Presence Sakai’s Rectangles

Charon Subset URLs

Sakai JSR-168 Portlet Very similar to the Sakai Desktop I wrote in Visual Basic Web Services are used to login to Sakai establish a session and retrieve a list of Sakai Sites and IDs. These are presented in the Portlet and as the user navigates between sites, an embedded iframe is used to show the site. The portlet is 100% stock JSR-168 –Works in Pluto, uPortal, and GridSphere

Sakai Portlet

Features Preferences –Sakai host, account, iframe height Automatic login –The portlet can be configured system-wide to have a designated Sakai host that people are to be automatically logged in. –A shared secret between the portlet and the Sakai system allows bypass of any Sakai log in. –There must be a Sakai account for each portal account. But if the account exists and the shared secrets match, integration is seamless

Preferences

How it Works uPortal, Pluto, or GridSphere Sakai Web Svcs Charon Portal Sakai Portlet Login SiteList

uPortal Thanks to Marcus Christie, Indiana University for the uPortal screen shot

GridSphere Thanks to Marcus Christie, Indiana University for the GridSphere screen shot

Pluto

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

Sakai tool HTTP WSRP Portal Sakai tool HTTP Sakai tool HTTP Non-Sakai Non-Java Tools tool WSRP Non-Sakai Tool WSRP WSRP Use Case

WSRP “Portal” Kernel Tool Registry Sakai WSRP Tool ATool BTool C Sakai Sites Request Filter Apache WSRP4J WSRP Consumer Portal Web Services WSRP Placements

WSRP Image

Sakai / uPortal Integration Sakai and uPortal in same Tomcat Sakai becomes “pushed fragment” by adding component to uP3 render pipeline –Sakai iFrame portlet –Sakai JSR-168 portlet for tools capable of producing “fragment” responses Sakai placements can be subscribed as channels/fragments Sakai tools appear as placeable channels This is a lot of work and all we have are initial designs

uPortal/Sakai uPortal’s Tomcat uPortal iFrame JSR-168 uPortal 3.0 uPortal GAPS uPortal Render Pipeline Users Sites and Placements User Plug-in GAPs Plug-ins Groups Placements Sakai uPortal

Sakai Repository Integration Approach

High Level View Data Repository Collaborative And Learning System Data Sources Publishing Activities Research Activities The data is the constant across applications and technologies.

Collaboration.vs. Repository Many different systems may be active at the same time Systems evolve, improve, and are often replaced every few years Systems focused on the dynamic needs of users and applications Thousands of simultaneous online users Performance tuning Must be very easy to use; almost unnoticeable Used informally hundreds of times per day per user Think “ ” Generally one system for the area Long term strategic choice for institution System focused on accessing, indexing, curation, and storage Millions of high quality objects properly indexed Data and metadata quality Must enforce standards and workflow to insure data quality Most use is very purposeful: search, publish, add value Think “Library”

Inbound Object Flow Ingest Create and use in native form Prepare for storage Data Model Store Curate, convert, update and maintain over time IndexLens Search View Reuse DRSakai The DR establishes a data model for “site” objects. The CLE hands sites to the DR. The DR 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 DR. Preparation for storage may include cleanup, conversion, copyright clearance, and other workflow steps.

Outbound Object Flow Data Model IndexLens Search View Reuse DR Sakai Sakai can find and re-use objects in the repository. Data Model Lens ViewSearch Reuse

Data Repository Technologies DSpace - is a connected set of features that includes repository, delivery mechanisms, and both user and administrative interfaces. OCW - IR focused on long term archival of teaching and learning material IBM Content Manager - Highly media oriented IR Fedora - has been developed primarily as a “repository” without a specific user interface Artstor - is an example of a repository that is cross- institutional built around particular collection and technologies to manage that collection

Will there ever be “one” Data Repository? Each current repository project covers a particular space / technology. Problems like long-term curation, extremely complex objects, rich media understanding are difficult to do in the general case. Some short term localized convergence may happen as one project adopts technology from another. Data portability between systems is the needed innovation to make IR choice more transparent.

Going Forward Instead of solving the problem by creating a single DR technology that is a superset - which might take years Focus on data portability between systems - reduce the impedance mismatch (or needed conversion between systems) RDF enables object portability across systems, languages, and technologies

Tangible Steps for Sakai Move Sakai and other Collaboration systems toward RDF –Experiment with using RDF as native storage format instead of relational or file-system –RDF has yet to demonstrate scalable performance needed for >100K active users - this is a research area Move data repositories toward RDF –Move from schema-based stovepipe objects to OWL/RDF based objects with referential integrity –Explore dimensions of portability of disseminator / lenses - this is an important research area

Sakai: Inverted The Personal Learning and Research Environment

Sakai’s Real Scope Data Repositories Resources Portals Collaboration Software

Data Repositories Resources Portals Collaboration Software Is this what the user wants? Fedora uPortal Sakai ? GridSphere SRB DSpace

The User’s Desktop Data Repositories Resource Portals Collaboration Software

PLRE Client Version Server - Site Tool + Site + Server Sakai X Sakai X

Charon Portal Kernel Tool Registry Charon Tool ATool BTool C Sakai Sites Request Filter

Mini PLRE: Replacing the Sakai Navigation with Web Services and a Desktop Application

Mini-PLRE Kernel Tool Registry Sites Web Service Tool ATool BTool C Sakai Sites Request Filter - Server - Site Tool + Site + Server

PLRE Client Version System X - Site Tool + Site + System Y Sakai X Sakai Y Imagine a system-tray icon. Imagine this handling *any* WSRP endpoint (Sakai or portals)…. Imagine this handling your different identities across domains and federation… Imagine this as a toolbar button in a desktop application…

Portals are not just user interfaces - they are servers too. E-Research is more than portals. Rob Allan, Technical Manager, Advanced Research Computing Centre, Daresbury Laboratory, UK July 12, Server - Site Tool + Site + Server

Questions and Summary