An Integrated Example of Laboratories as a Service into Learning Management Systems

Remote practical experiences are nowadays essential in the context of distance education, because students cannot use face-to-face traditional laboratories. These remote laboratories can be used by faculty within virtual classrooms, so that students can carry out their on-line experiments in a ubiquitous way – from anywhere and at any time. But these activities cannot be isolated from the learning process of students. Therefore, the services provided by a remote laboratory must be integrated into the institutional Learning Management System (LMS), in order to be employed during the whole learning process. In this work, a fully-functional example of the integration of service-oriented remote laboratories into a LMS is presented, where the Moodle platform has been chosen as a representative LMS.


INTRODUCTION
In recent years, laboratory experiences have been considered as core components of technical degree programs -particularly, in Engineering and applied sciences. Unfortunately, laboratories' physical equipment is usually expensive in terms of acquisition cost and maintenance. Therefore, laboratories can represent a very representative part of University budgets and capital investment and, as a consequence, they represent a very a valuable resource. In addition to this, there is not resource sharing among institutions, due to a constrained access to physical laboratories, which is misaligned with the increasingly complex lifestyles of students and their demands on their time. These aspects put further pressure on Universities with regard to the delivery of an effective practical laboratory education.
On the other hand, from the point of view of distance Universities, there is a need to remote access to teaching resources. This fact highlights the need to provide laboratories, which can be employed remotely. In the literature, a large number of remote laboratories are presented, which are deployed in an isolated way, or by using a middleware interface. For both cases, the laboratory is integrated into a learning process. This is achieved through the addition of pedagogical elements into the client application of the remote laboratory or the integration of remote laboratories into the existing learning contexts. In the case that remote laboratories could be seen as a set of services, remote laboratories would increase their reusability and versatility.
In our particular case, the Spanish University for Distance Education (UNED, Universidad Nacional de Educación a Distancia), is the largest university in Spain, with more than 200,000 students. This University provides university training to students who lack the time or resources needed to attend on-campus classes. This is necessary for students who have tight timetables because of other commitments. Furthermore, UNED provides university training to convicts and disabled people, whose attendance at on-campus classes is not feasible. UNED provides such students with the platform to receive education at home without the time-consuming and sometimes money-consuming effort requested by on-campus universities. The evolution of education towards technology requires significant improvements within the learning process.
An approach for the creation of adaptive Laboratories as a Service (LaaS) is described in this work, a service-based utility that allows the reuse of remote laboratories in order to be consumed from third parties in a versatile and customizable way. These LaaS are based on the deconstruction concept [1] of remote laboratories into smaller "chunks", which can be combined in order to allow the flexible creation of customizable remote experiments. Thanks to this, laboratory users can create scenarios that fit into their needs, and avoid unnecessary functionalities that may jeopardize the acquisition of knowledge by students. This way, the same laboratory can be adapted to the needs of its users, increasing its versatility. As an example, remote laboratories as a set of services for renewable energies have been developed [2].
This work proposes the integration of LaaS into Learning Management Systems (LMSs). Every remote laboratory must provide authentication, authorization, and scheduling services to ensure exclusive access (typically through a queue or calendar-based booking), and user tracking services. These features will be common to most remote laboratories. Therefore, the implementations of these services by third parties, such as a LMS, can be integrated into the experiment. In addition, a LMS environment provides students with all the theoretical documentation, protocol tasks, and complementary information they may need, as well as communication channels between students and instructors (e-learning resources). It is also clear that most of the LMSs provide features, such as PAPER AN INTEGRATED EXAMPLE OF LABORATORIES AS A SERVICE INTO LEARNING MANAGEMENT SYSTEMS authentication and authorization. These features should be increased with scheduling capabilities. The Moodle platform [3] has been employed for achieving our purpose of directly integrating LaaS into LMSs. Moodle includes the possibility of using plugins, which are a flexible way of extending its features. There are hundreds of plugins for Moodle, extending its core functionality. In our particular case, a new activity module [24] has been created in order to be used for integrating adaptive remote laboratories. This paper is organized as follows. In Section II, the state of the art and motivation of this work are described. Section III presents the concept of LaaS, and its importance for our purposes. The integration of LaaS into the Moodle LMS is presented in Section IV. Finally, some conclusions and future work are included in Section V.

