SUNIWE

Welcome to SUNIWE

What is SUNIWE?

SUNIWE was a project funded by the JISC under the Distributed E-Learning Regional Pilot Programme. SUNIWE ran from April 2005 to March 2007. SUNIWE aimed to create a portal of personalised content for learners and pilot it in the Staffordshire University Regional Federation and the Wales e-Training Network.

What's on the site?

The site contains the key findings and experiences of the SUNIWE project. Our experiences may be of interest if you are working with any of the following:

• Portals (especially uPortal)
• IMS Enterprise Web Services
• Shibboleth
• Cross-institutional services and personalisation

The project final report includes the full story of our experiences and is available from the downloads section. Also available from the downloads section is source code for the uPortal Channels and IMS Enterprise Web Services implemented as part of the SUNIWE portal.

Project partners

Contact

For further information about the SUNIWE project or subsequent related projects, please contact the Project Director Professor Mark Stiles.

Site Linkmap Table of Contents

This is a map of the complete site and its structure.

• SUNIWE  ___________________  site
• About  ___________________  about
• Welcome  ___________________  index : Welcome to SUNIWE
• Table of contents  ___________________  linkmap : Table of Contents for this site
• Project  ___________________  project : Project information
• Summary  ___________________  openOfficeWriter : Short summary of the project
• Organisation  ___________________  openOfficeWriter : Organisation, governance and management of the project
• Driving Factors  ___________________  openOfficeWriter : Factors driving the project
• Aims and Objectives  ___________________  openOfficeWriter : The aims and objectives of the project
• Project Approach  ___________________  openOfficeWriter : The development approach used in the project
• Software Development Process  ___________________  development-process : The development process followed to create the portal
• RUP summary  ___________________  openOfficeWriter : Summary of the Rational Unified Process
• The Vision  ___________________  openOfficeWriter : The requirements of the project outlined as scenarios
• Architecture  ___________________  openOfficeWriter : A description of the components of the system and how they interact
• Capturing Requirements  ___________________  openOfficeWriter : A description of how requirements were captured as Use cases
• Use Cases, Actors and Stakeholders  ___________________  openOfficeWriter : The list of Use Cases, Actors and Stakeholders identified during requirements capture
• Storyboards and Prototyping  ___________________  openOfficeWriter : Creating a prototype of the user interface via storyboards and mock screens
• Analysis  ___________________  openOfficeWriter : A description of how the requirements and data were analysed
• Storyboard Example  ___________________  openOfficeWriter : An example storyboard document
• Design  ___________________  openOfficeWriter : The design of the code for the uPortal channels and Web services
• Construction  ___________________  openOfficeWriter : The phase of the project which involves building the portal
• Development Practices  ___________________  development-practices : Practices, environment and tools used in the development of the portal
• Project Communication  ___________________  openOfficeWriter : Methods of communication used by the project team
• Development Tools  ___________________  openOfficeWriter : The software used to support the development process
• Logging and Exception Handling  ___________________  openOfficeWriter : Outline of our approach to logging and exception handling
• Remote Collaboration and the WeTN Portal  ___________________  openOfficeWriter : Tools and practices used to work with the WeTN development team remotely
• Shibboleth  ___________________  openOfficeWriter : Our experiences trying to implement Shibboleth
• Data Protection Issues  ___________________  openOfficeWriter : An outline of the approach used to address data protection issues
• IMS Enterprise Issues  ___________________  openOfficeWriter : Problems encountered trying to implement IMS Enterprise Specs
• Outputs and Results  ___________________  openOfficeWriter : Description of the outputs of the project
• Outcomes  ___________________  openOfficeWriter : What the project achieved in terms of the original aims and objectives
• Conclusions  ___________________  openOfficeWriter : What we'd learned by the end of it
• Implications  ___________________  openOfficeWriter : Implications for other projects
• Downloads  ___________________  downloads : Project outputs available for download
• Downloads  ___________________  openOfficeWriter : SUNIWE downloads
• Installation Instructions  ___________________  openOfficeWriter : Brief overview of SUNIWE system installation
• All  ___________________  all
• Whole Site HTML  ___________________  whole_site_html
• Whole Site PDF  ___________________  whole_site_pdf

SUNIWE Project Summary

Background

SUNIWE was a JISC Distributed E-Learning Regional Pilot project which ran from April 2005 to March 2007. The project partners were drawn from three distinctive regional consortia: the Staffordshire University Regional Federation (SURF), the Wales e-Training Network (WeTN) and the Northern Ireland Integrated Managed Learning Environment (NIIMLE).

SUNIWE was designed to build on the work done by the NIIMLE Project in implementing a portal to provide access to personalised information for learners. The aim was to extend the NIIMLE portal, trial this within the two partner consortia, and to further develop the portal content to provide personalised links to VLEs, library systems and e-resources. A parallel project strand looked at implementing and piloting the Shibboleth federated authorisation software. Shibboleth would be used to secure the portal and its content and allow seamless access to the portal throughout each consortium.

Methodology

The Rational Unified Process (RUP) was used as the project management and software development approach. It is a use case-driven, iterative software development process framework which focuses on identifying and mitigating risks and producing working software at each stage of development. It was important to use an iterative software development approach because it better suited the speculative nature of the development work. The portal was to be developed first within SURF and then the outputs cascaded and implemented within WeTN. This would allow the WeTN team to refine their requirements in light of the experience of the SURF developments. SURF and WeTN would then pilot the portal and evaluate it.

The RUP was followed to capture the requirements, analyse the data, design and implement the system. The system was built on the same foundations as NIIMLE. uPortal was used as the portal framework, uPortal channels were developed to display the personalised content in the portal and IMS Enterprise Web Services were developed to provide the data from institutional databases throughout each consortium. The scope of the project was reduced due to the lack of available data and insufficient interoperability with existing systems but the project successfully implemented channels and Web services to allow the portal to display personal, course and transcript information and link to VLEs and electronic resources.

Shibboleth

The biggest risk in the project was the Shibboleth implementation. Shibboleth was investigated and experimented with throughout the project and the project team sought advice far and wide but Shibboleth proved to be inappropriate for use with the portal and Web services for several reasons. Loss of key personnel during the project slowed the development effort such that the conclusion about Shibboleth was reached too late in the project to allow an alternative to be developed, although a candidate solution was identified. The lack of a secure environment for the portal and Web services meant that the portal could not be piloted at SURF and WeTN.

Result

Within the context of the aims of the distributed e-learning regional pilots, SUNIWE ultimately did not achieve its aim of piloting and evaluating the portal but key issues and barriers to facilitating progression, sharing of resources across institutions and supporting the independent lifelong learner were identified, especially in the area of federated identity management.

Future

The JISC SURF WBLWay Project is building on the skills, knowledge and experience gained in SUNIWE to create a personalised portal to support people involved in work-based learning in Foundation Degrees in the Staffordshire University Regional Federation.

Project Organisation

Roles of the core project team are illustrated in the diagram below.

Figure 1: project roles

Professor Mark Stiles directed the project. Vicki Watkin managed the project. Sam Rowley managed the technical development of the project and took over as Project Manager when Vicki left the project. Professor Tony Toole managed the work at WeTN and Dr Greg McClure acted in a consultant role for the project and managed NIIMLE involvement.

At SURF, the project reported to Staffordshire University’s Information Services Senior Management Team and the SURF Management Board. Information Services contributed effort from other internal teams as the project work formed part of core strategy. At the two SURF partners, the work was led by staff who had considerable experience of working with the University on JISC projects. The SURF development team was based at Staffordshire University.

Staffordshire University led the work on Shibboleth. Project funding was used to appoint staff who effectively “bought-out” experienced staff, whilst also contributing to the project. SURF was responsible for pulling together and submitting project reports for JISC.

At WeTN, the project reported to the National Coordination Committee. The project work was planned to happen in parallel with the WeTN on-line foundation degree development which was due for completion at the end of 2005. The WeTN project team were based at Coleg Sir Gâr.

NIIMLE’s role was as a “providing” partner in terms of supporting the other two partners in their use and further development of the NIIMLE outputs.

During the course of SUNIWE, the NIIMLE project was discontinued. The NIIMLE outputs were subsequently managed by Queens University Belfast (QUB) where NIIMLE was based and Greg McClure continued to work. An agreement with QUB was made to ensure continued participation of Greg in the project.

Consortium Agreements

A Consortium Agreement was required to establish the rules for managing the project. The consortium agreement outlines institutional rights and obligations, ownership of existing and newly created intellectual property and arrangements for operational, technical and financial management. The consortium agreement underpins the work of the project and should be in place from the start of the project. All SUNIWE partners agreed a commitment to full and open sharing of all work done, and that all source code produced would be open source. Should any content be produced this would also be made freely available. Even with this commitment, the creation of the agreement was still a laborious and time-consuming process. The summary below encapsulates months of effort. Our recommendation to other projects would be to start work on the agreement as early as possible in the project.

A consortium agreement would usually take the form of an agreement between institutions involved in a project. In the case of SUNIWE, each partner in the project was a consortium and each of the consortia had existing local agreements which predated the SUNIWE project.

The three consortia had existing copyright and intellectual property rights (IPR) agreements, but it was recognized that weaknesses in the agreements existed that needed to be addressed. Despite weaknesses in the agreements, all three consortia had operated successfully on their own projects and the problems to be addressed were more about formalising existing practice than the introduction of new practice.

The project team worked with Andrew Charlesworth to review the existing consortium agreements for SURF and WETN. It was decided that a “joining agreement”, including copyright and IPR issues, could be covered by memoranda of understanding as the existing WETN and SURF agreements were sufficiently robust.

Outputs

For the purposes of SUNIWE a principle of making all outputs freely available was adopted. This was implemented using Creative Commons for documentary outputs and Open Source licensing for software.

NIMLE source code was licenced using a BSD style licence (code is available to anyone who wants it; providing that the authors are acknowledge when used). It was decided the same type of licensing would be appropriate for SUNIWE outputs.

Data Protection

In addition to the copyright and IPR issues covered in the consortium agreements, the sensitive nature of the information being used in the portal required that a data protection agreement be produced. The data protection agreement covered the processing of data during the portal pilot and involved even more effort than the consortium agreements. Creation of the data protection agreement is outlined in the data protection section.

Driving Factors

There were a number of problems being experienced in the consortia which the project work attempted to address.

A difficulty that applied to all learners was the lack of relevant, collated, up to date information and links to applications. Essential resources for students were scattered across many web sites and applications. Learners had to remember several URLs or sequences of page links to navigate to the information and applications they needed on a regular basis. This often required logging in multiple times to different applications.

Another difficulty was the lack of systems to provide secure access to applications across institutions. VLEs were often used to provide authentication and authorisation services to allow secure access to distributed resources in the absence of a dedicated solution. This imposed an administration overhead for the maintainers of the VLEs and a complexity overhead for the learners who were required to use the VLE no matter how simple the resource.

A key difficulty experienced by managers of flexible on-line course delivery to lifelong learners was the maintenance of accurate student data. Conventional student record systems assumed campus-based students in cohorts following the normal academic year. A requirement existed for dynamic tracking of individual student learning plans with multiple start and finish times involving more than one institution.

Data reconciliation was also problematic. Personal data about each learner was held at each institution and the reconciliation process to confirm identities between institutions was a laborious manual process. More active involvement of the learners would benefit both sides.

Information of relevance to learners was often simply inaccessible, being locked away in ‘information silos’, monolithic corporate systems with specific roles which were difficult to integrate. Where information was available, it was spread across web sites and proprietary applications. There was a need to get these systems to communicate to allow the data they contained to be used flexibly in a range of contexts to provide a better environment for the learner.

Aims and Objectives

Aims

The aims of the project were:

1. To implement and evaluate the NIMLE student portal infrastructure as a way of managing the delivery of flexible lifelong learning

2. To improve the learner experience by providing easy access to a personalised collection of essential information, applications and electronic resources.

3. To enable the learner to log in once to access all the information, applications and resources.

4. To provide a foundation for tracking flexible student learning plans across institutions.

5. To enable learner interaction in business processes such as learner data reconciliation.

6. To implement a service-oriented approach to integrate the enterprise applications in each consortium to provide dynamic data via web services.

7. To improve enrolment operations between student record systems and VLEs via services.

Objectives

The objectives for the project were set out as a collection of envisaging scenarios to illustrate the functionality and services required from the point of view of the user. The scenarios are detailed in appendix A.

The SURF objectives were centred on utilising the existing work of NIIMLE to build personalised links between the portal and University and College systems to enable the following:

1. Display of current college course and university module titles and descriptions

2. Display of transcript / learner record information (course results, etc)

3. Display of personal information (name, address, telephone, etc)

4. Sending of learner requests to update personal information

5. Launching of course content in VLEs from links in the portal

