e-Assessment system architecture

The evolution of the architecture of e-assessment systems is generally similar to evolution of e-learning platforms or learning management systems. Such systems usually provide a holistic environment for managing and delivering educational experiences including assessment of their outcomes.¹⁾ Examples of such systems are

• Moodle,
• Sakai Project,
• Whiteboard,
• Desire2Learn,
• Gradepoint,
• WebCT/BlackBoard.

Still, there are also a number of standalone e-assessment systems like

• TCExam,
• CASEC²⁾, or
• The Questionmark.

Evolution of the LMS architecture³⁾ and the evolution of the standalone e-assessment systems⁴⁾ can be described in three stages:

First generation of solutions (~ 1993-1999) for e-learning and e-assessment were monolithic black-box systems, usually oriented only on a specific course and offering very limited user-tracking. Examples of such systems were first versions of WebCT and Blackboard.⁵⁾

Second generation of solutions (~ 1999- ) for e-learning and e-assessment like Moodle or Sakai offer more modular architectural design enabling easier integration of new functionality. Standards like SCROM, IMS Content Packaging, and IMS Learning Design were developed to support the ability to exchange courses or parts of the courses. In this type of systems, content is usually being separated from tools enabling them to be used as platforms for creating different courses and assessments.⁶⁾

As a common conclusion of a number of recommended LMS frameworks (including JISC e-Learning Technical Framework (ELF), IMS Abstract Framework, and Open Knowledge Initiative), service-based architecture is expected to be the next architectural advance of e-learning and e-assessment systems.

Service-oriented computing (SOC) is

• “an application architecture within which all functions are defined as independent services with well-defined invokable interfaces, which can be called in defined sequences to form business processes.”⁷⁾

The services in an SOA have the following characteristics:⁸⁾

• they are autonomous, and external components do not know nor care how they perform their function,
• they have well defined invokable interfaces making it irrelevant weather they are local or remote.

Some of the reasons for adopting service-oriented architecture are⁹⁾:

• development of a “coherent diversity”¹⁰⁾
• easier collaboration between institutions,
• avoiding of limitations using single vendor solutions,
• easier connecting of components in custom and new ways,
• possibility of replacing of one service with another to offer same functionality in new ways.