II. STATE OF THE ART
The LMS is a software application that facilitates the provision of theoretical online classrooms by means of integrated features and tools, such as administrative tools, synchronous and asynchronous communication tools, assessment and tracking tools, multimedia sharing tools, and standard compatibility. Our motivation is to make use of all the services provided by open-source LMSs, such as Moodle [3] or Sakai [4], and apply them in the remote practical laboratory sessions. Thus, several initiatives have been launched aimed at integrating remote laboratories into LMSs. This section strives at summarizing some of these projects, including their advantages and disadvantages. In order to solve the problem of providing practical skills to students, despite the lack of equipment and funds at educational institutions, technology-enhanced learning based on the sharing of equipment between institutions is suggested for wide-scale implementation across countries. This was a breeding ground for new researchers to establish a seamless, interoperable, and shareable integrated architecture that encompasses remote laboratories from several Universities, in order to span their dissemination and inter-institutional operation. Under this concept a new type of middleware appears, called Remote Laboratory Management System (RLMS), such as MIT iLabs [5,6], WebLab-Deusto [7], Labshare Sahara [8]), RELATED [9], or the proposed in [10]. These RLMSs provide development toolkits to incorporate remote laboratories, as well as management tools and common services.
A more detailed review on the integration and interoperability of remote laboratories can nowadays be found in [11] and [12]. A different approach for the integration of remote laboratories into a learning process is based on the extension of well-known learning contents standards, such as SCORM and IMS. In this direction, the Library of Labs (LiLa) project [13] appears, which has created a repository portal that includes online laboratories from different Universities wrapped into SCORM packages. Additionally, the Open Collaborative Environment for the Leverage of Online Instrumentation (OCELOT) [14] project is an open-source, collaborative online framework and middleware where remote laboratories are packaged into IMS Content Packages. The main drawbacks of these approaches are that the SCORM and IMS content packages are standards oriented to package static contents. These should extend the existing standards to include the needed features for the management of remote laboratories. Therefore, the LMS must be aware of the standard extension and offer support.
Several LMSs offer their own extension mechanism. So, a different option to integrate remote laboratories into LMSs is the creation of an extension of the corresponding LMS. As an example, the MARVEL project [15], [16] has created a booking module for the most popular open source LMS, Moodle, which is based on hour slots. Although it had been modified to facilitate the integration of remote laboratories, this approach is oriented to a fixed scheduling schema and remote laboratories only built with LabVIEW control panels. As the session slot is fixed, this session duration cannot adapt to the students' needs. Since our proposal uses the LaaS approximation, this is not a disadvantage. Each service of our remote laboratories can be used into the LMS in an independent way, allowing customization. For instance, the interface of the laboratory can be presented with the basic services or with a more complex interfaces and functionality. That fact depends on the faculty decision by taking into account the level or nedds of his/her students.
Another Moodle integration approach can be found in [17], where a Moodle and a dotLRN plugins are proposed to integrate remote laboratories into a LMS. Authors present a very useful extension for the WebLab Deusto platform for the integration of remote laboratories into Moodle. Therefore, the scheduling schema is delegated to the underline middleware. The integration of a remote laboratory in this case is more complex: first, it has to be integrated into WebLab Deusto, and the corresponding plugin must be installed. Our proposal integrates directly remote laboratories into the LMS with the ability of customization.
On the other hand, EJSapp [18,19] proposes a set of Moodle plugins for the integration of virtual and remote laboratories, a scheduling schema, collaborative tools for shared sessions, and a manager for the resulting experiment are offered. The remote laboratories are represented by EJS applets, by depending on the client side. The proposed plugin in this work is not dependent of the browser, versions, and so on, since it is programmed in the server side. Additionally, the interfaces of our proposal are responsive (it presents an automatic resize and resolution for any device).
Another drawback of EJSapp approach is that concurrent activities can be developed on the same laboratory or equipment. To solve this situation, a middleware is needed. Again, our proposal does not need a middleware to do this.
Education has also evolved towards new scenarios, called Massive Open Online Laboratories [20,21]. Therefore, scheduling and availability properties for remote laboratories have increased their relevance. Other trends in remote laboratories are describe at [22].
It is also remarkable that most of the integration proposals do not pay much attention to the monitoring of students during the performance of the experiments. This is also a key element in the development of our proposal of integration.

