Permalink
Switch branches/tags
Nothing to show
Find file Copy path
Fetching contributors…
Cannot retrieve contributors at this time
99 lines (79 sloc) 4.65 KB

Virtual Labs as a Service (VLaaS)

Introduction

This is the architecture document of the runtime environment in which the experiments are executed, henceforth called as Vlabs Experiment Runtime. The document also provides a blue print on how an experiment is designed to leverage this runtime environment.

Structure of an Experiment

An experiment is a set of learning objectives that are met by well-defined phases each consisting of steps or micro-activities composed in a meaningful manner.

Phase - a composition of activities that cognitively engage the learner. These activities are carried out in meaningful “steps.” Each phase is a self-contained capsule communicating or imparting a well-defined piece of knowledge or fact. Thus, at the end of each phase, the learner would have gained a little more insight into the subject matter.

Step/Steps - Simple acts that allow the user to move forward as filling up a text box with a number or text, selecting from a bunch of options (check boxes, radio buttons), tapping on an UI element, moving a bunch of objects around the screen, answering a descriptive question, writing a very short snippet of code, writing a free-form narrative, writing an equation, watching a video, listening to an audio clip, observing a simple animation on the screen, reading text narratives that bubble around animations, simply staring at a screen capture, and much more!

Vlabs Experiment Runtime

An Overview

edit the image

Slew of components

The runtime computational environment of the experiment is provided by the Vlabs Experiment Runtime which is a rich collection of active objects. Objects are loosely coupled; they communicate by passing messages to end points. The system is intended to be completely asynchronous and loosely-coupled. Some implementation technologies may, however, restrict the architecture in systematic ways. For example, a runtime may support only single-threaded event-driven style of communication.

There is a shared channel over which the Experiment, Phase, and Step objects interact with other objects in the Environment. A typical virtual environment contains objects that are: runtime state trackers of the experiment, loggers, analytics monitors, components that assist in grading and evaluating learner’s performance, reactive elements representing the UI and UX of the phases and steps in an experiment, and such.

The Vlabs Experiment Runtime that facilitates such a run time environment exposes REST API that is used by any other MOOC platform to build a MOOC.

Building the content

An Overview

edit the image

Components

Hosted Content
The resources could be either an NPTEL lecture hosted on youtube or a virtual lab hosted by VLEAD or any other resource residing on the internet.
Service Layer
This layer facilitates in finding a resource.
MOOC Plarform
Either Open edX or Google Course Builder is able to build a MOOC using the component platform described in the above section.

Incorporating Vlabs Experiment Runtime in Open edX

Strategy

Using the Vlabs Experiment Runtime allows a MOOC platform to persist the state of an experiment for a user, gather analytics etc. This is done by harnessing the Xblock architecture of Open edX.

The Vlabs Experiment Runtime sits inside am Xblock and the XBlock uses the REST API exposed by the Vlabs Experiment Runtime to capture the necesasry information. This information is fed back to the Open edX platform since the communication between an XBlock and the Open edX platform is seamless.

Google Course Builder can also use the same strategy since GCB supports XBlocks.

View

edit the image