Phase 2 Activities of Virtual Labs Project

From Virtual Labs Community
Jump to: navigation, search

The 2014 Virtual Labs Project Consortium meeting was held sometime back in New Delhi. The agenda of the meeting was to discuss the Virtual Lab project’s progress, its current status and to take a re-look at its objectives and also to finalize the deliverable for the upcoming Phase 2.

In this post we discuss in detail the Phase 2 objectives of the MHRD sponsored Virtual Labs Project. We describe the terms Central Platform Engineering and Integration, which is going to be the two major activities of Phase 2. Each of these two activities is a combination of a multitude of related activities.

Central Platform Engineering

The entire effort of building a common platform for the engineering and hosting the Virtual Labs, is being referred to as Central Platform Engineering. This involves the following activities:

  • Developing a lab as a web application
  • Standardising software life-cycle processes
  • cloud hosting, performance, analytics and security
  • Conversion to FOSS and standard platforms
  • Packaging and distribution.
  • APIs for Lab Services
  • Responsive UI
  • Lab Development Kit

(i) Developing A Lab As A Web Application:

Developing a lab as a web application implies implementing a lab using web 2.0 compliant technologies (JavaScript, HTML5, CSS, AJAX) so that the lab runs on all browsers with no any prerequisite software requirements. i.e the only requirement to run a lab would be a modern browser such as IE9 & above, Safari, Google Chrome, Opera or Mozilla Firefox.

The labs will interact with a client (browser) at the front end and with a set of common Virtual Lab Services or Application Programming Interfaces (APIs) at the back end. (the backend APIs will be developed by VLEAD, the Central Platform Engineering team of Virtual Labs project ,VLabs)

(ii) Standardizing Software Life-Cycle Processes:

To achieve standardization of the software life cycle processes, the software development process and the system development process will be standardised. In turn, the interfaces, the platform, and the back-end services will need to be standardised.

Software will be developed using standard coding practices, standard software frameworks and languages.The teams will be adopt a uniform way to version the lab’s code through Bitbucket or Github repositories.Testing will be done using standard testing frameworks.Code documentation and design and licensing terms will be standardised.

(iii) Lab Scripts For Cloud Hosting, Performance, Analytics and Security:

Labs will be hosted under a common cloud platform on Virtual Machines (VMs). An automated infrastructure for virtualization and lab life-cycle management will be developed.The lab deployment life-cycle process will be supported by a set of well defined scripts which include:

  • lab startup,
  • lab shutdown,
  • check-pointing,
  • backups,
  • restore operations.

Back-end systems will be developed for: performance monitoring, load-balancing, analytics and security.

(iv) Conversion To FOSS and Standard Platforms:

Currently, among the hosted labs which run on PCs and desktops many labs depend on proprietary platforms like Windows operating systems, proprietary Content Management Systems (CMS), proprietary softwares like MatLab, Adobe FLash (for animations and lab simulations), non-compliant web 2.0 softwares like Java SDK (for lab front end GUI) and so on. It should be noted that both Flash and Java SDK will not run on Aakash’s Android O.S. Thus all such labs which use non-standard/ proprietary softwares need to have major parts of their implementation rewritten to use free and open source software and standard platforms wherever possible. Please note that these softwares and platforms need to be web 2.0 compliant. Specifically, wherever possible Python, Scilab and SciPy APIs and bindings will need to be developed.

To make all the labs web 2.0 compliant and to make them available on Aakash tablet, the labs need to be rewritten/ ported/ developed using the web 2.0 compliant languages JavaScript, HTML5, CSS, AJAX. (The Central platform engineering will release alternative APIs based on FOSS for both front-end (Javascript) and back-end platforms wherever possible).

(v) APIs for Lab Services:


Phase 2 will provide a set of API’s for different lab related services viz:

  • Single Sign-On
  • Persistence
  • Analytics
  • Quiz
  • Security
  • Feedback Collection.
(The APIs will be developed in Python programming language. Team VLEAD will work on their design and implementation.)

(vi) Responsive UI:

jquery-responsiveLabs running on desktops and laptops will be made available on Aakash tablets. This requires a redesign of the User Interface of the labs such that they are responsive to different form factors (desktop screens, laptop screens, tablet screens etc) and end-user platforms (windows, linux, Mac, Android etc) . Be it any device, the labs should run on the device’s browser. For this to be realised, every lab will have to be a web 2.0 app. (Find a vlead post on Responsive web design @ A brief introduction to Responsive Web Design)

(vii) Lab development kit:

Lab development kit (LDK) is a set of templates and standard configuration files which will be used for lab integration, to ensure uniformity in the authoring platform. The central platform engineering team will release this LDK. In fact it will make multiple releases of the LDK (different versions) with each new version having more/ better features than its earlier version.

Examples of such artifacts include: HTML5-CSS-Javascript authoring templates, makefiles to drive the lab’s build and test processes, templates for reporting lab dependencies and all API releases.

(viii) Packaging and Distribution:

Basically for offline lab accessibility, labs will be distributed on media such as DVDs or pen drives. With this agenda, one will be able to use labs even in the absence of an internet connection. This scheme will aid schools with poor web connectivity to have local access to Virtual Labs. However it should be noted that space constraints will limit the number of labs or types of labs which can be packed on a DVD. Approximately twenty to twenty five labs can be made available on a DVD or a pen drive.

Integration: What is Integration (s/w Lab Integration)?

sw-labs-integrationCurrently, most labs use adhoc APIs and protocols to realise basic features such as single-sign-on, log in, analytics, back up, quizzing etc. As of now these and various other features of labs as well as the User Interfaces of labs have been devised and implemented in non-standard ways.