III. LABORATORIES AS A SERVICE (LAAS) PROPOSAL
The lack of common standards in laboratory definition and connectivity specifications is a major impediment to the adoption and wide-scale networking of remote labora-PAPER AN INTEGRATED EXAMPLE OF LABORATORIES AS A SERVICE INTO LEARNING MANAGEMENT SYSTEMS tories for teaching and training purposes. It is clear that a standardized access interface can help in this direction. To overcome this problem, the creation of adaptive Laboratories as a Service (LaaS) is employed in this work.
The LaaS customization have several benefits. LaaS allow the versatile creation of on-demand scenarios by using the laboratory services that are needed for each specific experiment, thus avoiding the use of all the services that are not needed. This way, students will be away from the unnecessary complexity which may jeopardize their learning process. The laboratories may be used for experiments in a basic course, for instance, consisting of only a webcam and statistics graph for students. For an advanced level course, experiments can also be created by using a wider set of services, which allow students to have more influence and control over the experiments and their results. Thanks to this, the same laboratory can be used for a wide set of scenarios, only varying the available services in each case, which increases their levels of use. This also affects the revenue of the institution, because of the fact laboratories can be used for more purposes with the same cost.
In particular, LaaS is a service-based approach that allows the use of remote laboratories to be consumed from third parties in a versatile and customizable way. These LaaS are based on the deconstruction [1] of remote laboratories into smaller "chunks", which can be combined in order to allow the flexible creation of customizable remote experiments. The development of LaaS has among others the following benefits. LaaS allow the versatile creation of on-demand experiments. This can be achieved by means of using the laboratory services that are needed for each specific experiment, avoiding the need to use all the unneeded services, and thus keeping students away from the unnecessary complexity which may jeopardize their learning process. Thanks to this, the same laboratory can be used for a wide set of experiments/scenarios (just varying the services that are visible in each case), which increases their levels of use. This also affects the revenue of the institution, since they can be used for more purposes at virtually the same cost.
Another main advantage of this approach is modularity. Each laboratory is composed by a set of HTTP RESTful web services as interfaces. Those web services must be provided or created by the laboratory owner. The internal details of these web services are hidden for the final service consumer. In our particular case, remote laboratories must first be deconstructed. That means their functionality must be provided in an independent for each service, similarly to [1]. Second, a container must be chosen in order to hold the clients and create customizable learning/teaching scenarios. Clients consuming the laboratories services must also be created and included in the container. A basic client can be a HTML page that accesses the services by means of AJAX technology.
More details about the deconstruction of remote laboratories can be found in [2]. The creation of LaaS involves three steps. First, deconstruction of laboratories, which refers to the way how functionalities of laboratories can be split in order to allow lecturer to rearrange them to compose customized experiments. These web services are the responsible for starting and ending the experiments, receive instructions for the equipment, sending the gathered data, temporarily store the generated data, or export the data to be processed by the student in CSV format. De-pending on the equipment interface different technologies can be used to implement them: Labview, Python, Java, etc. Second, selection of the container used to host these applications and publish them for its use. And third, creation of clients, which refers to the development of applications that use the aforementioned capabilities to allow the construction of customized scenarios.
Particularly, authors focus on adapting a solar and an Aeolian remote laboratory, to work as adaptive LaaS. These laboratories help students to understand how sun and wind is directly related to the generation of energy [23]. LaaS will help lecturers to prepare suitable evaluation on-line experiments/scenarios Next section introduces the integration of our LaaS into the Moodle LMS to be employed during the students' learning process.