6. Direct access to e-Resources from links in the portal

7. Direct access to library catalogue system from the portal to view books on load and reserved

8. Automation of enrolment operations between the student records system and VLEs.

A key objective was to implement Shibboleth to secure the portal, applications, e-resources and web services within each consortium to allow single sign-on access to all applications and resources accessed from the portal.

For WETN, additional objectives were:

1. To implement the portal as part of an integrated MLE involving six e-Training Network institutions

2. To evaluate the effectiveness of the implementation in the sharing of content and the management of delivery across institutional boundaries

3. To evaluate the ability of the system to dynamically maintain accurate student records

4. To trial Shibboleth technologies as part of the evaluation in order to achieve single sign-on capability

5. To test scalability by extrapolating to an all-Wales scenario

The Potential Benefits to NIIMLE were seen as:

Enhancement of the Enterprise Web Services implementation - The current implementation would be enhanced by the development of more of the operations specified by IMS. Also, additional application profiles developed would be useful in the provision of future NIIMLE services

Better integration of COSE with the portal, especially single sign-on between COSE and the portal. In addition, it was hoped that user preferences in the portal, for example colours and styles, could be made to extend to the COSE channel.

Project Approach

Overall Approach

The Rational Unified Process (RUP) was used as the project management and software development approach. It is a software development process framework which enables adopters to select process elements to generate a process customized to their needs.

The development team’s aim in a project like SUNIWE was to produce a high quality portal implementation that met the needs of its users under the constraints of time, the small size of the development team and the skills and relative experience of the developers. The project needed a well-established, iterative process to enable the developers to succeed and RUP fitted the bill.

RUP projects are comprised of four Phases. Each phase is comprised of one or more Iterations through the software development workflows (Requirements Capture, Analysis, Design, Implementation, Testing). Requirements are captured as descriptions of how the user interacts with the system. Each iteration produces working software which implements some of the descriptions (use cases) or addresses some of the technical risks.

The phases have specific objectives:

1. Inception Phase - focuses on establishing the business case for the project

2. Elaboration Phase - focuses on addressing the major technical risks of the project

3. Construction Phase - focuses on building the beta version of the working system

4. Transition Phase - focuses on refining and fine-tuning the system to best meet the needs of the users

Each Phase and Iteration is planned at the start and evaluated at the end. This ongoing evaluation and feedback loop allows the project and the process to be refined to produce better quality software.

The project plan called for the portal to be developed first within SURF and then the outputs cascaded and implemented within WETN. This would give the WETN team more time to understand the extent of what was achievable and refine their requirements in light of the experience of the SURF implementation.

Why RUP?

RUP offered several advantages:

1. it provided a well-defined structure for the lifecycle of the project and clearly articulated milestones and decision points

2. it focused on providing value for the user of the system

3. it focused on quality

4. it focused on producing working software

5. it included evaluation and refinement as a core part of the process

6. it was iterative and incremental

7. it comprised many software development best practices

8. it was well-supported with a large user base and extensive documentation

SUNIWE represented the first attempt at iterative development for the development team so the team wanted a methodology with a well-structured project lifecycle and the reassurance of good reference literature and a large user community. The customisable nature of the process was also important, as was the emphasis on producing working, tested software rather than documentation.

Why an Iterative Approach?

It was important to use an iterative software development approach because it better suited the R&D nature of the project.

The Traditional Approach

The traditional software development approach is one in which all the development workflows happen once in a series (requirements gathering, analysis, design, implementation, testing) hence it is also know as the Waterfall approach. All work is planned in detail at the start of the project. Changes to the project plan are considered exceptional events and are dealt with accordingly.

The Waterfall approach relies on some prior knowledge or experience of what is being implemented. This rarely is the case with research and development focused projects such as SUNIWE. With the development team unfamiliar with the nature of the problem and sometimes even the tools and technologies used to solve it, the initial project plan is essentially guesswork.

The Waterfall approach also defers testing and integration until the end of the project lifecycle. Consequently, problems tend to be harder and more expensive to resolve. A working system is only available after integration at the end of the project which rules out demonstrations and user feedback as the project progresses.

The Case for Iterative Development

Iterative development is an approach that builds software in a sequence of incremental steps. Each step, or iteration, includes some or all of the development workflows as well as management and evaluation activities. Each iteration produces a working system of limited functionality. Successive iterations build on the work of the previous iterations to evolve and refine the system until the final product is complete.

Iterative development has many advantages over waterfall development.

1. It embraces changing requirements. Change is seen as a natural part of the evolution of the system rather than an exceptional event. Evaluation of the working system from each iteration feeds back into the process. Decisions can be made as more is learned about the problem being solved, rather than guessing at the start. In this way the direction of development can be steered to ensure the system meets the needs of the users. The development process itself is also refined via evaluation.

2. Integration of components is done during each iteration. This means integration problems are spotted earlier when they are more easily and cheaply solved. Risks associated with the architecture of the system are also identified early on and can likewise be dealt with without major reworking of the product.

3. Similarly, performance bottlenecks are spotted early and can be dealt with over several iterations. Bugs are found and dealt with in each iteration so the core parts of the system will have been tested thoroughly and repeatedly by the time the system is complete. This results in a robust architecture and high-quality product.

4. Reuse is facilitated because it is easier to identify common functionality when encountering it during development iterations than in planning.

Iterative Development in the World of JISC

Iterative development is particularly suited to JISC project work. JISC projects often involve new technologies and standards and unfamiliar domains. An iterative approach allows the project team to run through the development workflows several times, each time learning more about the new aspects of the project. As the team gets a better handle on the new tools and technologies, this learning is fed back into subsequent development and a better quality system results.

JISC projects are often speculative and concerned with creating innovative and novel solutions. At the point of securing funding, project teams often don’t know what they are going to build in any detail. They have a good idea what they would like to build, of course, but they do not know whether it is feasible. The scope and nature of a system can change radically as more is learned about it as the project progresses. For this reason, a detailed project plan drawn up at the start of the project can be worthless as most of the plan will be guesswork. Using an iterative approach, the overall project plan is kept course-grained and detailed plans are made only for forthcoming iterations and phases. This allows development to be structured but allows the direction of the project to evolve as more is discovered about the system being built.

Software Development Process

RUP Summary

Methodology Description

The Rational Unified Process (RUP) is a software development approach that is described (Jacobsen et al 1999) as iterative, architecture-centric, and use-case driven.

Iterative development has been described above.

Architecture-centric means that there is a focus on the architecture of the application from an early stage in the project. A working system is created in the early iterations so that problems with the architecture can be addressed earlier in the project when they present less risk.

Use-case driven means that all the functionality of the system is derived from use cases, simple descriptions of the interactions between the system and it’s users. This ensures that only features of value to users are developed.

RUP provides a well-defined structure for the lifecycle of a project and includes essential milestones where major decisions can be made about the project.

Figure 1: The RUP Lifecycle

Project Lifecycle

The lifecycle of a RUP project is divided into four named phases.

1. Inception

2. Elaboration

3. Construction

4. Transition

A phase consists of one or more iterations and concludes with a milestone where project progress is assessed and major decisions made. Iterations in each phase focus on producing technical deliverables that meet the objectives of the phase.

Phases

Each phase has specific objectives.

Inception

The Inception Phase is concerned with launching the project. The business case for the project is built by developing a good understanding of the requirements and scope of the system and getting buy-in from the project stakeholders. At the end of the Inception Phase the project team will know whether or not to proceed with the project

Elaboration

The Elaboration Phase is concerned with addressing the major technical risks of the project. The focus of the work is to create a bare bones system which answers all of the major technical questions. At the end of the Elaboration Phase the project team will know that they can successfully build a working system.

Construction

The Construction Phase is concerned with moving from the executable architecture created in the Elaboration Phase to an operational system. At the end of the Construction Phase the project team will have a beta version of the system ready for evaluation.

Transition

The Transition Phase is concerned with ensuring that the software meets the needs of its users. The system is evaluated and refined based on user feedback. This is a fine-tuning exercise as the system will already meet the needs of its users because of the use-case-driven nature of the project. At the end of the Transition Phase the system is released and the project evaluated.

Milestones

A milestone marks the point at which the project team and stakeholders decide whether the project has achieved the criteria to pass to the next phase.

Iterations

The work of each iteration includes some or all of the development workflows.

1. Requirements Capture

2. Analysis

3. Design

4. Implementation

5. Testing

As the project phases progress, the relative amount of work in each workflow will vary. For example, In the Inception Phase, most of the work will be focused on requirements capture, whereas in the Construction Phase, most of the work will be focussed on Implementation.

Each iteration focuses on implementing specific use cases or addressing specific technical questions.

Planning and Evaluation

The project plan includes Phase and Iteration plans. The project plan starts out course-grained and uncertain and is refined as the project progresses and feedback from phase and iteration evaluation is included.

Evaluation is an inherent part of the RUP process. Each RUP Phase, and iteration within it, will have linked evaluative and QA components, plus a review at the end of each.

In SUNIWE, each partner and cooperating college maintained an ongoing record of all aspects of its involvement. Partners gave feedback and reviewed each others progress at project meetings. All aspects of the project were under evaluation including the development outputs, the tools and environment, the methods of communication and the project management and software development approach itself.

Initial user evaluation and testing prior to the pilot was planned to be made up of:

1. Demonstration to small target stakeholder group

2. Trial by group

3. Observation of trial

4. Focus group and/or interviews

The Vision

The aims and objectives of the project were described in the bid document in terms of envisaging scenarios. The full list of scenarios is included in the project final report. Together these scenarios formed the vision of the system in a way that could be easily conveyed to potential users of the system and the project team. This was important to promote a shared understanding of what the team intended to implement at the start of the project. An example scenario from each of the partners is shown below.

SURF

I am a student at Staffordshire University who works flexibly as I am a single parent. I connect to the University’s Portal over the Internet. When I log in, I can see a list of all the modules I have taken so far and the modules I am currently registered for. By clicking on their entry, I can see more detail about each module. I can also see my personal details, such as address, transcript, etc, as held by the University. I have just changed my phone number so I click on a button and enter the new number. (This is sent to the relevant people at the University who change the entry in the MIS system).

WETN

I am sales manager at Spencer Davies Engineering in Burry Port, South Wales. I have responsibility for the company web site and, more recently, for the development of our ability to carry out supplier and customer transactions on-line. To develop my skills in this area I am enrolled as a graduate student at Coleg Sir Gâr on an on-line Foundation Degree in e-Commerce validated by the University of Glamorgan. When I log on, I connect to the Virtualcollege Portal which gives me access to the modules I am currently studying, as well as a range of other resources and information including my Learner Record and ePortfolio. This information is important to the company as it confirms progress against my Personal Development Plan and, along with those for other employees, contributes to the company’s IIP status. As I understand it, the modules for this course were developed across Wales by a network of all the colleges in the country a and I am supported by the tutors at those colleges as I progress through those modules.

NIIMLE

I’m in the final year of my FE course and want to go to university. I log onto the NIIMLE portal using my current username and password from my college and select the pathways service. From here I can view details of courses I can progress to in HE institutions. Each course is supported by an online mentoring service where I can link directly to an academic in a discussion forum. I can also drill down to the FAQs section relating to the course for answers to the most common queries.

Architecture

The main aim of SUNIWE development was to take the NIIMLE and extend it to provide the required functionality for SURF and WETN.

The NIIMLE

The NIIMLE offered core data (name, course, etc), transcript, progression pathway information, mentoring, PDP and portable courses to learners. The NIIMLE was built on the free, open source uPortal software. uPortal provides a Java-based framework for creating web portals. A web portal is a site on the World Wide Web which provides personalized capabilities to its visitors. It is designed to provide services from a number of different sources and to provide content able to work on multiple platforms e.g. PCs, PDAs, Mobile Phones.

Data for the portal was provided by IMS Enterprise Web Services to enable interoperability with the various systems in the institutions in Northern Ireland. Portal channels created by the NIIMLE team displayed the information to the portal users.

UPortal

uPortal is an open source, open standards effort built on Java, XML, JSP, XSLT and JDBC. It is a framework for building a portal rather than a portal itself. uPortal presents collections of channels on each screen.

Figure 1: UPortal channels

Channels can display static and dynamic content. Each one of the areas shown in the screen capture above is a channel. Channels can act as applications and have their own navigation and display multiple pages of information. The portal provides an easy way to aggregate these applications to display important information on a single site.

IMS Enterprise Web Services

The IMS Global Learning Consortium provides a range of specifications to enable interoperability of learning systems. The Enterprise Services specification is the definition of how systems manage the exchange of information that describes people, groups and memberships within the context of learning.

Three services are specified:

1. Person Management Service

2. Group Management Service

3. Membership Management Service

Each service defines operations that manipulate single or multiple objects appropriate to that service. For example, the Person Management Service operations are shown in the table below.