Lab Integration is a process by which a lab is systematically “re-engineered” (creating, developing,implementing, porting, modifying, enhancing, deploying) so that it can use a set of central services provided by the Central Platform Team (CET). The CET defines and provides the central service APIs to all teams.

In fact integration is a highly iterative process. It is a continuous process of writing, re-factoring, bug-fixing, testing, automating and improving the implementation of the labs to make the labs more robust with every iteration and have it adapt to new requirements, environments and platforms. (During Phase 2 each lab is expected to undergo at least three major cycles (and several minor cycles) of re-engineering.)

Integration Level (IL) and associated Quality Parameters for a lab:

To systematize the development of the labs and checkpoint their maturity, the Central Engineering Team has defined a set of Integration Levels and an associated set of Software Quality Parameters that a lab is expected to have.

The maturity of the integration of a lab will be determined by these set of Quality Parameters (QPs). As of now the Central Engineering Team has defined fifteen Integration Levels (0 to 14). These Integration Levels and their properties (quality parameters) are listed at this link: 15IntegrationLevelsTable.

(Click on figure to zoom in the table)


0: None
1: Versioned
2: Buildable
3: Testable
4: Hostable
5: Auto Hostable
6: UI Responsive
7: Documented
8: Single Sign On Ready
9: Persistence Ready
10: API Conformant
11: Agile
12: Modular
13: FOSS based
14: Security Hardened

The table is self-explanatory. It describes with a sentence each every Integration Level.

Phase 2: Organisation of the teams

Having understood the two main activities of Phase 2, we now depict the team structure and give an overview of their interactions.

(click on figure to zoom in the chart)

structural-organisation-of-teams-FINAL The chart depicts various teams/ individuals and their interactions with each other. You will find these individuals/ teams in the chart:

  • LD: denotes a Lab Developer/ Faculty Lab Developer (many per institute)
  • (IIC): denotes an Institute Integration Coordinator (one IIC per institute; a faculty)
  • IT: denotes Integration Team (IT) ( comprised of software developers)
  • CET: denotes Central Engineering Team/ Central Platform Engineering Team ( team VLEAD of IIIT-H)

We give more explanation for the terms FLD, IIC, IT, CET in the following section:

Lab Developer/ Faculty Lab Developer (FLD):

The content of a ‘Lab’ as well as its conceptualization is the responsibility of a faculty member who works for the project. Such a faculty member is also the the Subject Matter Expert (SME) for the lab. We call such a faculty “Faculty Lab Developer” (FLD) or simply “Lab Developer.”

In Phase 1, every FLD worked with a group of software developers/programmers to get a lab implemented. The responsibility of the FLD then was to envisage a ‘Lab’ and to conceptualise all its associated experiments. In Phase 2, the role of the FLD will be once again to conceptualize and prototype new Labs. However unlike Phase 1 where the labs and experiments got implemented using non-standard softwares and technologies, in Phase 2 their labs will be developed/ implemented using web 2.0 compliant standards and the agreed upon standards proposed by CET.

In Phase 2 every FLD is also expected to contribute towards improving the course content of their existing labs of Phase 1.

Integration Team (IT) :

The Integration Team is a team of software engineers responsible for the software development of labs. Every institution will have at least one such Integration Team which receives inputs (conceptualisation/ content/ design) about the to-be-developed labs from the Lab Developer faculty. The Integration Team will then develop and implement the lab, complying to web 2.0 standards.

In addition to integrating the labs to new platforms, they will also maintain and fix bugs in their experiments’ and labs’ code. Also on inputs from FLDs they will improvise the existing labs and/or add new features to the labs.

Institute Integration Coordinator (IIC):

Institute Integration Coordinator (IIC) is an institution faculty who will co-ordinate and supervise the per institute Integration Team. He will take part in all project meetings, and all central meetings and will effectively communicate the meetings’ outcome with the Integration Team.

An IIC’s experience in software and systems engineering will be a motivating factor for the Integration Team and will be crucial to the success of the integration effort.

Central Platform Engineering team: We, team VLEAD (Virtual Labs Engineering and Architecture Division) is the Central Platform Engineering Team/ the Central Engineering team (CET) of this Virtual Labs project. Our team consists of Network Engineers, Systems Engineers, Software Engineers and Web Designers.

The role of our team is to: (i) design and run the central data centre to host labs, and (ii) design new engineering platforms (UI, Akaash, API development, analytics, etc.) with which labs will be integrated.

Our responsibility therefore is to build a common platform for the engineering and host the labs developed by the Integration Teams.

We have proposed many engineering enhancements for the project. These software as well as systems enhancements will be carried out in Phase 2. They are:

  • Hosting the labs on cloud through a new proposed architecture termed One Virtual Machine Per Lab (OVPL) architecture. (for more info., refer to architecture-
  • Defining a set of Integration Levels and an associated set of Software Quality Parameters for a lab.
  • Standardising software and system development processes.
  • supporting the lab deployment life-cycle process with a set of well defined scripts.


The main objective of Phase 2 will be to support extensive and sustained usage of Virtual Labs and to provide high quality User Experience to all users of the lab. The platform engineering team VLEAD will have a crucial role in Phase 2. While Lab Integration and Scripts development will be the two major activities by VLEAD, developing new labs and modifying existing ones will be the major activity of all Integration Teams. The ITs will have to make the labs web 2.0 compliant so that the labs will run on all browsers without the need of any additional software. Faculty Lab Developers will be responsible to conceptualise new labs, improve lab contents and suggest modifications for the already hosted labs. All in all, all the teams including ourselves, team VLEAD, look forward for an exciting Phase 2, to work enthusiastically and to deliver the best to realise all the objectives of this MHRD sponsored Virtual Labs project.

This entry was posted in Uncategorized on May 6, 2014 by Jayashree Prasad.

Post navigation

Attention Lab developers: Developer Portal moved to Bitbucket!