Project index

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.


Routine project planning and progress notes are linked from here.

1. Shibboleth

1.1. Authentication for Sakai portals

(1b3) Shibboleth-enable the Sakai portal (as opposed to the portlets)

  1. 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)

  2. Analysis of infrastructure needed to roll out a Shibboleth federation across partner sites (link)

  3. Implementation of Shibboleth federation across partner sites (link)

1.2. Authentication for JSR-168 portlets

(1b2) Shibboleth-enabled portlets

  1. Transfer of Shibboleth authentications via WSRP/JSR-168 to Shibboleth-aware portlet. (link)

  2. Expose Shibboleth properties via portlet session proerties. (link)

  3. Integration of Shibboleth authentication into uPortal framework (based on SPIE project work). (link)

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

  1. Document technical and architectural issues with Shibboleth-enabling Sakai VREs (reference and specialize Franscico's work). (link)

1.4. Grid integration

(1b4) GRID integration of Shibboleth-enabled Sakai environments

  1. Evaluation of tools. (link)

  2. Implement suitable tools within Sakai. (link)


(1b5) Integrate PERMIS authorization and access control tools with Shibboleth-enabled authentication infrastructure.

  1. Evaluate PERMIS management tools. (link)

  2. Implement suitable PERMIS management tools within Sakai demonstrator. (link)

2.1. Requirements analysis

(2a3) Analysis of requirements for enhanced search tools

  1. Operational requirements (e.g. scripted search, search history recording, visualization). (link)

  2. Survey target repositories to search (e.g. bibliographic, quantitative data, e-prints, etc.). (link)

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

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

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

  1. Implement portlet service locator. (link)

    • Registry searching for end users and administrators
    • Different control regimes

    [NOTE: split this into requirements/implementation tasks?]

3. Testing and agile development

3.1. Create Sakai installation

(2a1) Create a local Sakai installation for testing.

  1. 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.
  2. (1b1) Develop ServletUnit testing framework for JSR-168 portlets. (link)

4. User requirements

  1. Distill user requirements analysis from related projects and project partners. (link)

4.2. Requirements identification and analysis

For search requirements, see section 2.1.

  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.

  1. Prepare summary notes about Sakai architecture and underlying technologies. (link)

5.2. Sakai development proposals

  1. Concrete proposals for useful developments to or with the Sakai framework. (link)

5.3. Portal technical architecture

  1. Investigation of architectural issues for portals and WWW. (link)

  2. 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
  3. Review strengths and weaknesses of this project in context of known requirements. (link)

  4. Synchonizing multiple views of a model. (link)

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

Creative Commons License
The content of this wiki is licensed under the Creative Commons Attribution-ShareAlike 2.0 England & Wales Licence.

OSS Watch is funded by the Joint Information Systems Committee (JISC) and is situated within the Research Technologies Service (RTS) of the University of Oxford.