Table5

Operation	Description
createPerson	To request the creation of a populated 'person' record on the target system and the source is responsible for the allocation of the unique identifier.
createByProxyPerson	To request the creation of a populated 'person' record on the target system and the target is responsible for the allocation of the unique identifier.
deletePerson	To request the deletion of a 'person' record. The 'person' record is deleted and all of its associated relationships.
readPerson	To read the full contents of the identified 'person' record. The target must return all of the data it has for the identified 'person' record.
updatePerson	To write new content into the identified 'person' record. The target must write the new data into the 'person' record. This is an additive operation.
replacePerson	To replace the content of the identified 'person' record. The target must write the new data into the 'person' record. This is a destructive write-over of all of the original information.
changePersonIdentifier	To change the sourcedId of the 'person' record. The completion of this operation will result in later actions using the original sourcedId reporting an unknown identifier status.
createPersons	To request the creation of a set of populated 'person' records on the target system. The source is responsible for the allocation of the unique identifiers.
createByProxyPersons	To request the creation of a set of populated 'person' records on the target system. The target is responsible for the allocation of the unique identifiers.
deletePersons	To request the deletion of a set of 'person' record. The 'person' records and all their associated relationships are deleted.
readPersons	To read the full contents of the set of identified 'person' records. The target must return all of the data it has for each of the identified 'person' records.
readPersonsForGroup	To retrieve the 'person' records for a particular Group. This returns the person record for every person that is a member of the Group i.e., for whom a membership record in the Group exists.
updatePersons	To write new content into the set of identified 'person' records. The target must write the new data into each of the 'person' records. These are additive operations.
replacePersons	To replace the content of a set of identified 'person' records. The target must write the new data into the 'person' records. These are destructive write-overs of all of the original information.
changePersonsIdentifier	To change the sourcedId of the set of 'person' records. The completion of this operation will result in later actions using the original sourcedId reporting an unknown identifier status.

Figure 2: Summary of PersonManagerService operations.

The NIIMLE used IMS Enterprise Web Services to manage student records, pathways records, and learner transcript. Operations from all three services were implemented. The Person Service delivered the student core data, the Membership Service delivered a set of ‘memberships’ of courses (enrolments), and the Group Service delivered details of each of these courses.

SUNIWE

SUNIWE used the same architecture as NIIMLE.. A collection of components were combined to create the system.

Figure 3: NIIMLE/SUNIWE System Components

Clients access SUNIWE using a web browser. On the portal server, Apache Tomcat was used as the web container. uPortal ran as a web application in Tomcat.

Custom channels were created by the development team to provide content for the portal. Each custom channel consists of Java classes and XSL stylesheets. The Java classes consume data in XML format from the web services and transform it using the XSL stylesheets into a format fit for processing by uPortal. The XML is then output from the channel and uPortal performs additional transformations to turn the XML into appropriately-styled HTML for display on-screen.

On the servers hosting the web services, Tomcat was used as the web container. The Apache Axis Web service framework was used to host the Web services.

Web services use XML messages that follow the SOAP standard. Axis provides a SOAP server implementation, and various utilities and APIs for generating and deploying Web service applications.

The IMS Enterprise Services specifications include a set of machine readable descriptions of the operations supported by the server described in Web Services Description Language (WSDL). Axis provides a WSDLtoJava tool which was used to generate a framework of IMS Java classes from the IMS WSDL descriptions. These IMS classes were modified to use NIIMLE classes to implement the functionality of the services. The NIIMLE classes interacted with the database via basic JDBC queries.

Training

The project team held training sessions to enable developers to get familiar with the NIIMLE system and to gauge the amount of work involved in implementing the NIIMLE portal and services. These ‘code bashes’ separately covered the Web services and the uPortal channels and attempted to implement the NIIMLE components locally at SURF.

Capturing Requirements

Requirements were captured as use cases. Each use case described the interaction of a user with the system as a sequence of steps that led to some outcome of value to the user. The use cases contained more formal descriptions of system behaviour than the original envisaging scenarios. Part of the use cases analysis was to identify the actors and stakeholders of the system. Actors were people or computer systems that would use the system and require services of the system. Stakeholders were people for whom the system would have an impact even if they did not directly use the system. It was important to identify both Actors and Stakeholders so that the needs of both could be addressed.

Use cases were used to describe requirements because they captured descriptions of the system in a way that could easily be understood by all users of the system. The use case-driven aspect of the RUP approach then ensured that the system was implemented as realizations of the use cases so only features of value to users were developed.

Identifying Actors, Stakeholders and Use Cases

The actors and use cases were identified by working through the envisaging scenarios to extract interactions with the system. Most scenarios gave rise to multiple use cases. Stakeholders were identified by thinking about the impact the system would have on other systems or processes and procedures in the institutions.

An example Use Case and the scenario it was derived from is shown below. The scenario mentions the ability of the user to see personal information and make a request to have it changed, The Use Case was derived from the scenario by thinking about the steps the user and the system needed to take in order to achieve the desired behaviour. These steps were captured as text in a formal Use Case description.

The Use Case Description includes a brief description of the use case; descriptions of the actors who participate in the use case; any preconditions that must be satisfied at the start of the use case; a basic flow of events which describes the normal operation of the use case; and alternative flows which describe different paths through the use case when exceptional events happen.

Excerpt from Scenario 1:

“…I can also see my personal details, such as address, transcript, etc, as held by the University. I have just changed my phone number so I click on a button and enter the new number. (This is sent to the relevant people at the University who change the entry in the MIS system)”.

Use-Case Description: View and Change University Personal Information

Use-Case Description: View and Change University Personal Information

Brief Description

This use case describes how a Learner uses the system to view the personal information held by the University and submit a request to change the personal information.

Actor Brief Descriptions

Learner

The Learner is registered on a course at the University and can view personal information about the Learner held by the University.

Learner Information Manager

User of College MIS system who receives requests to change personal information and can make the changes.

Student Information System

The system storing the student personal information.

Preconditions

The Learner must be registered as a student with the University. The Learner must have a username and password to access University systems.

Basic Flow of Events

{Launch System}

The use case begins when the actor Learner launches the URL of the system in a web browser.

{Authenticate Learner}

Include use case Authenticate Learner to authenticate the use of the system by the Learner.

{Display Personal Information}

The system displays personal information and an option to change personal information.

{Change Personal Information}

The Learner selects to change personal information.

The system displays editable personal information and options to cancel or submit a change request.

{Edit Personal Information}

The Learner edits the personal information.

{Submit Change Request}

The Learner selects to submit a change request.

The system submits a change request to the Learner Information Manager and a copy of the change request to the Learner.

{Update Personal Information}

The Learner Information Manager updates the Student Information System with the changed personal information for the Learner. NOTE: In reality this will happen sometime after the receipt of the request by the LIM. Need to know how to best capture the asynchronous nature of this step in the use case.

{Acknowledge Change Request Submission}

The system displays a message to inform the Learner that a change request has been submitted and an acknowledgement option.

The Learner selects to acknowledge the change request message.

The system displays the personal information and an option to change the personal information.

{Use Case Ends}

The use case ends.

Alternative Flows

Change Request Cancelled.

At {Edit Personal Information} or {Submit Change Request} if the Learner selects to cancel the change request,

The use case resumes from {Display Personal Information}.

Handle communication failures

At {Display Personal Information} if the Student Information System cannot be contacted or does not reply within the set communication time-out period,

And if the communication link has failed more times than the communication retry number, then communication is abandoned and the system informs the Learner of the communication error.

The system will attempt to contact the Student Information System until it has completed the number of retry attempts indicated by the communication retry number.

If communications are re-established, the basic flow is resumed at {Display Personal Information}.

If there is still no response from the Student Information System, the system creates an event log entry to record the failure of the communications link to the Student Information System. The event log entry includes the type of failure.

The system sends the event log to the Service Administrator to inform it that communication with the Student Information System has been lost.

Resume the basic flow at {Use Case Ends}.

Use Cases, Actors and Stakeholders

Use Cases

Use cases were extracted from all of the scenarios and then prioritized to tackle those which involve significant architectural issues first with the “simpler” use cases to follow. The Use Case analysis resulted in the following initial list for SURF and WETN.

SURF

1. Login To University Portal

2. View Taken University Modules

3. View Registered University Modules

4. View University Module Details

5. View Personal Details held by University

6. View University Learner Record

7. Request change to Personal Details held by University

8. Login To SURF Portal

9. View Taken College Courses

10. View Registered College Courses

11. View College Course Details

12. View Previous Institution College Courses

13. View VLE Modules or Courses

14. Access VLE Module or Course

15. View Relevant e-Resources from College or University

16. Access Relevant e-Resource

17. Enrol Onto VLE Module

WETN

1. Enrol and receive induction

2. Log in and access current learner information

3. Access learning resources

4. Access tutor support

5. Access learner support

Actors

Actors identified during use case analysis were as follows:

Table6

SURF	WETN
Learner	Learner
COSE VLE	eTutors
College VLE	Coleg Sir Gâr VLE
University Student Record System	Coleg Sir Gâr SRS
College MIS	College VLE
uPortal	uPortal
eResource Systems	eResource Systems
	College SRS

Stakeholders

Stakeholders are shown in the table below. It was important to consider the stakeholders as well as the actors as the stakeholders could have a significant impact on the success of the project and portal.

Table7

Stakeholders SURF and WETN	Interest / stake	Importance (SURF)	Importance (WETN)
Learners	Prime beneficiary of the project outcomes	High	High
e-Moderators/Tutors	Part of the distributed programme support team	Medium	High
Programme Managers	Manage the distributed programme	High	High
Programme Administrators	Manage the distributed information	High	High
Learner Support Staff (LRC, Technical Support, Customer Support)	Support providers. Could be a central provision for the distributed network	Medium	Medium
Resource Support Staff (Portal, VLE & Repository Support, Content Management)	Could be partly distributed and partly central	High	High
Corporate Information and Student Service Staff	Own current Business practices	High
Learning Development and Innovation	Responsible for implementation and leading change	High
Senior Institutional Management (WETN)	Need to buy in to the culture change that this development would represent		Medium
Senior Institutional Management (SURF)	Need to support required culture changes, which are in line with existing institutional strategy at the University and buy into it in college partners	High
HEFCW	Need to buy in to the culture change that this development would represent		Medium
Wales Assembly Government	Need to buy in to the culture change that this development would represent		Medium
HEFCE	Project in line with HEFCE eLearning Strategy	Medium
UK Government	Project in line with DfES eLearning Strategy	Medium

Storyboards and Prototyping

With the requirements identified in the form of use cases, the next step was to prototype the user interface. Following the NIIMLE process, an initial storyboarding session was held.

Initial Storyboarding Exercise

The aim of the storyboarding session was to create a logical design for the user interface. User interface elements required by each actor for each use case were identified and organized to ensure each use case was accessible through user interface elements in a well-integrated, easy to use and consistent manner.

Screen layouts were sketched and labelled. All screen elements were also labelled. Once the screen sketches for a use cases were complete the project team walked through the use case using the sketched screens to check for missing elements and consider navigation and usability issues.

The designs of the UI screens were captured on flipcharts and then photographed with a digital camera for quick and easy inclusion in electronic documents. The storyboarding session was written up with notes about each screen and the photographs included and this document was circulated to the project team. This document was the starting point for the prototype screens. Example user interface sketches from the session are shown below:

View Module List, Module Information and E-Resources Use Case

Mock Screens

To get a more realistic view of the channel screens as they would appear in uPortal, mock versions of the screens were created. The creation of the mock screens was a different step to that in the NIIMLE development process. The NIIMLE team created Photoshop images of the channel screens but the SUNIWE approach was worthwhile because the HTML of the screens formed an ideal starting point for the creation of the XSL files later in the development process. The mock screens also allowed the development team to become familiar with the uPortal styling mark-up and work on the HTML styling issues separately from the transformations.

The mock screens were created in XHTML and the CSS file from one of the uPortal themes was referenced in the HTML to allow uPortal styles to be used. This ensured that the XHTML of each screen was exactly what the channel needed to output to render the screen and this XHTML could be used as the target for the XSL development work. An example screen is shown below:

Figure 1: Mock Channel Screen

The mock screens showed exactly what the screens would look like in a uPortal channel. Hyperlinks to other screens were used to simulate channel behaviour. This helped with reviewing the screens to ensure a consistent look and feel and way of working across the entire portal.

Analysis

With the initial requirements captured, the focus turned to analysis. Use cases were reviewed to identify requirements common to SURF and WETN. Data items were reviewed to ensure that data was available to support the use cases and any data protection issues were documented. Interactions of the portal with other systems were identified and the mapping of the data items to IMS Enterprise Service objects was defined. The analysis was captured as a set of storyboard documents, one for each use case, which the team used to guide the construction of the services and channels.

