Sakai VRE demonstrator project goals
This page outlines some of the goals, both on- and off- the project plan, that we perceive for the Oxford element of this project. The formal project plan sees our work focused in two main areas: Shibboleth federated authentication, and search facilities.
- Testing and agile development
- User requirements
- Sakai, portals and the World Wide Web
Routine project planning and progress notes are linked from here.
1.1. Authentication for Sakai portals
(1b3) Shibboleth-enable the Sakai portal (as opposed to the portlets)
Document requirements and procedure to create a minimal demonstration Shibboleth installation (the available documentation doesn't appear to be very helpful here: pointers would be welcome). (link)
Analysis of infrastructure needed to roll out a Shibboleth federation across partner sites (link)
Implementation of Shibboleth federation across partner sites (link)
1.2. Authentication for JSR-168 portlets
(1b2) Shibboleth-enabled portlets
Transfer of Shibboleth authentications via WSRP/JSR-168 to Shibboleth-aware portlet. (link)
Expose Shibboleth properties via portlet session proerties. (link)
Integration of Shibboleth authentication into uPortal framework (based on SPIE project work). (link)
Ref. Jasper Tredgold's SPIE work in this area. See http://spie.oucs.ox.ac.uk/Wiki.jsp?page=WSRP.
- Does this really mean uPortal?
Given the uncertain and fragile state of WSRP4J and the decidedly user-facing nature of Shibboleth version 1, I (GK) propose to de-emphasize Shibboleth-enabling of portlets in favour of focusing on Shibboleth-enabling the Sakai portals, with the view that portlet focused work would be better deferred until WSRP4J is more stable and robust, and Shibboleth 2 is available with support for multi-tiered authentication via constrained delegation.
1.3. Architectural issues
Document technical and architectural issues with Shibboleth-enabling Sakai VREs (reference and specialize Franscico's work). (link)
(Completed: see ShibbolethNotes)
1.4. Grid integration
(1b4) GRID integration of Shibboleth-enabled Sakai environments
(1b5) Integrate PERMIS authorization and access control tools with Shibboleth-enabled authentication infrastructure.
Evaluate PERMIS management tools. (link)
Implement suitable PERMIS management tools within Sakai demonstrator. (link)
2.1. Requirements analysis
(2a3) Analysis of requirements for enhanced search tools
Operational requirements (e.g. scripted search, search history recording, visualization). (link)
(Work in progress: See InterPortletCommunicationUseCases)
Survey target repositories to search (e.g. bibliographic, quantitative data, e-prints, etc.). (link)
Is there any variation of requirements between research subject disciplines? (link)
- Pick up on requirements work from BVREH and IBVRE projects, and others
2.2. Existing tools survey
(2a4) Analysis of existing tools.
Survey JAFER, CREE, SPP, MDC, ASK, etc. (link)
- Can we abstract away key differences and/or styles?
- How well do these meet identified requirements? Where are the gaps?
2.3. Develop search tools
(2a5) Develop search enhancements.
Develop enhanced search tools. (link)
- Preferably for an identified user.
- How easy is it to develop portal-agnostic, then integrate into Sakai?
2.4. Portlet Publish-Find-Bind
(2a6) Implement Web Services for Remote Portlets Publish Find bind (WSRP PFP).
The essential issue here is that WSRP actually has four Web Services: WSRPBaseService, WSRPServiceDescriptionService, WSRPRegistrationService, WSRPPortletManagementService - with no requirement for these services to be at the same URL endpoint, nor even same server! Moreover the WSRPDescriptionService might give descriptions for multiple portlets
As such PFB consists of three (currently) components - an abstract model of how these different web services connect together (and relate to the underlying portlets) for the purposes of registering portlets into a Web Service registry and then two concrete documents for particular registry protocols namely UDDI and ebXML.
This facility will be based on an existing WS locator facility, following the guidelines in WSRP PFB as regards how we use such a WS locator facility for portlets.
Implement portlet service locator. (link)
- Registry searching for end users and administrators
- Different control regimes
3. Testing and agile development
3.1. Create Sakai installation
(2a1) Create a local Sakai installation for testing.
Install Sakai, and capture any additional information needed to ensure repeatability. (link)
- Identify a stable configuration, and use this as a baseline for testing new features.
(Completed: See PlutoNotes, SakaiVre/DocsAndPresentations/20060105-PortalTesting.ppt)
4. User requirements
4.1. Survey related projects
Distill user requirements analysis from related projects and project partners. (link)
(Completed: See SakaiVre/UserRequirements)
4.2. Requirements identification and analysis
For search requirements, see section 2.1.
Identify other use-cases and requirements for VRE tools (link)
5. Sakai, portals and the World Wide Web
5.1. Sakai technology overview
(2a1) Overview of Sakai.
Prepare summary notes about Sakai architecture and underlying technologies. (link)
(Work in progress: See SakaiNotes)
5.2. Sakai development proposals
Concrete proposals for useful developments to or with the Sakai framework. (link)
5.3. Portal technical architecture
Investigation of architectural issues for portals and WWW. (link)
- Document specific problem areas, and suggest possible resolutions (preferably existing designs)
Alternative architectures for VREs. (link)
- Suggest an architecture based more squarely on ordinary Web standards
- Suggest generic architecture for dealing with data (as opposed to presentation) integration in a VRE environment
Review strengths and weaknesses of this project in context of known requirements. (link)
Synchonizing multiple views of a model. (link)
Portals, personalization and authentication; teasing apart the pieces. (link)
- Explore the deconstruction of portal functionality into pieces that can be implemented separately
(Some early thoughts: See MakingStandards)
-- GrahamKlyne 2006-02-22 11:40:50