Skip to content

good practice and innovation
about us infoKits Tools & Techniques Publications Events
You are here: Home » infoKits » Creating an MLE » technology-options » MLE architectures

5.2. MLE Architectures

Creating an MLE requires the development of an integrated technology system. This means that early decisions may have a profound impact on later developments. The hardware platform, operating systems, database technologies and middleware will all impact on later systems. Here we look at the way in which architectures are developing, why it is important for you to develop an overarching architecture for the MLE, and why it is necessary to look not just at the applications that are currently being purchased, but at the technology requirement of the whole MLE.

Architectures for major systems have changed enormously over the years. Originally systems were built as single large entities with each system doing everything. By the 1980s we saw a separation into layers with some of the functionality being handled by the operating system, some by generic 'middleware' and others by applications.

Click on image to view separately along with a description

By 2000 we have seen the application layer divided into two parts, the user agent and the application services. This has lead to a greater use of re-usable components such as content management and search services.

Click on image to view separately along with a description

The Open Knowledge Initiative (OKI) uses a model very similar to this:

Click on image to view separately along with a description

and this is being taken even further now, with the move to web services which makes the components even smaller.

Web services definitions

Web services
Web services are a standardised way of integrating Web-based applications using the XML, SOAP, WSDL and UDDI open standards over an Internet protocol backbone. XML is used to tag the data, SOAP is used to transfer the data, WSDL is used for describing the services available and UDDI is used for listing what services are available. Used primarily as a means for businesses to communicate with each other and with clients, Web services allow organisations to communicate data without intimate knowledge of each other's IT systems.
SOAP
Simple Object Access Protocol - A messaging protocol, based on XML, used to send low level messages between computer systems.
UDDI
Short for Universal Description, Discovery and Integration. A Web-based distributed directory that enables businesses to list themselves on the Internet and to discover each other.
WSDL
Web Services Description Language, an XML-formatted language used to describe a Web service's capabilities as collections of communication endpoints capable of exchanging messages. WSDL is an integral part of UDDI.
XML
eXtensible Markup Language is a cut-down version of Standard Generalised Markup Language (SGML), designed especially for Web documents. It allows designers to create their own customized tags, enabling the definition, transmission, validation, and interpretation of data between applications and between organizations.

5.2.1. MLE Architecture specifics

Most architectures will start by defining some form of directory, probably using the Lightweight Directory Access Protocol (LDAP) so that all the systems are sharing core information about the individuals (staff and students) and some information about them. All systems use this type of information and therefore there is considerable benefit to be had from using it as a core part of the architecture.

Compatibility with existing systems

Perhaps the next critical decision is the standards to be used. Open standards are discussed separately in the MLE Design section.

Proprietary solutions have some advantages, notably that they do usually work as the developers only have to meet their own needs, not the generic needs of all which allows them to optimise the system and fully test it. However it does mean that it will only work with other systems that have implemented the same solution.

This can also affect the order in which systems are implemented. Thus, although there is likely to be a logical order for changing the systems from a functional point of view, perhaps because some systems no longer offer all the functionality that is currently required.

However, when building an MLE it is also important to look at which systems are to be integrated and the nature of that integration. Some systems are much more open to integration and the development of a web interface than others. It is thus possible that some systems may have to be replaced earlier for technical reasons than might otherwise be the case.

Data integrity

Using multiple systems leads to the danger of multiple copies of data and of these getting out of line, this is one of the reasons for building an architecture around a directory system. There is then a single authoritative instance of any information, and when it is changed the updated version is available to all systems. Indeed to some people this is one of the key advantages of moving to MLEs - data need only be collected once and it is correct (or wrong of course) everywhere.

Creating the architecture needs to take into account the nature of the processes (automatic) and procedures (manual) that will be used to support data integrity. This is in part an architectural question but goes much wider and needs to be considered in during implementation and embedding of the systems. However, the architecture does need to be able to support whatever methods are going to be used.

Follow this link for key resources for this section (these open in a new window)


Bookmark and Share
If you can read this text, it means you are not experiencing the Plone design at its best. Plone makes heavy use of CSS, which means it is accessible to any internet browser, but the design needs a standards-compliant browser to look like we intended it. Just so you know ;)