IV. EXAMPLE OF INTEGRATED LAAS INTO LMSS
Every remote laboratory should manage a subset of the following features: authentication, authorization, scheduling users to ensure exclusive accesses, user tracking, and administration tools. These features are common to most remote laboratories, and they are actually independent of the particular remote laboratory objectives.
On the other hand, The LMS environment provides students with all the theoretical documentation, protocol tasks, and complementary information they may need, as well as communication channels between students and instructors. The LMSs also provides features, such as authentication or authorization, but they have to be extended with features, as it is done in this work. The Moodle platform [3] has been chosen for our purposes.
Before describing the development of our extension of Moodle for the integration of LaaS, some concepts have to be clarified. A laboratory is an equipment deployed in an institution that it is accessible by means of RESTful web services. An experiment involves a set of operations with a particular laboratory, and an activity is an instance of an experiment in a course.
In our particular case, a new activity module has been created, which provides the following functionality: • A Moodle administrator must be able to install the plugin, and register laboratories and available experiments. • Instructors can create an activity, an instance of a particular experiment for their students, configure the activity parameters, and monitor the performance of the students during the activity. The plugin must avoid them to configure or implement anything. • A student can book a free session for this activity, do the activity, and download the results of the activity. The platform stores all the followed steps during the execution of this instance of experiment.
Activity modules reside in the "/mod" directory of the Moodle installation. Each module is in a separate subdirectory and consists of a number of "mandatory" files and other support files, such as multimedia files or auxiliary functions.
The general functionality of the developed plugin for Moodle, the registration of laboratories and experiments, the creation of an experiment, and the execution of a session will be detailed below.

A. Laboratories/experiments
After the installation of the plugin into Moodle, an administrator can include laboratories and their corresponding experiments from the administration page. As shown in Figure 1, there are two tables; one of them contains the data correlated to the laboratories, and the second one reports about the registered experiments. On top of the administration page, the following three buttons can be found: • "Add a laboratory". It opens a form in order to register a new laboratory into Moodle. This is the first step when adding a new experiment to the platform. • "Add an experiment". It also opens a form in order to include a new experiment to a previously registered laboratory. • "Sessions". It shows a table where administrators can observe all the current sessions. This helps administrators to monitor the plugin activity in Moodle (see Figure 2). The session has the following status: pending, running, finished, time out, or unused. It is also useful if an activity is deleted from the course. Therefore, administrators can recover the data of the sessions for faculty. Concurrency is controlled by the plugin, there is only an active session per experiment, and a laboratory is only concurrent if several experiments can physically take place in it at the same time or if there are replicated laboratories.
Under our framework each experiment is composed by the following parameters: • A reference to the laboratory, where the experiment takes place. • A website that can include the laboratory client. This website can include any web technology object, such as a Silverlight application, a LabVIEW control panel, a Java applet, or a HTML5 compliant website. • Optionally, the experiment can provide a status service that reports about errors on the equipment or if there is a running session in experiment. This feature is fundamental when the equipment is shared among more than one institution or different Moodle platforms. • Optionally, an experiment can have a web service for retrieving a file with the experiment results.