Throughout the development process it was important to identify any commonality between SURF and WETN wherever it existed. The key aim in the development of the web services was to create common services that could be used by both SURF and WETN. The WETN situation differed from SURF because the WETN development was more a case of implementing a new system than integrating existing systems and databases. The plan of implementing the portal at SURF and then cascading to WETN meant that the requirements were less well defined for WETN during this first analysis exercise. The WETN requirements would be analysed further in the Elaboration Phase with the benefit of feedback from the SURF analysis.

Use Case Analysis

Each use case was reviewed with the project partners to determine to what extent the services could already be provided by the NIIMLE outputs and what new services needed to be developed. Common services were identified where possible. The screens were reviewed to identify the data items that would be required from the student records databases.

Data Analysis

Data items were reviewed to:

1. determine whether the data existed for each partner

2. identify the location of the data at each partner if it did exist

3. identify and document any institution or business rules that governed or restricted the data that could be used

The process involved meeting with the MIS managers at the partner institutions to discuss data availability and constraints. In some cases the required data did not exist and the scope of the use case was modified accordingly or the use case abandoned.

Data Mapping

For each of the use cases, a mapping between the data fields being retrieved from the student records system and the IMS Enterprise Web services data structures was created. The IMS Enterprise Web services information models and specs were consulted to determine the best fit with the SUNIWE data. The mapping was captured in the storyboard documents, one for each use case. IMS Enterprise Web services operations that needed to be developed to support the use cases (in addition to the existing NIIMLE operations) were identified.

Interactions With Other Systems

Interactions with other systems were investigated. These centred around library and VLE systems. Details are in the project final report.

System Scope

As some use cases were ruled out through lack of data, the scope of the system narrowed until the list of use cases that were to be implemented was the following:

SURF

1. Authenticate Learner

2. Enrol Onto VLE Group

3. View and Change College Personal Information

4. View and Change University Personal Information

5. View and Launch VLE Modules

6. View College Course List

7. View Module List Module Information And E-Resources

WETN

1. Enrol Onto VLE Group

2. View and Change University Personal Information

3. View and Launch VLE Modules

4. View Module List Module Information And E-Resources

Storyboard Documents

For each remaining use case, a storyboard document was created. Each storyboard document included a section for each screen. Each screen section included:

1. a list of IMS Enterprise Web services operations required to get the data for the screen

2. a picture of the mock screen

3. a table containing details of the screen including the names of files associated with the screen, possible interactions of the user and user interface elements and actions

4. a table mapping the screen data items to the IMS Enterprise objects and database fields

The storyboard documents when complete acted as the primary reference for the developers during the rest of the development process. An example extract from a storyboard document for the Module List View screen is shown below

Storyboard Example

Module List View Storyboard Document

Web service operations:

readMembershipsForPerson(personSourcedId)

For each membership

readGroup(groupSourcedId)

Screen

Table9

Screen NameModule List View	ParametersbaseActionURL
HTML mock-upModuleListView.html	Form ActionsbaseActionURL
	Fields/ButtonsbutLaunch?Note: need to decide how to launch the module in the VLE - via buttons or another method?

Database mapping

Table10

Data item	IMS object/attribute	Notes	Source in SRS - Staffordshire University
Registration number	Person.sourcedId		Student.s_ref
Surname	Person.name.namePartType = ’Surname’Person.name.namePartValue = ’data’		Student.s_surname
Forename	Person.name.namePartType = ’Forename’Person.name.namePartValue = ’data’		Student.s_forename_1
Award title	Group.description		Combination of fields in conjunction with student enrolment information (eq takes into account study route, etc)
Award level			Student_enrol.se_level
Mode of study			Student_enrol.se_study_mode (for the HESA code) + Lookup.l_code_desc (where l_group = ‘MODE’ and l_code = se_study_mode) for the description
Module academic year	Member.timeframe.beginMember.timeframe.end	Allows flexibility of timeframes per student (not Group.timeframe)	Student_module_attempt.sma_start_academic_year?
Module title	Group.description		Module.m_title
Module code	Group.sourcedId		Module.m_module
Module cats credits	Group.extension.fieldName = 'cats'Group.extension.fieldType = 'Integer'Group.extension.fieldValue = 'data'		Module.m_cats
Module status	Member.recordInfo.comments	Vocab:Completed, not started, continuing	Student_module_attempt.sma_status (for code) plus lookup.l_code_desc (where l_group = ‘STUDENT_MODULE_STATUS’ and l_code = mv_status) for description
Module result	Member.interimResultMember.finalResult	Carry both and display as appropriate	Student_module_attempt.sma_result
Total credits achieved	No mapping	Calculated by client(?)	Not held
View type	Group.groupType.scheme = 'Module'	Indicates module view rather than course view

Design

The design of the channels was dictated by uPortal channel design guidelines and the Web services were based on the design of the existing NIIMLE services.

uPortal custom channels

The source code packages for the uPortal channels are shown below.

Figure 1: uPortal source code packages

IMS Enterprise Web Services packages

IMS Enterprise Web Services packages (org.imsglobal.www.specs.*) and classes were inherited from NIIMLE. The NIIMLE developers generated the IMS classes from the Web service descriptions (WSDL files) published as part of the IMS Enterprise Web Services specification using the Apache Axis WSDL2Java tool. WSDL2Java takes a set of Web service descriptions and generates Java classes for IMS Enterprise objects and Java classes and interfaces to for stubs, service interfaces and service implementations. The generated classes provided a framework for implementation of the services. The SUNIWE uPortal custom channels used the IMS Enterprise classes for data returned from the services.

uPortal packages

Some uPortal packages (org.jasig.portal.*) are shown in the diagram above. Most have been trimmed from the diagram to save space. There are a lot of uPortal packages. The source code for custom channels is in the same place as the source code for uPortal itself. uPortal runs as a web application within Tomcat. The process of developing a channel includes keeping a local copy of the entire source code for uPortal, adding the source for the custom channel to it, and running the uPortal build script to build the code and deploy it to Tomcat.

SUNIWE custom channel classes

SUNIWE portal content was implemented as uPortal Custom channels. The classes implementing the channels are shown below.

Figure 2: SUNIWE channel source code

The uk.ac.suniwe.common package contains:

1. classes implementing common utilities

2. common JavaBeans used by the service classes

3. properties files

Each custom channel has a package which contains the controlling class of the channel, e.g. CPersonalInformation.java. The controlling class responds to events from uPortal, determines which screen to display and invokes the screen rendering class. Rendering classes are stored in a views package under each channel package. Each screen of the channel has a class which handles rendering of the screen. This involves calling Web services to get the data, storing the returned data in JavaBeans, getting an XML representation of the data, transforming the XML into presentational XHTML, and forwarding the XHTML to uPortal for further processing. The XHTML then undergoes uPortal transformations to position and style the content ready for display in the portal.

Figure 3: SUNIWE channel stylesheets

Each screen has a XSL stylesheet which is used by the channel to transform the XML received from the Web services into XHTML. The XHTML includes uPortal CSS markup to ensure that the channel content assumes the look and feel of the current uPortal theme/skin. The stylesheets are stored in a different are of the uPortal source tree from the channel source code.

Each channel also has a corresponding stylesheet list (SSL) file. This contains a list of stylesheets for the channel and rules for when to use the stylesheets. This enables different presentation of the same content depending on the type of browser or platform.

Web services

The source code packages for the Web services are shown below.

Figure 4: Web services source code packages

Client package

This package includes the command line test client written by Greg McClure for simple testing of the Web services. It also includes SQL scripts and sample anonymised data for populating the MySQL test database.

IMS Enterprise Web Services packages

The same Web services packages and classes were used as in the uPortal channel implementations. The IMS classes referenced classes in the SUNIWE packages for the implementation of the service operations.

SUNIWE implementation packages

SUNIWE implementation classes (uk.ac.suniwe.*) handled service requests, queried databases to get the data and constructed service responses.

Figure 5: SUNIWE Web service implementation classes

The common package (uk.ac.suniwe.common) contained:

1. classes implementing common utilities

2. common JavaBeans used by the service classes

3. properties files

Each service had a package of classes which implemented operations of that service. Service packages followed the same pattern of classes. For example, the Group Management Service package (uk.ac.suniwe.gms) contained:

1. GroupManagementServiceSuniweImpl.java – implemented the service operations

2. SuniweGMSSQL.java – handled querying the database and populating JavaBeans with the data

3. SuniweGMSTransformer.java – handled transforming data from the JavaBeans into IMS objects

Construction

The Construction Phase was concerned with building the system ready for beta testing. The earlier phases had reduced the scope of the SURF implementation down to two uses cases which covered a lot of the features outlined in the original scenarios. The simpler use case had been realized in the Elaboration Phase so the Construction Phase involved realizing the remaining use case and preparing the WeTN development staff for their development activities. All major technical risks other than Shibboleth had been tackled in the first two phases so the construction work was straightforward. Shibboleth investigations continued throughout the Construction Phase.

The use case followed the same pattern of development which was:

1. Use the fully described use case as the requirements definition to ensure that the focus of development is on implementing a feature of value to the Learner

2. Develop the UPortal channel

   1. Storyboard the user interface to clarify look and feel, usability and navigation issues and to establish what UPortal channel screens and components will be required to realize the use case

   2. Design, develop and test the XML and Schema used to drive each UPortal channel screen

   3. Design, develop and test the XSL stylesheet used to determine the presentation of each channel screen

   4. Design, develop and test Java classes to handle data and rendering for the channel

   5. Deploy, test and refine the channel

3. Develop the Web service

   1. Determine which IMS Enterprise Web Services operations to implement to support the use case

   2. Determine which IMS Enterprise Specification elements to use for wrapping the data output by the Web service

   3. Create a mapping between the data objects used within the SUNIWE web service implementation and their IMS Enterprise equivalents

   4. Develop SUNIWE classes to store and output data from the database

   5. Develop SUNIWE to IMS Enterprise transformation classes to convert between SUNIWE data objects and IMS Enterprise representations

   6. Create database views against which SQL calls can be made to provide the data for the Web service

   7. Modify the IMS classes to hand off implementation of operations to SUNIWE classes

   8. Develop the SUNIWE classes to implement the Web service operations

   9. Deploy, test and refine the Web service

The channel and Web service development tasks were again tackled independently. This allowed multiple developers to work concurrently with the outputs brought together when all tasks were completed. As before, storyboarding the UPortal channel screens and labelling all the screens and screen components consistently was essential to allow this division of labour to work. The channel development could be split between the roles of Java developer and user interface (UI) developer. The Java developer would develop the channel controlling and rendering classes. The UI developer would develop the XSL stylesheets.

Development Practices

Project Communication

Meetings

As the project team were distributed across three countries, meetings were held primarily using telephone conferencing to reduce travel costs. These meetings were at least monthly.

Face to face meetings were held quarterly and additionally as necessary. JISC meetings were also exploited (e.g. programme meetings) as another chance to get members of the project team together.

The project maintained regular contact with the programme manager and supplied a number of informal updates. Members of the project attended all JISC programme meetings, and showed a poster at the meeting in Oxford.

Developers involved in the Shibboleth work attended a series of Shibboleth related events, including those organised by the Middleware Assisted Take-Up Unit (MATU).

Email

An email list was set up at Staffordshire University for email discussions within the project.

Ultimately, little use was made of the mailing list and project communication happened via standard email and the Wiki.

Web Site

A project web site was set following standard JISC project practice but the project team also made use of a wiki for collaboration between the project team members.

Wiki

A wiki is essentially a web site where the content can be easily and quickly edited by users. TWiki was used in the SUNIWE project.

