De Montfort University, MLE Architecture version 1.000
Managed Learning Environment - Architecture
(John Eyre - De Montfort University - Virtual Desk project - JCIEL 7/99)
The interest in "Joining-Up" electronic systems and services, for the benefit of end-users, has grown immensely over the past year. This is largely due to JISC funded research into Managed Learning Environments, and a growing need for UK Educational Institutions to become more efficient in their business data-handling.
So, what systems do we think need joining up, and how do we do it? And, how do we provide a user interface for students and staff to access it from on, and off-campus?
The current JCIEL 7/99 programme splits projects into those focused on Joining-Up systems for the Universities Business requirements and those looking at the issues for the Learning requirements. Actually, there will need to be a lot of overlap. In order to identify an individual student and provide a personalised support environment, we need to be able to talk to the Student Record System (an Administrative Tool). There are other administrative tools that we need to be able to support, for example, the Timetable system, validated Module database and the Finance system.
On the educational support side, we have to find out what academics are doing and how they are doing it. Most have spent years resisting the pressure to redesign all their materials to work well on the Web. Having said this, a growing number are placing existing materials on to web sites, for students to access at their own convenience. To help academics manage their new electronic teaching materials, and deliver them to students in an informing way, a number of software applications have emerged. These now tend to be referred to as Virtual Learning Environments. So, we have a wide variety of materials placed on uncontrolled web sites, and a growing use of VLE applications, that try to help with managing these materials but don't tend to provide much in the way of structured pedagogy.
Then there is the Library. These operate like complete businesses in their own right. They manage their own user accounts, stock management, charging mechanisms, licensing and access to remote services, as well as providing face-to-face and on-line support for learning. They also need to interact with the rest of the universities administrative systems, but don't usually have direct, on-line, interactive connections to the SRS.
Do we also want to provide some support for finding other relevant resources, perhaps on the web, hidden in remote databases, descriptions of things that are not themselves digital.
What about the part of student life that most students actually enjoy, their social life. We need to look at how we can enhance this part of their university experience by providing services that are not easy for them to do any other way, for example, discovering other students that have similar social interests.
The following figure shows how we see the various parts of the MLE environment fitting together.
The user interface for an MLE is usually (but not necessarily) a Web Browser. This means that the developer doesn't have to worry about distributing and updating a user client application. But it does come with some drawbacks, due to the fact that there are so many browsers to choose from, and they don't all support the same features, or respond in a consistent way.
The MLE server needs to look after users on an individual basis, so it requires some means of recording who they are and what they are doing. One way would be to register all possible users into a local database, but this is one of the existing problems that the MLE is trying to overcome, the fact that each new system duplicates the student registration process and is therefore out of sync with the main university SRS.
In our model, we only worry about "actual" users. Out of the 20-30,000 potential student users, it is likely that take-up will be gradual, with the service being advertised to smaller groups, such as evaluation groups or new first years. As we are able to validate a users ID and password against an existing system (the student email), we add each new student to our user database when they first use the system. This keeps information about when they last logged in and their user preferences. It could easily maintain a complete record of how they use the system, which could be useful for evaluating the utility of the system, or to look at study patterns as a research area.
The student email system doesn't know very much about the user. As we want to tailor the interface to meet individual needs, we need to be able to query the Student Record System (QLS) to find out what faculty, course and modules they are signed up to. The SRS also has their personal contact details, addresses, fee scheme, assessment progress etc. the only access to this system is via a dedicated client interface (MS Windows only), from PCs connected to the Administrative network, isolated from the Internet. So, we needed a secure way through the firewall to be able to query this database, without any chance that some hacker could send "update" instructions to it. We will look at this in more detail later in this document.
We need access to several other databases in order to build a picture of the students' requirements. These include the Timetable system, Module database and Finance system. These are all in a similar status to the SRS and could use the same mechanism, even though the DBMS and the data table structures are different. Other systems that we need access to include the Library, which provides access to a host of local and remote learning resources and holds financial status, which could stop a student from graduating. The Virtual Learning Environment is the next major learning support tool that we need to be able to interact with.
The Library and the VLE are part of a group of resources that already have existing student interfaces (in the case of the Library, very secure, well structured and self-contained). This gives us a challenge. To identify features in the MLE that don't just duplicate what already exists in other places, such as the Library, but do something for the student, in context, that isn't easy to do without an MLE. This might be, to provide links directly from a module view on the MLE into the relevant past exam papers for that module, or to book references from the reading list. It could present the users status in the Library (e.g. overdue books, fines etc), or give access to personal messages from the Library system. For the VLE, it could provide useful "overview" status information that goes across modules (VLE systems are usually module focused, with academics setting up support systems for their own modules. Students work across multiple modules). The MLE could provide a control service for passing information between the SRS and VLE, for example, to set up user accounts and feedback assessment results.
Another group of resources that need to be considered is those remote electronic services that can be found on the Internet. Many JISC projects have turned into services and each has their own interface and set of interactions with the user. Many have registration and access authentication, licensing and some measure of tracking usage. There are some common ways of working, such as ATHENS authentication, but how to support all this in a local MLE is not straightforward. The DNER ANGEL project is considering this kind of issue in more depth, so I include an explanation of how this work is going, later in this document.
The next figure shows the two main systems that the MLE needs to work with in supporting the student users administrative and subject learning experience. Each can be thought of as being a software application with a number of interfaces and its own user database. The SRS interacts with the UCAS system and the local academic and administrative staff. The VLE also has an administration side, creating and managing academic authors and student users and their relationship with individual modules. An institution could easily have more than one VLE and potentially multiple SRS (especially a multi-campus or multi-institutional partnership).
The basic user data held in both the SRS and VLE should match, Names, UserIDs, contact details etc. The usual way of getting this information from the authorised source (SRS) to the VLE could be any of the following:
· Printout a list and re-key into VLE
· Export a file of data in a format that the VLE can read, write an input routine to load it in.
· Use an Application Programmers Interface from one of the two systems, in the other.
· Both system can agree to use the same "standard" to directly exchange agreed data.
What would be nice for the institution would be if the MLE could control the data exchange between the SRS and the VLE using an agreed standard. This would allow either the SRS or the VLE to be replaced by another product at a later date, and allow for additional systems to be brought into the design, under the same controlling MLE. See the next figure.
As we have suggested that most systems are basically the same structure - a database, some programmed functions and one or more user interfaces, we can generalise a model such as the following diagram. It identifies a number of the main systems that exist in education and shows how they could be "joined-up". One method would be to use the MLE as a control system. In our MLE "student-focused" system, we are trying to present a "view" of a students distributed data. As the MLE is a system in its own right, it manages the data it needs to interact with the user, but it doesn't aim to duplicate any information that the other systems maintain. It doesn't "need" to move data between the SRS and VLE, but it could do, if this was a perceived benefit of having an MLE available.
A better way for the institution to organise its data would be to provide a "centralised" directory service. This takes a "view" of all the data that the university maintains. It can enforce ownership of individual data elements, e.g. "family name", "email address", and only allow one system to modify this data, while allowing others to "read" it.
In this model, the MLE would just be another data owner and user, and would be considered along with the other services when building the full directory list. This is a big task and could be addressed bit at a time.
Another way of dealing with all the variety of systems, databases, protocols and access management, would be to create a service tool that focused on this task. The ANGEL project is developing a "middleware" service, which aims to address these issues.
The dotted line indicates the ANGEL "black-box". It has a number of connectors that listen for messages coming in using particular communications protocols, such as HTTP and Z39.50. The XRR format is the generic ANGEL protocol (as used internally, therefore would not need conversion and hence work faster). IMS is an developing standard (currently a specification for defining data models for Instructional Management).
Incoming messages could be search queries, containing their required target system. However, they could simply be messages that carried some information about a users group memberships and the kind of information they are currently looking for. ANGEL could then use its user manager and resource manager to identify appropriate target systems for this users interests. The requesting system would not need to talk all the protocols that targets systems might use, or even know what target systems existed or how to connect to them.
Queries would then be posted to one or more target systems via the appropriate ANGEL clients. Returns would be managed and passed back to the requesting system in a format they could understand.
New servers and clients can be added to ANGEL as required, and new targets can be described in the resource manager. Any user access requirements and security issues can also be handled by ANGEL on behalf of the current user.
The next figure shows how the generalised model has been implemented in the DMU MLE
system.
MLE Integration with DMU Administrative Systems.
The diagram below illustrates how the integration with the Student Record System (QLS) has been achieved. The MLE queries QLS in order to retrieve student biographical data together with information relating to the user’s programme of study, selected modules, faculty, fees and assessments.
1. User requests a page in the MLE that contains QLS data.
2. A data request message in XML format is sent to a server on the secure DMU admin network where it is received by a Visual Basic client database broker. This message conforms to a bespoke MLE-QLS protocol and contains three parameters: the name of the database to be queried (i.e. QLS), the unique identifier of the student whose data is required and the number of a pre-defined SQL query which is to be run against the specified system. The structure and content of the message is validated against an external XSD schema file, which enforces the MLE-QLS protocol. All communications between the MLE web server and the admin-networked server on which the database broker is hosted are carried out over an encrypted SSL connection using point-to-point firewall rules, (we are still investigating SSL tools that would be usable in a production system).