B. Customization of experiments
Instructors are allowed to add new activities based on defined experiments or resources into Moodle courses. In order to create an experiment activity, faculty must turn on edition and add a new activity by using a "Laboratory" template (see Figure 3); thus, the experiment will be based on the selected laboratory. Then, the particular experiment activity form is shown to complete the creation of the activity. Apart from a name and description, faculty must choose one of the registered experiments from the list. The experiment activity has a period of time. The maximum duration is a month. This way, the condition that another faculty can use the experiment activity in fair conditions is guaranteed.
Experiment activities cannot be added alone in the course. It is relevant that faculty offers other tools in conjunction with the experiment activities, such as a PDF with technical details about the remote laboratory, a video that explains the experiment interface, other activities related to the experiment, and an assignment task, in order to deliver a report about the experiment. This way the learning process can be meaningful for the students. Another key element is a forum, so that students can exchange opinions or questions during the experimentation phase.
Faculty can observe all the sessions for a particular experiment activity. For this purpose, there is a session table on the bottom of the plugin view. This table allows faculty to search for a particular student sessions or about the status of the sessions. It is also a useful element for monitoring the development of the activity.

C. Running a session
Before students can access an experiment activity, they must book a session in advance, as seen in see Figure 4a. This scheduling schema is dynamic, so it avoids students to wait until the laboratory is free. Every time a student checks a date, the system computes all the possible sessions according to the experiment restrictions and the selected day.
If the laboratory is concurrent, the system searches for already booked sessions of the experiment during that session plus the pause gap. If the laboratory is not concurrent, the system search for all the already booked sessions of the laboratory. Afterwards, the system shows the student all the possibilities, as shown in Figure 4b. Students have also a session table, their own sessions, and they can also cancel their previously booked sessions. Each session is checked against the session database, so the system can determine its status. Once the session has started the student can access the experiment. A solar remote laboratory integrated into a Moodle course is shown in Figure 5, which is composed of the needed services for the experiment: a slide, a webcam, a plot, and so on. Since this remote laboratory is an adaptive LaaS, it is possible to show other client interfaces, with a less or additional implemented services, depending on the requirements of the experiment.
Student is reported about the session time left by a temporizer on the top left of the experiment site (see Figure  5). If the experiment has an error or it is busy, the student cannot access to this site. A message is shown by reporting about the incidence and an email is sent to the responsible of the laboratory, in case of an error occurs. The laboratory status is also checked during the experiment session. In case there is an error in the middle of a session, the experiment view is closed and the student is reported by a message about the error.
During the experiment sessions, students can save the obtained data in the server. This is done using the "Save experiment data" button in Figure 5. These files are placed in a file repository within their personal account of Moodle. Students can access them from any computer with an Internet connection, and use them to write the laboratory reports, which are finally sent to the instructors through the LMS. A copy of the students' results is stored in the file area of the plugin, so the original results will be available for the instructors.

D. Monitoring the activity
In our LaaS, there are two main strategies combined for monitoring the performance of the students. On one hand, logging module of Moodle is applied, by means of the Logging API. This module allows Moodle to track activities such as view of a page, add an activity, log into the platform and so on. The plugin can add log activities in events such as the student click on the activity, book a session, delete a reservation for a session, and so on. But it cannot track the student activity inside the session.
On the other hand, one of the advantages of LaaS is the possibility of combination with third-parties services. In this case, Google Analytics offer us a useful information that logging module cannot offer. Google Analytics provide information about the geolocation of the students, and the type of device that they are using during the experiments, among other web metrics as it is shown in Figure 6.

V. CONCLUSIONS AND FURTHER WORK
This work presents a plugin that allows the integration of LaaS into Moodle platform. This integration can be easily achieve due to the flexibility of the paradigm of Laboratories as a Service. Nowadays the plugin is not publicly available. We would like to finish the evaluation phase before release it as a Moodle plugin.
Faculty employs these integrated laboratories at distance subjects, with students from anywhere and at any time. Each available service of our remote laboratories is fully integrated as pedagogical resources within the students' learning process. The developed plugin connects both platforms in order to monitor the users' actions, both students and instructors. As an additional example of the advantages of this approach, the remote laboratories have been also combined with Google Analytics in order to complement the monitoring functionality provided by Moodle. Evaluations from the users' points of view are being conducted in order to analyze students' satisfaction. Since users are continuously monitored, and the associated data is stored, the experimental sessions will be analyzed.