Six MLEs: More Similar Than Different

The JISC-funded programme ‘Building Managed Learning Environments (MLEs) in HE’ [1] was of three years’ duration and concluded in July 2003. The aim of the programme was to explore developments that test, evaluate, and prove (or in some circumstances disprove) the generic deployment of technology in support of improved learning. The programme has developed good practice and shared ideas and experiences across FE and HE sectors. The specific objectives were to:

• demonstrate to the FE/HE community the potential of MLEs to support and enhance learning and teaching
• identify the generic and transferable aspect of the development projects
• demonstrate the benefit of a student-centred approach to service provision
• enrich the educational sector understanding of the cultural and organisation issues encountered when developing MLEs
• create technical and organisational guidelines to support the introduction of MLEs

The fourteen projects funded under the programme explored issues in four areas: the development of learner-centred MLEs; the development of institutional systems to support MLEs; the use of IMS specifications to develop MLEs; and strategies to achieve organisational change to support MLEs.

Six of the projects developed a variety of joined-up systems which, in general, linked together back-end administrative systems and presented a user interface through a Web front-end. In many cases, the system that was developed shared many of the characteristics of an institutional portal (also commonly known as Educational or Campus portals).

The JISC wished to review the systems that were developed and to consider their potential for future use in the wider FE and HE community; this article summarises the full report [2] that was produced as part of the review.

Aims

The aims of the report were to review products developed under the programme in the context of international technology developments in order to ascertain their potential future in the FE and HE community.

The objectives of the report were:

• to document the products that were developed by the projects, including how successfully they were achieving their objectives
• to make recommendations about the potential deployment of the products in the wider FE and HE sector or the integration of the products with current open source portal software/frameworks.

Analysis

Essentially all project products were underpinned by an architecture summarised in Figure 1:

Figure 1: A generic MLE Architecture?

Whilst common across the JISC ⁷⁄₉₉ projects that were reviewed, Figure 1 is not really a generic MLE Architecture; rather it is typical of any N-tier Web application and contains easily identifiable storage, logic and presentation layers on the server side of the application.

Harder to pigeon-hole was the ‘glue’ that supports interoperability between the various layers to occur - the term ‘middleware envelope’ is used here to bracket the integration magic that holds it all together. It was principally in the nature of their middleware envelope that projects differed from a technical standpoint - and this is also where the major innovations of this strand of the JISC ⁷⁄₉₉ programme can be identified.

Project overviews

The overall impression was that the six projects had more in common than they had differences. This commonality is conveyed in Figures 2-13; the architecture diagrams have been constructed using the same schema as that used in Figure 1.

De Montfort University-MLE

This project sought to integrate the student information system, the timetabling system, key documents (e.g. student handbook, regulations) and a news/messaging system. The product was primarily aimed at students of De Montfort University.

The project started development using Java and XML but switched to the uPortal [3] framework when Version 2 became available.

The potential for exploitation within other institutional contexts is very wide; the uPortal framework is agnostic and standards-based. The degree to which other systems can integrate is limited only by whether they offer adequate APIs and whether sufficient expertise is available to undertake the task (and maintain the service subsequently).

In general the architecture was flexible. However, the most innovative component of the product - the Broker between the student record system and the rest of the MLE - was also the most proprietary in terms of the toolkit (Visual Basic) and the platform (Windows) required. For such middleware to be adopted widely it needs to be recast in a more open, less platform-dependent alternative.

Figure 2: The DMU-MLE architecture

Figure 3: Screenshot of DMU-MLE - the Home Tab (before login)

The Generic Integrated Management Information System (GIMIS)

Integration of Writtle College’s four primary databases (finance, library, student records and timetabling) was the primary goal of this project. In addition, about twenty-five ancillary databases and discrete data sources used throughout the College were also integrated within the GIMIS core (e.g. locations database, FE Attendance). The product was aimed at both staff and students.

The architecture was flexible if working within a Cold Fusion [4] environment. The potential for exploitation within other institutional contexts is limited by this factor. The current prototype exposed an extraordinarily rich range of information drawn from many content sources within the institution and demonstrated what can be achieved with a high level of commitment to an information strategy.

Figure 4: The GIMIS architecture

Figure 5: Screenshot of GIMIS StaffNet - Admin Menu

Institutionally Secure Integrated Data Environment (INSIDE)

Perhaps the distinguishing feature of this project (a joint venture between St. Andrews and Durham Universities) within the JISC ⁷⁄₉₉ programme was its recognition that information maintained by departments (as opposed to the central administration), and the work involved in doing so, are important components in the overall institutional information base. This project sought to integrate departmental and centrally maintained systems using Java Server Pages [5]. In particular it focused on the exchange and management of data about students and modules (the ‘Module Management System’ - MMS). The product was mainly aimed at academic staff.

There are many components to the overall system; it was not clear to what extent they would be portable to other institutions, (though this was never an explicit goal of the project). The diversity of applications suggested that the system was indeed flexible within the local departmental context, provided in-house expertise was available to customise and develop the system.

Figure 6: The INSIDE architecture

Figure 7: Screenshot of INSIDE Staff Information Portal

MARTINI

This project sought to provide access to a wide range of systems: student records, unit enrolments and marks, course data, accommodation records, debtors and payments data, library borrower information, IT Service user data and timetabling information. It was primarily aimed at students of the University of East Anglia.