The Twiki web site (http://twiki.org/) describes it as “a flexible, powerful, and easy to use enterprise wiki, enterprise collaboration platform and knowledge management system. It is a Structured Wiki, typically used to run a project development space, a document management system, a knowledge base, or any other groupware tool, on an intranet or on the internet. Web content can be created collaboratively by using just a browser.

TWiki looks and feels like a normal Intranet or Internet web site. However it also has a Edit link at the bottom of every topic (web page), everybody can change a topic or add content by just using a browser.”

Figure 1: The SUNIWE Wiki

The main benefit of the wiki compared to a traditional web site was that it enabled all of the project team to create and edit content. Files could also be uploaded easily and linked to from the text of the wiki pages to allow all project artefacts to be contextualised. This enabled the wiki to act as a central repository for project information, documents and files. Meeting minutes, the project plan, files used in development, outputs of the development process and discussions were all captured on the wiki. The email alerting facility of the wiki was configured to inform the project team when each topic had been updated so the team could keep up to date with the project information without wasted visits to the wiki site.

TWiki was chosen because it had a fine grained authentication and authorisation system allowing access to be configured for users down to the page level. This enabled the wiki to be set up for private use within the project team. The role of the wiki was different to the web site. The wiki was used for internal project communication and discussions. The project web site was used for dissemination of progress and outputs to the wider JISC community.

It was important to have a private project area to allow the team to communicate unhindered by consideration of a wider audience. A more public facing area would have stifled project discussions.

Although SUNIWE did not make use of it, the wiki could have been configured to have a separate public area which could act as the project web site. This would have been a good approach as the focus on the use of the wiki tended to leave the project web site neglected.

The wiki had disadvantages as well as benefits.

1. The structure of the wiki continually evolved during the project. As the content grew, long unwieldy pages or complex navigation often forced a restructuring. After each restructuring the project team would be greeted with an unfamiliar layout. This instability of structure was a barrier to effective use of the wiki.

2. The bulk of the content was created by one or two individuals. This was partly because of the unfamiliarity of the wiki concept. There was an understandable reluctance to restructure or change the content. This reduced the collaborative aspect of the wiki.

3. The securing of the wiki private area imposed a maintenance overhead. Accounts had to be created and managed and permissions configured on wiki areas.

Development Tools

The hardware and software required to support the development effort was set up as follows:

Each developer PC ran all of the software components on a single machine for testing. All web applications ran within the same instance of Tomcat and the Web services queried against a MySQL database.

1. Tomcat

   1. uPortal

   2. Axis

   3. Shibboleth IdP web application

   4. Shibboleth SP web application

2. MySQL

3. Shibboleth IdP

4. Shibboleth SP

A development server ran the same components to allow PCs and the server to test Shibboleth and Web service interactions across the network.

The development team used the MyEclipse IDE, a cheap, subscription-based version of Eclipse, pre-configured with lots of plug-ins for Java, database and Web development.

The development team maintained the source code in a CVS repository on the development server. Eclipse includes a lot of functionality for team working with a CVS code repository.

MyEclipse includes a database perspective to enable viewing and interacting with databases. As well as this functionality, the developers used DbVisualizer, a free version of which is available, which performs the same job. It allows dynamic querying of the database and shows database structure and properties, all very useful when checking the operation of the Web services.

Apache Ant was used to build and deploy the source code. The uPortal source code came with an ant script which was modified to include the SUNIWE source in the build where necessary. An ant script was written for the Web services source code to speed up build and deployment of the Web services code to run under Axis.

Tcpmon, a tool that comes as part of Apache Axis, was used to monitor TCP traffic between the portal channels and Web services. This allowed inspection of the SOAP requests and responses to ensure the information was correct.

Logging and Exception Handling

Two essential practices helped to preserve developer sanity during the creation of the Web services and portal channels. Logging and chaining exceptions in the source code.

Logging statements are a crude method for debugging but sometimes logs are the only source of information. The SUNIWE system was built upon layers of web applications, each potentially with their own logging configuration and logs. It was vital to institute a consistent logging approach across all these applications. Otherwise, developers could easily spend a long time trying to track down logs and log messages.

The Apache Commons Logging package was used for logging in the SUNIWE code. Commons Logging is an ultra-thin bridge between different logging implementations which allows changing of the underlying logging implementation without recompiling code. Log4J was used as the logging implementation. The combination of commons logging and Log4J enabled detailed logging messages to be easily created. Each log message would include information about the context of any error. Log4J gave control over the granularity of the logging. Logging could easily be configured for individual classes, packages or across the whole codebase and the type of logging messages output could be controlled in a similar fashion.

Where possible, the Web applications (uPortal, Axis, Shibboleth IdP and SP) and Tomcat itself were configured to use Log4J via Commons Logging. This reduced the complexity of the logging set up. The logging was configured to create a separate log for each Web application but to put all the logs in the same directory. The other approach was to make all the Web applications append to the same log but this resulted in huge logs and confusion where log entries from different Web applications were interspersed. Defining and testing the logging configuration for the Web applications was a time consuming and fiddly business but the resulting collection of coherent logs was well worth the effort.

Exception objects in Java represent exceptional conditions that occur while the system is running. Exception chaining is a method of setting up an association between exception objects. This allows the root cause of a problem to be persisted even though the surrounding exception type might change as it is propagated through the program until it is dealt with. Without this association, the developer would have no way of identifying the original cause of an exception.

In the SUNIWE code, service exceptions often had to be propagated to the uPortal framework as input/output (IO) exceptions. This involved catching a service exception and throwing an IO exception with the root cause set to be the original service exception as illustrated in the code below.

From the PersonManagementService SUNIWE implementation

              try
            {
                personManagementServiceSync = 
    personManagementServiceSyncLocator
    .getPersonManagementServiceSyncSoap(pmsURL);
            }
            catch(javax.xml.rpc.ServiceException e)
            {
                IOException ioException = new IOException(e.getMessage());
                ioException.initCause(e); // chain ServiceException 
                throw ioException;        
            }
    
      

The result of implementing the above was log entries that clearly identified the context and nature of the root cause of any exception or error.

Remote Collaboration and the WeTN Portal

While portal construction was taking place at SURF, the Wales e-Training Network was piloting and evaluating a number of on-line modules designed as components of an all-Wales on-line Foundation Degree programme. The full roll-out of that qualification was to happen in 2006/2007 and WeTN was engaged in a validation process that would allow multi-institutional collaborative delivery. For that to be successful, new collaborative systems of delivery and support were needed, together with software to facilitate such systems. SUNIWE was seen as an important test bed to see if uPortal and Shibboleth could provide the services required. The intention was to provide single-sign-on access to distributed resources across the Wales e-Training Network.

The plan was to set up access from uPortal to the Coleg Sir Gar virtualcollege VLE to test access to learning resources. Discussions were held with the MIS staff responsible for the student record system at Coleg Sir Gar and a separate mirror server was set up for testing data transfer to uPortal.

After a repeat of the SURF code bashes at Coleg Sir Gar, training sessions were held to get WETN staff familiar with the codebase and to install the Web services and channel that implemented the first use case. After two face to face sessions, the project team used a combination of VNC and Skype or telephone communication to hold remote training sessions.

VNC software allows the user to see the desktop of a remote machine and control it with mouse and keyboard, just like the user would do sitting in the front of that computer. SUNIWE developers used the free TightVNC software (http://www.tightvnc.com/). Skype (http://www.skype.com/) is a peer-to-peer Internet telephony network allowing free voice communication between computers.

With a tweak or two to network settings the combination of applications allowed developers at SURF to talk to developers at WETN and control the laptops at WETN as though they were present at Coleg Sir Gar. With Tight VNC and Skype remote sessions could be held without any cost for travel or communication. The network connection did not always stand up to the amount of data being transferred so a speaker phone was sometimes substituted for Skype. Even with the cost of the call it was a much cheaper exercise in time and money than a physical visit by one of the developers.

Shibboleth

The most significant technical risk of the project was the use of Shibboleth to secure the SUNIWE components. After the code bashes the project team were content that the NIIMLE components would work in the SURF and WETN environments but none of the team had experience of Shibboleth.

Shibboleth is an authorization system designed to allow organizations to exchange information about their users in a secure and privacy-preserving manner. Attributes about an individual can be transferred across security domains between institutions. This attribute exchange enables a user to access resources at an institution other than the one at which they authenticate. For example, Shibboleth might allow a user to log in at their college and use resources at other colleges or the University without having to log in again.

Overview

Shibboleth has four key concepts:

1. Identity Providers

2. Service Providers

3. Where Are You From Service

4. Federations

Identity provider

An identity provider (IdP) allows the user to authenticate stores information about the user as attributes. When a user authenticates, the IdP creates a privacy-preserving handle for the user which can be used by service providers to request user attributes.

Service provider

A service provider acts as a guardian of a Web resource. If a user has already authenticated, it requests attributes from the IdP and makes a decision to grant or deny access to the resource based on the attribute values. If the user has not authenticated, it redirects the user to the where are you from service.

Where Are You From Service

The where are you from service (WAYF) provides the user with a list of institutions (IdPs) and allows them to choose at which one they wish to authenticate. The WAYF then redirects the user to the chosen IdP.

Federations

The Shibboleth architecture is based on trust. A Shibboleth Federation is a group of institutions who agree a common set of policies, practices and standards for authentication, security of components and the exchange, use, and population of user attributes. This allows the trust model to work between institutions. SPs will accept attributes from any IdP in the Federation.

Shibboleth Components

The diagram illustrates the interaction of the Shibboleth components in the case of a user requesting access to a resource having not yet authenticated. The steps are described in the list below.

Figure 1: Shibboleth Component Interactions

1. In a web browser, the user attempts to access a resource protected by the service provider.

2. The user is not authenticated so the user is redirected to the Where Are You From (WAYF) service.

3. The WAYF service asks the user to choose an institution (IdP) to authenticate at.

4. The user chooses an institution (IdP).

5. The user is redirected to the Handle Service of the chosen IdP.

6. The Handle Service works with the local Single Sign-On (SSO) system to ask the user to authenticate.

7. The user supplies credentials to authenticate (e.g. username and password).

8. If the credentials are valid the Handle Service generates a handle for the user and supplies it to the Assertion Consumer Service (ACS) of the SP.

9. The ACS validates the handle, creates a session and transfers the handle to the Attribute Requestor (AR).

10. The AR request attributes from the Attribute Authority (AA) of the IdP using the handle.

11. The attribute authority supplies attributes in the form of assertions.

12. The attributes are used by the SP to determine whether to permit access to the resource.

13. If permission has been granted the user is able to access the resource.

Privacy

Shibboleth includes mechanisms to allow users to control which information about them is released in the form of attributes, typically via a Web-based interface. Many access control decisions are based on membership of groups (e.g, faculty or course) for which identification of the user is not necessary. Because a temporary handle is used in Shibboleth as a reference to the user the identity of the user is concealed. The SP gets only the information it needs to make the access control decision and no more.

SUNIWE Shibboleth Deployment

The intention with the SUNIWE deployment of Shibboleth was to have Identity Providers and Service Providers at each of the partner institutions. Identity Providers at each institution would enable users of the portal to authenticate at their home institution. Protection of the portal and each of the Web services by an SP would allow the portal to aggregate data from multiple partners while preserving user privacy and security. The implementation of a Shibboleth-based authorisation system would enable the institutions to grant access to a learner’s record based on assertions made about that learner by trusted partner institutions. This was seen as an important step forward in enabling true lifelong learning.

At SURF the plan was to implement Shibboleth to allow students federated access to personalized course information, personal information and targeted e-resources via uPortal. Access would be from within the University and from the two SURF college partners (Stoke on Trent College and Shrewsbury College of Art and Technology) and would prove the concept of federated access from anywhere within SURF. The implementation would involve integrating Shibboleth into the University authentication and authorisation practices, “shibbolizing” applications and services that would be delivering the personalised information and resources, and creating the SURF shibboleth federation to include the University and the two Colleges involved in the implementation.

At WeTN, work was led by Coleg Sirgar. Swansea implemented Shibboleth and uPortal as part of other work early on in the course of the SUNIWE project and so were a good source of expertise. Swansea were using a channel for VLE access and access to learning resources as well as personal information.

Approach

Feasibility work began at SURF on the application of Shibboleth and organisational issues that might cause problems were documented. Following a period when the Shibboleth work was being covered by existing staff, a technical developer was appointed to work exclusively on Shibboleth. Technical members of the project team attended Shibboleth presentations at JISC Programme meetings and the Shibboleth Early Adopters Workshop to get up to speed with the Shibboleth technology.

The project team met with staff from the Middleware Assisted Take-Up Service (MATU) and outlined the objectives of the Shibboleth implementation at SURF. MATU highlighted the aspects of the implementations that required further investigation but had no problem with the general concept of portal and Web services being secured using Shibboleth. If the project team could determine the required attributes then MATU would advise on the architecture of the implementation.

The main activities that resulted from the meeting were:

1. to scope the Shibboleth implementation and, hence, determine what hardware and software configuration would best support that

2. to consult similar Shibboleth projects to gather advice

3. to determine what attribute sets would be required and set attribute release policies

Scoping the Shibboleth implementation

Shibboleth-related use cases were developed to scope the requirements of the Shibboleth implementation. Required components for the deployment of a Shibboleth proof of concept prototype were identified and a plan for deployment created.

Figure 2: Shibboleth component deployment at SURF

Deployment plan:

1. Develop Federation Agreement

2. Implement Staffordshire University single sign-on test system

3. Install and configure IdP and SP at Staffordshire University

4. Shibbolize uPortal

5. Shibbolize Web services

6. Test uPortal single sign-on integration

7. Implement College IdP and SPs

8. Implement Web services at Colleges

9. Test operation of Web services under Shibboleth protection at Colleges and University.

10. Refine Shibboleth implementation

Consulting similar projects

MATU suggested visiting the JISC KC-ROLO project which had integrated Shibboleth with a ‘Shibbolized’ instance of Moodle. The project team had attended a number of presentations from KC-ROLO project members whilst attending Shibboleth-related JISC events but the objectives of the KC-ROLO implementation differed from that of SUNIWE. KC-ROLO did not involve any Web services or aggregation of personal information. Similarly, the Swansea Shibboleth implementation was focused on access to resources by group rather than individual and there was no use of Web services. Both the KC-ROLO and Swansea implementations provided useful advice and information about integrating applications with Shibboleth but the scope was sufficiently different from SUNIWE that neither could provide advice about the Web service and portal aspects of the deployment. The other early adopter projects were looked at but none was using Web services.

The SURF development team liaised with the JISC Shibboleth-enabled Portals and Information Environments (SPIE) Project. The outputs of the SPIE project were used to integrate the portal (uPortal) with Shibboleth and the SPIE project team were a good source of advice for configuration problems encountered during the implementation.

Also, Staffordshire University had an internal Access, Authentication and Authorisation (AAA) project underway which sought to incrementally implement a single sign-on (SSO) facility for University applications. The AAA project manager was consulted to contribute expertise to the project and schedule the introduction of SSO for the SUNIWE portal and the introduction of Shibboleth in general.

Determining attribute sets

The SUNIWE use cases and data were analysed to identify attributes required to implement Shibboleth authorisation. The primary attribute required was the reference number of the learner. The dynamic information displayed by the portal would be provided by the Web services. The Web services had to conform to the IMS Enterprise Services specification which defines the type of data sent to and returned from the Web service for each operation. For example, to get personal information about a learner, a channel in the portal would call the readPerson operation of the Person Management Service. The readPerson operation is defined as:

readPerson(in sourcedId:Identifier, out person:Person) : StatusInfo

This means the readPerson operation takes an identifier (i.e. the learner reference number) and a person object as arguments, populates the person object with attributes of the learner if the request is successful, and returns information about the success or failure of the request in the StatusInfo object.

The subset of IMS Enterprise Service operations that SUNIWE intended to implement were:

1. Person Management Service

   1. readPerson(in sourcedId:Identifier, out person:Person) : StatusInfo

1. Group Management Service

   1. readGroups(in sourcedIdSet:IdentifierSet, out groupIdPairSet:GroupIdPairSet) : StatusInfoSet

1. Membership Management Service

   1. readMembershipsForPerson(in personSourcedId:Identifier, out membershipIdPairSet:MembershipIdPairSet) : StatusInfoSet

The only attribute required to allow the Web services to be called was the learner reference. The learner reference was needed as an identifier for the readPerson and readMembershipsForPerson operations. The set of group IDs required for the readGroups operations would be returned by the readMembershipsForPerson operation as part of the membershipIdPairSet.

This presented an interesting issue for the development team. One of the founding concepts of Shibboleth is the preservation of privacy. This sits well with most applications of Shibboleth where decisions are based on attributes such as membership of groups, courses, awards, etc. The SUNIWE portal, on the other hand, in providing personalised information to users, required the user’s reference number to be used as an attribute. This was another aspect of SUNIWE that differed from the other Shibboleth related projects. The project team could not find any other projects that had implemented personalisation at this level. Being inexperienced with Shibboleth, the team were uneasy about the implications of specifying a user via the learner reference but it was hard to find anyone experienced enough to provide definitive advice on the best approach.

Deployment

The deployment plan was followed and a number of problems were encountered. Ultimately some of the problems were insurmountable and prevented the use of Shibboleth in the SUNIWE project.

The Shibboleth components were installed on servers at Staffordshire University and locally on development PCs. The Shibboleth IdP and SP both consist of an application and a web application. Installation of the Shibboleth components was trivial. It was the configuration of Shibboleth to integrate into existing infrastructure that presented more of a challenge.

The development team integrated uPortal into the Shibboleth setup using guidance from the JISC Shibboleth-enabled Portals and Information Environments Project. Project members benefited from liaison with members of the SPIE project to solve installation and configuration issues.

The intention was that each of the SURF Colleges would implement the Identity Provider and Service Provider to allow federated access to information from each institution. To this end, the development team and MIS staff from the Colleges worked to outline and set up the required infrastructure to support the Shibboleth and Web services implementations. A solution involving duplicate read-only databases to be accessed by the Web services was identified as the most appropriate solution to providing the data.

The network specialists at each college were consulted regarding integration of the Shibboleth components to allow access to these databases. There was understandable reluctance from the network specialists to allow access. The Shibboleth technology was unknown to them and at the time the development team were talking to them a Shibboleth solution for SURF had not been identified. One of the colleges used a third party provider for their network security infrastructure so there was another layer of staff to convince of the validity of the Shibboleth approach. Another barrier to proceeding was the lack of a local heavyweight champion at the colleges. Local project team members at the colleges could talk to the MIS and network staff but had no influence over the priorities of those staff. The relative importance of the SUNIWE work could not be gauged.

Shibboleth model

With these concerns in mind, the original intention of deploying a proof of concept implementation of the web services and channels distributed between Staffordshire University, Stoke College and Shrewsbury College was scaled back. Instead a local model of the Web services and Shibboleth architecture was developed which ran in the LAN at Staffordshire University and consisted of a server and two PCs. The server hosted the portal and each PC played the part of one of the colleges. The PCs had databases which duplicated the user directories and student record systems at each of the colleges and provided data for the portal channels via the Web services.

The advantage of the local model approach was that it:

1. allowed the team to explore development and configuration in a safe environment

2. used security components that could be configured locally and that mapped directly to production-style equivalents making it easier to determine how the model would map to existing security infrastructure at the colleges

3. provided a basis for better describing the operation of Shibboleth and requirements to the college network/MIS staff to give them a better understanding of Shibboleth and help break down political barriers to use of Shibboleth.

Whilst developing the model, a number of fundamental issues were identified.

Problems Implementing Shibboleth

Shibboleth and IMS Enterprise Web Services

Conflicting constraints hindered the ability to aggregate data from multiple institutions in the portal when using Shibboleth. This was caused by a combination of three factors:

1. the Shibboleth requirement for authentication at a single institution

2. the different learner reference numbers in use at each institution

3. the IMS Enterprise Web service requirement for use of a single identifier for the learner

Shibboleth via the Where Are You From (WAYF) service, required that a learner authenticate at a single IdP, so either at a College or the University but not both. The IdP would hold attributes about the learner including the learner reference number. Shibboleth SPs could request this learner reference and use it to access the Web services,

The learner reference number was specific to the institution. A learner on a foundation degree would have a reference number from their registration at the University and another from their registration at the College delivering the Foundation Degree. The reference numbers were allocated according to local procedures and there was no way to link reference numbers that referred to the same learner across institutions.

The learner reference number was used in the calls to the IMS Enterprise Web services to identify the learner. In the background, the learner reference number was used to query the student records systems to return personal information.

If a learner authenticated at a College, the College IdP would have the College learner reference number as an attribute. If the learner accessed the portal, the portal channels would call the Web services and supply the College learner reference number as identifier. The Web service at the College would return College personal information but the Web service at the University would have no record corresponding to the College learner reference and, hence, would not return any information.

In the same way, if the learner authenticated at the University, Shibboleth would pass around the University learner reference number which would mean nothing to the College Web services so only the University information would be returned.

At the time of writing (August 2007) the Shibboleth roadmap includes the following features which might be implemented after Shibboleth v2.0 is released so the problem above may be addressed by Shibboleth in the future:

1. Support for SAML 2.0 NameIDManage, NameIDMapping request/response pairs

2. Ability to link accounts between multiple Identity Providers

3. Use linked accounts to gather attributes from multiple Identity Providers

Historical Identities

One of the original SUNIWE scenarios described the portal providing a list of previous College courses the learner had taken. Investigation identified that whilst Colleges kept such historical data, the learner accounts were removed when the course was completed. This meant that although the information might exist, the learner would have no credentials or current learner reference number for the College which could be used by the portal to gather the information from the Web services.

Shibboleth vs Portal/Web services

Every Shibboleth presentation attended by the project team demonstrated the same features, namely accessing resources with a Web browser. In such circumstances, Shibboleth can redirect the user to the IdP, the Web browser can prompt the user for credentials to authenticate, and Shibboleth can finally redirect to the intended resource once authentication is successful. Portals and Web services present a multi-tier use case which is not catered for by Shibboleth.

Web service requests and responses are carried as SOAP packets. SOAP forms the foundation layer of the Web services stack, providing a basic messaging framework. Interactions between the portal channels and the Web services happen in the background with no interaction with the Web browser. Shibboleth is currently based on the SAML V2.0 specification which does not include profiles that provide complete authentication solutions for SOAP. The current version of Shibboleth (1.3) or the next version (2.0) do not provide any support for this either.

Another missing piece of the puzzle is modelling of the delegation aspect of portal behaviour. When a learner uses the portal, the each portal channel acts as an application which asks for information on behalf of the user. The learner delegates to the channels to get the information and each of these actors needs to be represented in the security assertions. Delegation security semantics are not included in SAML V2.0 or Shibboleth.

Outcome

For the reasons outlined above, Shibboleth was an inappropriate solution for the SUNIWE portals. It took the majority of the project duration to find this out. There seemed to be a wealth of information about what Shibboleth could do but no information about what it was not suitable for. Local staffing issues also affected the duration. Work on the Shibboleth solution was hampered by the loss of one of the development staff at SURF. Because it was decided not to replace the developer who had left, the remaining staff had to divide the channel and Web services development work between them which diluted effort on the Shibboleth investigations.

With the Shibboleth approach ruled out, the focus turned to trying to implement a Shibboleth-like solution which would encompass the portal and Web services. The Liberty Alliance Identity Web Services Framework (ID-WSF) 2.0 specifications were identified as the most appropriate solution. Semantics for delegation were included and the Shibboleth 2.0 roadmap on the Shibboleth wiki stated that a future version of Shibboleth might subsume the Liberty Alliance ID-WSF specification to handle Web services. The downside was that the development team was starting again from scratch with a different set of specifications towards the end of the project and ultimately we ran out of time to implement a solution. The Shibboleth model was ported to WeTN where some use cases covered direct Web browser access to resources but the Web services remained unsecured. Despite project-long effort to address it, the key critical risk remained unaddressed and prevented the portals from being piloted.

Data Protection Issues

The Approach

The plan was to use previous NIIMLE and WeTN agreements as a starting point for the development of an agreement between the SURF partners in SUNIWE. It was envisaged that service-based approaches would arise from current and future projects within SURF and Staffordshire University, so it was seen as an opportunity to establish an agreement with the whole of SURF. The aim was to produce an agreement that could be adopted by WeTN for the WeTN portal.

An agreement was required because of the origin and nature of the data being displayed by the portal. Each institution in SURF held personal data about the learner (name, address, etc) and acted as data controller for that data. The project proposed that a user would authenticate at their local institution and use the portal to view personal information from each institution that they were registered with. The personal information would be provided via Web services which would each query the student record system at their institution. The portal would call the Web services and aggregate and display the data. The portal would be hosted centrally on a Staffordshire University server. The key data protection issue was that information from the SURF Colleges would be processed by Staffordshire University in the portal. This would require an agreement between the data controllers (all of the institutions) and the data processor (Staffordshire University) where the portal was hosted.

Pilot Agreement

The Staffordshire University Information Protection and Security Officer and the University Solicitors were consulted. The agreements from previous JISC projects (JISC-SHELL and NIIMLE) were reviewed as a starting point but these were focused more on learner records rather than personal information. It was decided that the most pragmatic way to progress was to pilot an agreement with the project partner colleges at Stoke-on-Trent and Shrewsbury to cover the SURF portal pilot. This pilot would then be evaluated and the agreement amended accordingly. Finally the agreement would be rolled out to the rest of the SURF Colleges. The pilot agreement or the amended agreement would be used for the WeTN portal depending on the timing of the WeTN portal pilot. WeTN investigated their requirements relating to the agreement in parallel with SURF so that all requirements could be considered for the SURF pilot agreement. At WETN tutors were planned to be more involved in accessing information.

In discussions of the workings of the portal with the various experts, it was important to stress that the learners would not have direct access to the student record databases as the information would be delivered via a Web service with a tightly defined set of operations limiting the information that would be delivered. Learners would only have read access to the information their institution held about them. Similarly the University would not have direct access to the College databases. It was also important to make it clear that the processing of the data by the University was purely presentational, i.e. raw XML from the Web services was turned into XHTML for display.

Communicating the concepts of the service-based approach to the non-technical legal experts was a challenge. It was essential to get the technical experts to explain the workings of the system directly to the legal experts. Passing on detailed information about the system to the legal experts via an intermediary was quickly found to be counter-productive. The best arrangement was to get the legal, DP and technical experts together.

Scope at SURF

The portal would only be accessible to students on Staffordshire University courses hence the data protection agreement would only apply to students on Staffordshire University courses within the SURF Colleges. It was agreed that the DP consent form that students sign when they join the University would be sufficient to cover this use of the data.

Other Requirements

The project had identified a requirement related to e-resources for sending information to specific groups of users, e.g. the Careers Service would like to send specific information to particular ethnic groups and social groups. The personal information could not be used to target groups in this manner, but the requirement could be satisfied via a subscription-style solution, e.g. a general statement to all learners on a portal page saying something like “If you would like information on….click here”. It would need to include a disclaimer covering how the learner’s personal details would be used and how long those details would be kept.

Test Data

Because of the personal nature of the information, data used in development and testing of the Web services and portal needed to be anonymized. This was done by exporting data from the databases and writing scripts to shuffle and edit fields.

The Agreement

After a long process of redefinition and refinement, the pilot agreement was produced which included the following:

1. A description of the objectives of the portal pilot

2. Details of the services the portal is composed of

3. The roles and responsibilities of the parties in the agreement

4. Definition of the length of the pilot agreement

5. Obligations of the University in hosting the portal

6. Obligations of the institutions in hosting the Web services.

7. Details of the evaluation of the portal/agreement

8. Termination arrangements

9. Limitation of liability

10. Confidentiality obligations of each party

The agreement is available from the downloads section.

IMS Enterprise Issues

A conflict between award to module relationships and the IMS Enterprise Group Management Service operations was identified. At Staffordshire University, learners have a choice of which modules to take to work towards an award. Consequently, there is no static relationship defined between awards and modules. Each module could be a part of several awards. It is only within the context of an individual learner that the relationships exist. In other words, for an individual learner, an award will be composed of a collection of modules, but for another learner, the collection of modules composing the same award might be completely different.

The IMS Group Management Service readGroups operation can be called with a collection of group IDs only. The learner cannot be specified which meant that, for the Staffordshire University implementation of the operation, group relationships could not be returned with the rest of the group data. To allow the relationship between awards and modules to be retrieved, the development team added an extension to role data returned by the readMembershipsForPerson operation. Because readMembershipsForPerson is called with the learner ID the relationships between the awards and modules for that learner could be retrieved from the database.

Outputs and Results

The project successfully created the portal components of the intended system including Web services and portal channels to provide a personalized environment for the user. Unfortunately, the lack of an appropriate method to secure the system meant that the intended piloting of the portal could not take place. With this result in mind, the key outputs of the project are seen as the following.

Software

The SUNIWE software will be available for download from the project web site together with guidance for setting up the portal system using the supporting applications. The software is comprised of the uPortal channels and IMS Enterprise Web services which allow the realization of 2 use cases

uPortal Channels

Two uPortal channels were developed to support the two main SUNIWE use cases:

1. View and Change Personal Information

2. View Module List, Module Information And e-Resources

The two channels are shown running side by side in uPortal below.

Figure 1: SUNIWE uPortal channels

View and Change Personal Information Channel

Figure 2: View and Change Personal Information Screen Flow

The View and Change Personal Information Channel allows the learner to view personal information the institution holds about them and submit a request to change the information if it is incorrect.

Personal Information View screen

Figure 3: Personal Information View screen

The Personal Information View screen displays personal information from the institutions student records database. The channel calls the IMS Person Management Service Web service to provide the data. If any of the information is incorrect the learner can select the change button to proceed to the editing screen.

Personal Information Edit screen

Figure 4: Personal Information Edit screen

The Personal Information Edit screen allows the learner to edit the personal information and submit a request for it to be updated. The OK button submits a request via email to appropriate staff at the institution. The cancel button takes the learner back to the Personal Information View screen.

Personal Information Confirm screen

Figure 5: Personal Information Confirm screen

The Personal Information Confirm screen displays a message to the learner upon submission of the update request. The message tells the learner that the request feeds into a manual process and that the information will be updated within a certain period of time. The OK button takes the learner back to the Personal Information View screen.

View Module List, Module Information and e-Resources Channel

Figure 6: View Module List, Module Information and e-Resources screen flow

The View Module List, Module Information and e-Resources channel allows the learner to view a list of awards and modules they are taking together with their current status on each module or award and results and credit values where available. More detailed module information can be viewed and modules supported by the COSE VLE can be launched in the portal.

Module List View screen

Figure 7: Module List View screen

The Module List View screen shows a summary list of awards and modules the learner is taking. Transcript style information is shown for each module (e.g. cats credits, module status, result). Clicking on the title of the module shows more detailed module information in the Module Information View screen. A launch link is displayed for modules that have a corresponding VLE component. Clicking the launch link launches the VLE in the portal. The Module List View calls all of the implemented Web services to get the data it needs for display on screen.

Module Information View screen

Figure 8: Module Information View screen

The module information view screen displays the descriptor for the selected module. The module descriptors are available on the University web site so the links from the Module List View screen are to the pages on the web site. The information appears within the channel.

VLE screen

Figure 9: VLE screen

The launch links on the Module List View screen launch the COSE VLE in the channel. All the functionality of the VLE is available. The only difference from launching the VLE manually is the screen size available. The amount of room for the VLE is constrained by being inside the uPortal channel. The links from the Module List View screen could be made to launch in a new window but this would sacrifice the user interface consistency of having everything running in the same portal.

Services

A small subset of IMS Enterprise Web Services were implemented sufficient to support the uPortal channels. The service operations were:

1. Person Management Service

   1. readPerson

1. Group Management Service

   1. readGroups

1. Membership Management Service

   1. readMembershipsForPerson

The View and Change Personal Information channel called the readPerson operation to get personal information about the learner for display.

The View Module List, Module Information and e-Resources channel called the readPerson operation to get personal information about the learner, the readMembershipsForPerson operation to get the award and module transcript-style information and the readGroups operation to get details of the awards and modules (title, etc).

Data protection agreement

The data protection agreement is the product of extended and significant, not to mention costly, collaboration between experts from the legal, technical and operational sides of the project. It covers the essential aspects requiring agreement for the running of a cross-institutional portal supported by Web services and would be a good starting point for any projects embarking on implementing a similar agreement. The data protection agreement is available from the download area.

Shibboleth report

The Shibboleth findings are summarized in the Shibboleth section of the Web site and can be downloaded in PDF form by clicking on the PDF link on the Shibboleth page. It is hoped this document will act as a guide to the scope of Shibboleth and allow similar projects to determine whether Shibboleth is an appropriate solution to their problem.

SUNIWE final report

The SUNIWE final report includes the full story of the process followed and decisions made in developing the system and managing the project. It is hoped the experience captured in this report will allow other projects with similar aims or similar make-up to benefit from the lessons learned in SUNIWE. The final report is availabe from the download area.

Development Process and Practices

This Web site and the final report include details of the process, practices and tools used in the development of the portal which will be useful to any projects embarking on Web application or portal-related development, especially for a JISC project.

Outcomes

Aims

The aims of the project were:

Table11

Aim	Achievement
To implement and evaluate the NIMLE student portal infrastructure as a way of managing the delivery of flexible lifelong learning	The NIIMLE student portal infrastructure was proved to work with minimum modification in the SURF and WETN environments. The only changes required were to NIIMLE configuration files and database views at the institutions.
To improve the learner experience by providing easy access to a personalised collection of essential information, applications and electronic resources.	The portal provided easy access to personal, course and transcript information and access to electronic resources and VLEs but as the portal could not be piloted, the improvements to the learner experience were not achieved. The JISC SURF WBL-Way project builds on the SUNIWE portal development work and has much the same aim so it is hoped that the intended improvement in the learner experience will eventually be realised.
To enable the learner to log in once to access all the information, applications and resources.	The portal was configured to work with the single sign-on system as part of the Shibboleth implementation but the Web services could not be secured using Shibboleth so this aim was not achieved.
To provide a foundation for tracking flexible student learning plans across institutions.	The service-based approach proved that it was possible to aggregate information to support student learning plans across institutions but the lack of a security solution, once again, meant this could not be demonstrated.
To enable learner interaction in business processes such as learner data reconciliation.	The project proved that it was more of an organisational than a technical challenge to provide personal information from multiple institutions to enable learner interaction in data reconciliation. Web services and channels were developed for this purpose but the lack of a pilot meant that the aim was not achieved.
To implement a service-oriented approach to integrate the enterprise applications in each consortium to provide dynamic data via web services.	The project developments have formed a first step towards a service-based approach to sharing information within the project partners. Barriers to further development are the lack of available electronic data and the lack of a security solution. Work to develop a security solution and promote a coherent approach for data storage and access across each consortium will continue. The data protection agreement will form the basis of a SURF-wide data protection agreement enabling all SURF members to participate in the service-based system as it is developed.
To improve enrolment operations between student record systems and VLEs via services.	This was not achieved.

Objectives

The objectives for the project were defined by the collection of envisaging scenarios and use cases which illustrated the functionality and services required from the point of view of the user.

Table12

Objective	Achievement
To enable display of current college course and university module titles and descriptions	This was achieved as part of the View Module List, Module Information and e-Resources channel.
To enable display of transcript / learner record information (course results, etc)	This was achieved as part of the View Module List, Module Information and e-Resources channel.
To enable display of personal information (name, address, telephone, etc)	This was achieved as part of the View and Change Personal Information channel.
To enable sending of learner requests to update personal information	This was achieved as part of the View and Change Personal Information channel.
To enable launching of course content in VLEs from links in the portal	This was achieved as part of the View Module List, Module Information and e-Resources channel.
To enable direct access to e-Resources from links in the portal	This was achieved as links to the MyAthens collection of Web-based resources.
To enable direct access to library catalogue system from the portal to view books on load and reserved	This could not be achieved because of technical limitations of the library catalogue.
To Automate enrolment operations between the student records system and VLEs via IMS Enterprise Web Services.	This was not achieved because it was the lowest priority objective and resources allocated to it were diverted to the Shibboleth work.
Implement Shibboleth to secure the portal, applications, e-resources and Web services to allow single sign-on access to all applications and resources accessed from the portal.	The portal was secured using Shibboleth but Shibboleth was ultimately found to be an incapable of supporting the SUNIWE portal/Web services environment so this objective was not achieved.

Outcomes

The SUNIWE project set out to create a portal to support learners and pilot and evaluate it. Ultimately, the project failed to pilot the portal but there are some valuable lessons to impart about the process of creating a portal-based system, the cultural, organisational and political issues involved in cross-institutional data sharing and the technical challenges of securing such a system.

The project development team have gained expertise in portal channel development, IMS Enterprise Web service development, Shibboleth, and Web application security. At SURF, this expertise is being utilised in the JISC SURF WBL-Way project which builds on the work of SUNIWE and the JISC SURF WBL project to implement a portal to support employers, mentors, tutors and learners involved in work-based learning in Foundation Degrees.

Project outcomes have been disseminated via several JISC events. The data protection agreement and the details of the development process have generated considerable interest in particular. It is hoped that the Shibboleth experiences will enable other projects to readily understand the scope of Shibboleth and determine the suitability for their project.

Methodology

The RUP methodology provided an essential framework for the development process but there were limitations to the approach as well as good points.

The iterative and incremental aspect of the RUP approach suited the R&D nature of SUNIWE but implementing iterations proved troublesome. It was difficult to get the development team together as frequently as was desired because of the time involved in travelling to and from and attending face to face meetings. This was a consequence of the project team being spread over three countries. Future projects would benefit from planning regular meetings at the start of the project to avoid delays trying to schedule meetings during the project. An alternative approach would be a focused effort where the consultant works continuously with the development team for the first few iterations to get the development process started.

RUP encouraged a focus on production of working software but it was easy to drift towards artefact creation, i.e. documenting the software instead of creating it. In future developments a greater focus on prototyping and less emphasis on documenting requirements would give better results. Use cases were essential to capture only features of value to the user but documenting the use cases could be done in an informal manner. Formal use case descriptions were overkill for the simple use cases in SUNIWE.

The SURF WBL-Way project is using an Agile approach for the creation of the WBL portal. Agile development has many of the good features of RUP but has even more emphasis on measuring progress in terms of working tested software instead of documentation.

Conclusions

The SUNIWE project was an ambitious attempt to implement a portal-based system across institutions before the environment was really ready for it. The portal and Web service components of the system were scoped and delivered successfully but the work required to implement a security infrastructure was underestimated. This was exacerbated by the loss of key project personnel which slowed development.

Overambitious

One of the risks identified at the start of the project was that it might be overambitious. The project team foresaw that the scope of what was technically possible would probably shrink in light of further analysis and that use cases would be prioritised in order to deliver maximum value. What was not foreseen was the scale of effort required to implement a security mechanism for the components in the system. Even without the problems encountered with the Shibboleth implementation, implementing Web services, single sign-on systems and authorisation systems in multiple institutions was an immense task technically, operationally and culturally.

SUNIWE was asking too much from existing technical and organisational systems in many respects. From a legal viewpoint, it was difficult to convey the nature of the portal and Web services to the legal experts because they had not encountered the technologies before. From a data point of view, there was no consistency between institutions in the range or availability of information stored. Too often, the project team found that systems that the portal was intended to interface with had no means of communicating with the portal. Culturally, there was significant resistance to sharing data in the way the SUNIWE portal intended. Creating the necessary organisational change was and is a slow process. The SUNIWE project has laid the ground work to inform future consortium processes and procedures that may need to be established within a similar context.

There was a vast amount to learn during the project. The development staff recruited at SURF had some Java knowledge but no experience of Web Services, XML, XSLT, Apache Axis, IMS Enterprise Services, SOAP, Shibboleth, SAML, Apache Tomcat or uPortal. Acquiring these skills obviously took time. Ideally development staff already possessing the necessary skills would have been recruited at the start of the project but the relatively low salary and short term nature of the project reduced the range of applicants. Additionally, the RUP approach was being implemented for the first time.

Loss of key personnel

Retention of project staff is critical for projects like SUNIWE. Early in the development process one of the two SURF developers left and mid way through the Construction Phase the project manager left. Given the timescales involved it was decided not to recruit replacements. The technical lead took on the project management responsibilities and the work of the departed developer was split between the technical lead and the remaining developer. The decision not to replace the departed staff was valid because previous experience suggested the chances of recruiting staff with the required technical skills within the time available was remote. Given the skills required it would take months before a new developer could make a useful contribution to the project. It was, therefore, vital to hold on to skilled staff. Loss of the staff was not a project killer but it slowed down development and contributed to the failure to identify a suitable security solution for the system.

Communication

Communication between the project team over such a geographically dispersed area was a challenge. A combination of traditional face to face and remote meetings was found to be the best approach.

Telephone conferencing and use of Skype and VNC to hold remote development sessions was useful to keep travel costs under control but face to face meetings were essential, especially during the requirements capture period. It was important to discuss the requirements as a team to ensure a shared understanding of the intended system was developed. Use cases were an aid to this by describing the use of the system but the scope and technical options could not reliably be conveyed remotely.

The wiki was useful as a persistent store for project documents and for capturing discussions. It was configured to email users when any topics were updated so that the project team did not have to keep checking the wiki for updates. A down side of using the wiki was that the structure of the wiki evolved as content was added. This required periodic tidying up of the content to prevent it becoming unwieldy which in turn created problems for users trying to find content in the new structure. Another barrier to effective use of the wiki was that users felt inhibited about editing content created by other users. This tended to stifle the intended wiki way of working where content evolves and updates create discussion.

Shibboleth scope

Shibboleth is suitable for federated access to online resources and applications, especially where the attributes used to determine access are not personalised. Shibboleth currently is not suitable for use with portals and Web services because there are no Shibboleth profiles to support Web services and the standard that Shibboleth is built on, SAML 2.0, cannot represent the delegation inherent in calls to Web services by the portal.

IMS ESWS development

Development of IMS Enterprise Web services involves several technologies. Developers need to be familiar with … and the IMS specifications themselves. The scale of effort required in producing even a modest collection of service operations is large. This can only be justified if the skills acquired are going to be reused in other developments or more services are to be produced in the future. Similarly, the business case for using Web services needs to be apparent. Services should be designed to be part of a service-oriented architecture where each provides a focused service suitable for reuse without change in several different contexts. Reuse of the services enables the benefit to outweigh the cost of development. If the “services” are just seen as plumbing between channels and databases then there is no real need for Web services.

The approach taken in the SUNIWE project was to implement the service operations at a low level, building XML documents from scratch. For future implementations, use of the CETIS IMS Enterprise SDK would speed up development.

IMS documentation was unwieldy. Of most use to the development team were the IMS Enterprise Web Services information models and the best practice guide. A read through the information models is recommended and for Java developers, javadoc-style API documentation would be useful as a quick reference whilst developing.

Mapping of data to IMS Enterprise objects is a decidedly non-trivial exercise. It tends to highlight inconsistencies in data storage between institutions and the Web service operations sometimes operate contrary to the business rules of the institutions. For the SUNIWE data:

1. extensions needed to be added for term-time address information.

2. the address format varied between institutions with one format having insufficient structure to the address to allow a consistent mapping to be achieved

3. the restriction of the readGroups to supplying group information for a collection of group IDs meant that the readMembershipsForPerson operation had to be extended to return group relationship information because the group relationships only existed within the context of an individual learner.

Implications

SURF WBL-Way

The JISC SURF WBL-Way project is building on the work of SUNIWE to produce a portal to support work-based learning in SURF Foundation Degrees. A similar approach to SUNIWE has been taken but there is no business case for Web services in the WBL-Way portal so portlets interact directly with the institutional databases.

Portlets conforming to the JSR-168 specification are being developed in the WBL-Way project rather than uPortal channels. This is because JSR-168 portlets are inherently more portable which will allow them to be run in the WBL-Way portal and in the Staffordshire University internal Oracle portal. uPortal has been rejected in favour of the LifeRay JSR-168 enterprise portal platform for the WBL-Way portal. LifeRay offers better JSR-168 support than the current version of uPortal and less effort is required to produce a clean look and feel with LifeRay.

Federated Identity

Given the emphasis placed by JISC on the service-based approach of the JISC e-Framework, there is a clear need for a Shibboleth-like solution to secure multi-tier systems like SUNIWE (i.e. portal and Web services). The SUNIWE development team have identified the Liberty Alliance Identity Web Services Framework (ID-WSF) as a possible solution. Further investigation and implementation along these lines would benefit any projects with an interest in cross-institutional Web services and portals.

Projects should be aware of the limitations of Shibboleth in cross-institutional environments where a mapping between institutions learner IDs is not present. A future Shibboleth release may include the ability to link accounts between multiple identity providers but currently, users are restricted to a single IdP.

SUNIWE Downloads

Documents

Final Report

The full story of the project.

suniwe-final-report-v1.doc (MS Word format)

suniwe-final-report-v1.odt (Open Document format)

Portal Data Protection Agreement

The pilot agreement covering the processing of data from College web services by the University in the portal.

suniwe-portal-dp-agreement-final.doc (MS Word format)

suniwe-portal-dp-agreement-final.odt (Open Document format)

Shibboleth Report

Shibboleth findings are detailed in the Shibboleth page of the Project information. To download as a report, click the PDF link on the Shibboleth page.

Code

uPortal Channels

uPortal with SUNIWE channels integrated into the source code.

suniwe-uportal-1.0-src.zip

suniwe-uportal-1.0-src.zip.sha1 (SHA1 checksum)

IMS Enterprise Services Web Services

SUNIWE Web service implementations.

suniwe-esws-1.0-src.zip

suniwe-esws-1.0-src.zip.sha1 (SHA1 checksum)

Checksums

Verify the integrity of the download files using the sha1sum utility.

Installation Instructions

Introduction

The purpose of this document is to give a brief list of tasks (mainly software installation) you need to perform to set up the SUNIWE uPortal / Web Services system and to suggest an order for the tasks as we had problems with the order of tasks in the documentation on the uPortal web site.

Installation

The graphic below illustrates the components involved in the UPortal and Web Services interactions. At Staffordshire University we put all the components for the Web Services and UPortal onto a single server. The following instructions assume you will be doing the same. If not, just install software according to the diagram.

Install Java JDK

Download JDK 5.0 from http://java.sun.com/j2se/1.5.0/download.jsp and install. Installation instructions are linked from the same page.

Set JAVA_HOME

Create an environment variable called JAVA_HOME and set it to the directory where you’ve installed the JDK.

      export JAVA_HOME=/usr/local/jdk-1.2.2
      

Install Apache Ant

Download Ant from http://ant.apache.org/ and install.

Manual with installation instructions: http://ant.apache.org/manual/index.html

Set ANT_HOME

Create an environment variable called ANT_HOME and set it to the directory where you’ve installed Ant.

Add the Ant bin directory to the PATH environment variable.

      export ANT_HOME=/usr/local/ant
    export PATH=${PATH}:${ANT_HOME}/bin
      

Install Apache Tomcat

Use version 5.5.9 if possible. At the time of writing, later versions have a UPortal login bug which will be fixed in uPortal 2.5.2.

Download Tomcat from http://tomcat.apache.org/ and install.

Installation instructions:

http://tomcat.apache.org/tomcat-5.5-doc/setup.html

Install Apache Axis

Download and install Axis (Java) from: http://ws.apache.org/axis/

Installation instructions:

http://ws.apache.org/axis/java/install.html

Install an SQL database

Use PostgreSQL or MySQL. We used PostgreSQL initially purely because we wanted to have a look at it, having already had some experience of MySQL. We later reverted to MySQL as more of the development team were familiar with it.

Install PostgreSQL

http://www.postgresql.org/

Installation instructions:

http://www.postgresql.org/docs/8.1/interactive/installation.html

Install PostgreSQL 8.1.x according to the installation instructions.

Install the PostgreSQL JDBC driver

1. Download an appropriate JDBC JAR file from http://jdbc.postgresql.org/download.html. The JDBC driver file will vary with the PostgreSQL and JDK versions. Look up which JDBC file corresponds to your combination of PostgreSQL and JDK. In our case this was postgresql-8.1dev-402.jdbc3.jar.

2. Create a directory /usr/local/java to hold the external java libraries required by UPortal.

3. Copy postgresql-8.1dev-402.jdbc3.jar to /usr/local/java.

4. Copy postgresql-8.1dev-402.jdbc3.jar to jakarta-tomcat-5.5.9/common/lib.

5. Create a database called uportal with UTF8 encoding using the PostgreSQL pgAdminIII interface or from the command line using psql.

SQL

The SQL to create the database is:

      
CREATE DATABASE uportal
    WITH ENCODING='UTF8'
    OWNER=postgres;
      

This assumes your superuser for PostgreSQL is a use called postgres.

Install UPortal

Installation instructions: http://www.uportal.org/administrators/install_v2.html

Download UPortal

http://www.uportal.org/download.html

Download the quick-start and the UPortal-only distributions. The UPortal-only distribution will be installed and the quick-start distribution will be used to supply the external libraries that UPortal requires.

Install External Dependency Libraries

Extract uPortal_rel-2-5-1.

Copy the contents of the lib directory to /usr/local/java (not the lib directory itself, just the jar files in it).

Edit uPortal_rel-2-5-1\build.properties

Make the following changes to the build.properties file:

      
lib.path=/usr/local/java
    server.home=/usr/local/tomcat (your tomcat directory)
    jdbcDriver.jar=${lib.path}/postgresql-8.1dev-402.jdbc3.jar (your JDBC file)
    #webapp.contextFile=uPortal.xml 
    webapp.contextFile=uPortal55.xml 
      

Edit uPortal_rel-2-5-1\ properties\Logger.properties

Make the portal log appear in the Tomcat logs directory:

      
log4j.appender.R.File= /usr/local/tomcat/logs/portal.log
      

Edit uPortal_rel-2-5-1\properties\rdbm.properties

      
jdbcDriver=org.postgresql.Driver
    jdbcUrl=jdbc:postgresql://localhost/uportal (substitute the name of your server and uportal database name)
    jdbcUser=postgres (your PostgreSQL user)
    jdbcPassword=pgsql (the PostgreSQL user’s password)
      

Edit C:\download\uPortal\uPortal_rel-2-5-1\properties\db\dbloader.xml

Add a type mapping for your JDBC driver. For our postgresql-8.1dev-402.jdbc3.jar it was the following:

      
<db-type-mapping>
    <db-name>PostgreSQL</db-name>
    <db-version>8.1.1</db-version>
    <driver-name>PostgreSQL Native Driver</driver-name>
    <driver-version>PostgreSQL 8.1devel JDBC3 with SSL (build 402)</driver-version> <type><generic>LONGVARCHAR</generic><local>TEXT</local></type> <type><generic>VARCHAR</generic><local>VARCHAR</local></type> <type><generic>LONGVARBINARY</generic><local>BYTEA<local></type> <type><generic>VARBINARY</generic><local>BYTEA</local></type> <type><generic>INTEGER</generic><local>integer</local></type>
    </db-type-mapping>
      

Build uportal

      
cd uPortal_rel-2-5-1
    ant initportal
      

If all goes well you should get the following message:

      
BUILD SUCCESSFUL
      

If not, deal with any errors and try again.

Stop and Start Tomcat

To get it to use the new jar library files.

Launch uPortal

http://<your server>:8080/uPortal (or whatever you’ve configured the URL to be).

You can login to uPortal using one of the following username/password combinations:

         demo/demo
       student/student
       staff/staff
       faculty/faculty
       developer/developer