Virtual Labs as a Service (VLaaS)
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
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.
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
- 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.
Vlabs Experiment Runtime in Open edX
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.
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.