The project started development using WebObjects [6] but switched to the uPortal [3] framework in its final stages. The architecture was flexible; the IMS - Generator and XML - IMS conversion programs can work with either a WebObjects-based or uPortal-based system.

The use of XML to act as the interface with institutional data allows this middleware to sit between any data and any Web application that can import and read XML. If you know your institutional data structures and have the expertise to modify a few (less than five) XML documents, then the middleware can work in your context.

The potential for exploitation within other institutional contexts was very wide. It was not clear that deep integration of systems had yet been achieved in the current prototype; the passing of authentication credentials between component systems had not yet been implemented.

Figure 8: The MARTINI architecture

Figure 9: Screenshot of MARTINI - Student Details screen (after login)

Sunderland Managed Interactive Learning Environment (SMILE)

This project at Sunderland University attempted to integrate a virtual learning environment (WebCT) and student records system (SITS) within a portal. The product was aimed at both staff and students.

The project was distinctive in not having embraced Java as a development platform and instead adopting Zope 7. While this architecture is highly extensible (and portable), the project was able to reuse existing components (Plone [8] - itself built upon the Content Management Framework), to create their product more or less ‘out of the box’.

SMILE had not yet achieved deep integration of its SIS and VLE systems. It had achieved a degree of being joined-up by providing a ‘one-stop shop’ at which users can find collected in one place the links they need to other campuses. But there was no passing of authentication credentials; a separate login was required at the systems (e.g. E-mail, VLE) to which you were taken.

Figure 10: The SMILE architecture

Figure 11: Screenshot of SMILE - Academic Life Tab

Towards an Integrated Student Record (TISR)

The validating example of the TISR project was a model of the student record. The project showed how a student record can be embodied as an LDAP (Lightweight Directory Access Protocol) directory entry, and, using the TISR API, how the LDAP directory can be populated with student records, the individual components of which are derived from different sources.

TISR is described as a ‘lazy meta-directory’. Its role is to integrate the disparate data sources that typically make up the student record. Sample data connectors including JDBC (Java Database Connectivity ), LDAP, Enterprise JavaBeans (EJB) [9] and XML have been developed. In short TISR will integrate whatever you want. The product is aimed at systems administrators.

Aware of the international efforts to produce specifications for interoperability such as the IMS, EduPerson and LiPerson ‘student objects’, TISR focused on a pragmatic solution while such standards consolidate and manufacturers of both instructional and administrative software for the educational sector implement them.

The potential for exploitation within other institutional contexts is probably universal - what institution does not have more than one flavour of content repository? The TISR middleware is agnostic and standards-based.

Ravensbourne College has delivered an exemplar project which should inform the future development of any ‘project standards’ that the JISC may wish to consider in programmes involving technical development.

Figure 12: The TISR architecture

Figure 13: Screenshot from TISR demonstrator - Viewing search results

Summary of Recommendations

1. Assessment of middleware
   The principal recommendation from the review was the need for further assessment of middleware. There are many questions:
   • Which middleware is best?
   • Can one size fit all?
   • To what extent can functions within the middleware envelope be defined in common ways across institutions?
   • To what extent can functions to and from the middleware envelope be defined so as to keep them to a manageable number?
   • What are the key functions to concentrate on to fit the greatest number of institutional environments?
   • Is ‘a middleware toolkit’ potentially a UK contribution to global portal framework projects such as uPortal?
   • How might this link with projects such as ANGEL [10]?
   • Is this a task to be undertaken by CETIS [11]?
      
2. Development programme/project management (e.g. advice on software licensing and distribution, as well as technical evaluation, should be an expectation for any programme).
    
3. Observation and advice for other developers in the community (e.g. all projects used LDAP, build security in from the beginning rather than retrospectively, supply test data sets, stress test, the need to skill up in load-balancing).
    
4. Recommendations to JISC on areas that need further investigation (e.g. CMS, Web services, collaborative tools).

Acknowledgements

It has been a privilege (and a learning experience) to see behind the scenes of the projects, their code and their host institutions - their co-operation is gratefully acknowledged. My thanks in particular to Tish Roberts (JISC Programme Manager) for the support and patience she has shown.

References

1. The Building MLEs in Higher Education programme page is at: http://www.jisc.ac.uk/index.cfm?name=programme_mle_he
2. The Technical review of the systems developed by the JISC ‘Building MLEs in HE’ (⁷⁄₉₉) programme is at: http://www.jisc.ac.uk/index.cfm?name=799_techreview
3. The uPortal site is at: http://mis105.mis.udel.edu/ja-sig/uportal/index.html
4. The Cold Fusion MX site is at: http://www.macromedia.com/software/coldfusion/
5. The Java Server Pages site is at: http://java.sun.com/products/jsp/
6. The WebObjects site is at: http://www.apple.com/webobjects/
7. The Zope site is at: http://www.zope.org/
8. The Plone site is at: http://www.plone.org/
9. The Enterprise JavaBeans site is at: http://java.sun.com/products/ejb/
10. The ANGEL Project site is at: http://www.angel.ac.uk/index.html
11. The CETIS site is at: http://www.cetis.ac.uk

Author Details

Article Title: “Six MLEs: more similar than different”
Author: Paul Browning
Publication Date: 30-July-2003
Publication: Ariadne Issue36
Originating URL: http://www.ariadne.ac.uk/issue36/browning/