Enhancing EJsS with Extension Plugins

Abstract

Easy JavaScript Simulations (EJsS) is an open-source tool that allows teachers with limited programming experience to straightforwardly bundle an interactive computer science or engineer simulation in an HTML+ JavaScript webpage. Its prominent place in Physics (where it has won several prizes) should not hinder its application in other fields (such as building the front-end of remote laboratories or learning analytics) after having adapted part of the functionality of EJsS to them. To facilitate the future inclusion of new functionalities in EJsS, this paper presents a new version of this tool that allows the enhancement of EJsS, letting it incorporate new tools and change its graphical user interface, by means of extension plugins (special software libraries). To illustrate the benefits of this distributable self-contained non-intrusive strategy, the paper (a) discusses the new methodological possibilities that the Plugins bring to EJsS developers and users, and (b) presents three plugins: one to support the plugin management and the others to easily set up a streamlined remote laboratory. Moreover, the paper also presents the main characteristics of that remote lab to allow readers take advantage of EJsS and the three plugins to set up new online experiments for their students quickly.

1. Introduction

Computer simulations are useful for teaching science and engineering, as they help students to establish relationships between the theoretical concepts and simplified/controlled versions of real-world scenarios [1,2]. Online pedagogical material and courses make some simulations leave the classroom and become interactive graphical tools that, being part of virtual and remote laboratories, allow students to understand the behavior of the system under study [3,4,5]. Ready-to-use simulations are also collected and shared, through different projects and web pages, such as the Interactive Simulations for Science and Math in [6], Open-Source Physics [7] or the University Network of Interactive Laboratories for Control Engineering [8].

Developing interactive graphical simulations usually requires the implementation of the model that defines the behavior of the system (e.g., the Ordinary Differential Equations —ODEs— in dynamic systems), apply a simulation strategy (e.g., an ODE integrator/solver) and build the view (i.e., the graphical user interface) of the simulation. To this end, different applications have already been used and/or combined, ranging from simulation commercial tools (e.g., Modelica, Matlab and EcosimPro) to video games simulation engines (e.g., Unity and Second Life) or generic programming environments (e.g., JAVA, JavaScript + HTML and Node.js), as the following labs/methodologies, to name a few, show [9,10,11,12,13,14,15,16,17]. Despite their success, these approaches require their developers to have a good knowledge of the tool and/or programming technique, hardening the creation of new virtual simulated labs.

Easy JavaScript Simulations [18,19] is an alternative free open-source tool that has earned a prominent place in physics education, with more than a thousand of simulations available in the ComPADRE digital library [20] and several prizes (e.g., the American Physical Society 2020 Excellence in Physics Education Award and the 2015 Multimedia in Physics Teaching and Learning Award). The popularity of EJsS comes essentially from the fact that it simplifies the creation of an interactive learning simulation for people who have a limited programming experience, but who might have great ideas for teaching and experimenting. Within the advantages of EJsS, we consider three of them invaluable. First, it is easy to use due to a clear separation between the model behavior and the view graphical components, and to a trivial and interactive way to link them. Second, its bunch of built-in numerical solvers and powerful event handling mechanisms can cope with many simulation scenarios. Third, it automatically bundles an HTML + JavaScript webpage, which can be directly shared with the students. All these characteristics hide the complexity of the simulation implementation behind the scenes, letting its developers focus their attention on the problem itself and on the creation of an attractive interactive view.

Although the initial goal of EJsS was to facilitate the creation of interactive scientific computer simulations, over the years it has found application in other fields, such as building the front-end of different remote labs [21,22,23,24,25,26,27,28,29,30,31,32,33] or for learning analytics [34]. These new uses of EJsS have required that the developers of this tool, helped by some of its users with advanced programming capabilities, adapt/extend its functionality to/for the necessities of the new application domains. For example, in its remote lab applications the simulation of the model has been substituted by communications routines between the EJsS view and the remote system. Or for performing learning analytics with EJsS, different statistical tools have been incorporated in the newer version of EJsS. Although several of these functionality changes have been addressed in the past by EJsS capability to include new elements in the model (e.g., communication or learning analytics libraries), others (e.g., including new tools and view components, or supporting the edition of the code that interacts with the remote system) have required to modify directly the EJsS code, needing a deep understanding of the tool’s programming, and causing issues in versions compatibility and distribution.

The objective of this work is to present a new standardized way of modifying the functionality and Graphical User Interface (GUI) of EJsS to facilitate its extension to new application domains. In other words, this paper presents a new version of EJsS that takes advantage of its existing capabilities, while adapting its aspect and tools to new types of users without modifying directly EJsS code. Moreover, the presented approach (based on self-contained extension plugins, already incorporated in EJsS version 6.0 and available from [35]) will allow a streamlined non-intrusive distribution of new functionalities and GUI elements of EJsS, and facilitate its maintenance in new releases of EJsS. Moreover, it has been especially designed to bring cohesion to future features of EJsS model and view, and to support the integration of new GUI elements within EJsS.

Furthermore, and to explain how the new version of the tool and methodology works, this paper also presents three of our extension plugins. The first is intended to help EJsS users to install/enable/disable new plugins. The other two plugins can help EJsS users to set up a streamlined remote laboratory. Considering the current COVID-19 teaching scenario, where easy-to-use online teaching resources are required to handle blended and remote learning, we have decided to include also in this work a description of the developed remote lab infrastructure for those readers interested in it. The plugins and the remote lab infrastructure are available from [36].

The rest of the document is structured as follows. Section 2 presents the background, discussing the main characteristics of EJsS, presenting the traditional extension mechanisms, and analyzing their benefits, drawbacks and limitations. Section 3 highlights the methodology changes supported from the version of EJsS that incorporates the extension mechanisms presented in this paper. Section 4 gives an overview of the characteristics of the new extension mechanisms, presents the changes performed in EJsS to support them, and describes the key-points that the features and the architecture of any extension plugin must fulfill. Section 5 illustrates, through case studies and from the EJsS perspective, how the plugins can adapt EJsS to fit the needs of different developers and fields of application. Section 6 describes the main characteristics of the remote lab infrastructure developed to test the plugins, and shows how to set up a remote lab quickly with it and with the help of EJsS enhanced by the same plugins. Finally, Section 7 draws the conclusion and presents the future research lines.

2. Background

The contents of this section are three-fold. On one hand, it describes the main characteristics of EJsS, especially highlighting those ones that are required to understand the new extension mechanism presented in the paper. On the other one, it analyzes the traditional extension mechanisms already supported by EJsS, establishing its differences and limitations. Finally, and as a consequence of the previous analysis, it raises a set of questions about other possible ways of increasing EJsS functionality and making it compatible with future releases of EJsS.

2.1. Easy JavaScript Simulations Overview

Essentially, EJsS [19] is a tool that allows users to define, in a decoupled way, a simulation model using ordinary (and delay) differential equations and the view that conforms its interactive and graphical visualization. Moreover, it takes the model and view defined by the users to generate the HTML + JavaScript code of the corresponding webpage simulation. To this end, EJsS makes use of different numerical integration methods (from fixed step algorithms such as the Euler method to more sophisticated ones such as the Cash–Karp algorithm), built-in event detection and handling procedures, and other sophisticated mechanisms that are useful to create and run complex simulations. Moreover, it incorporates a palette of visual and interactive elements that help users to design illustrative and attractive graphical environments for their simulations. All these features make EJsS a great tool to create interactive simulation and virtual laboratories.

To facilitate the interactions of the developers of the simulations or applications in EJsS, its functionality is also distributed into several areas that group conceptually related elements:

• The Main Editors Panel, placed at the top of EJsS and framed in yellow at Figure 1, gives access, by default, to the three main tools required to define all the aspects of a new simulation. On one hand, the Model Editor, framed in green at Figure 1a, allows to define the variables and the differential equations of the model, to write fixed relations and custom code, and to use extension elements. On the other, the HtmlView Editor, framed in green at Figure 1b, contains, at its left side, the tree of elements that the user has already combined to obtain the current view of the simulation and, at its right side, the palette of available visual and interactive elements (e.g., buttons, sliders, text fields, 2D plots, or 3D drawables). Finally, the Description Editor (which is not displayed in Figure 1 because its functionality has not been modified in the new version of EJsS) is used to let the simulations or applications developers provide helpful information to its final users.
• The Buttons Bar, placed on the right of EJsS and framed in blue at Figure 1, contains shortcuts to common actions, such as building and deploying the application, accessing to global configuration parameters, etc. These buttons can directly trigger an action, or open a dialog that groups several actions or configurations.
• The Output Message Area, placed at the bottom of EJsS and framed in red at Figure 1, serves as a log, where EJsS notifies its direct users (i.e., the simulations or applications developers) of potential errors and of other events that occur during their interaction with the tool.

Finally, for those readers familiar with Easy Java Simulations (EJS, [37]) is worth noting that Easy JavaScript Simulation (EJsS) appeared to complement the former. Moreover, both follow the same decoupled definition methodology, but while the new EJsS encapsulates the simulations as HTML+JavaScript webpages, the old EJS generates a Java applet. For this reason, The arrival of EJsS in 2015 was acclaimed since webservers were removing its applet support for security reasons, and hence EJS applets could no longer be hosted in educational webpages.

2.2. Traditional EJsS Extension Mechanisms

Adapting EJsS functionality to other application fields was already possible due to the following decisive factors:

• The accessibility to the code of EJsS, which is an open-source tool available in a public repository, allows anyone with enough programming knowledge and time to study and customize it to his/her needs. Although this approach undoubtedly offers an absolute control and flexibility, it is not always the best alternative. On one hand, introducing changes into EJsS requires a deep knowledge of its code. Moreover, the implications of a change in other parts of the code are not always obvious, due to the complexity and size of EJsS. On the other one, it is not efficient to modify EJsS with every feature you want to add, because when a new version of EJsS will be released, probably the same changes will have to be reworked.
• The possibility of creating new View Elements to satisfy the needs of new types of users (e.g., to include the visual representation of a frequently used device). To do it, the user must modify the EJsS code locally, implementing the interface of a ViewElement (which will allow EJsS to be aware of its existence and to be able to use it), assigning a new icon to the element and arranging it into a group of the palette components. The new View Element can afterwards be used in the graphical interface of the user application, similarly to the default EJsS View Elements. Although this approach is less code-intrusive than the previous, the new View Element will only be available in the EJsS application where its code has been modified (and hence, it is not available for other users or should be included again in future releases of EJsS).
• The possibility of adding new Model Elements. To allow EJsS to support more behaviors than the usually defined with ordinary/delay differential equations and event handling mechanisms, EJsS allows to encapsulate and reuse other functionality from the initially empty Model Elements Palette. Again, the new Model Element must implement the interface ModelElement to let EJsS be aware of its existence and to be able to access its functionality. However, instead of incorporating this new code straightaway into the code of EJsS, Model Elements can be provided as external libraries of new functionality (e.g., the communication routines of the remote labs) that, once deployed in an appropriated folder, EJsS can load to make them available for the users that require them. This approach helps to easily share the new functionality between users and quickly reuse it in new version of the code.

2.3. Questioning the Extension Mechanisms

It is worth noting that the previous functionality adaptation mechanisms are presented in this paper by decreasing programming difficulty and increasing decoupling with EJsS code. Moreover, although a View Element and a Model Element are conceptually different (the first implements visual components, while the second encapsulates behaviors), they (1) share the mechanism that makes them usable within EJsS (which consists on implementing an interface of a given class) and (2) diverge in the way that they are actually included within EJsS (because the first requires the modification of the EJsS code, while the second can be implemented as an external-loadable library).

While wondering about the reason of the last difference, new questions arose. For instance, could we (or would be useful to) also modify, by using external-loadable mechanisms, other parts of EJsS, such as the tools available from the Buttons Bar or the editors from the Main Editor Panel? Is there a better reason to make some tools accessible from one group of elements of the EJsS interface or from another? Could we bundle modifications in different parts of EJsS in a unique external plugin? Could we distribute the modifications, according to their final purpose, in multiple simultaneously loadable plugins?

To be able to give positive answers to the previous questions we have developed the new extension plugin mechanism for EJsS that is presented in the following sections of this paper. With it, we expect to: (a) provide an elegant strategy to facilitate the improvement of EJsS, (b) let developers with advanced programming capabilities customize or extend the EJsS interface and functionality for its potential final users, (c) support an easy-to-use update-independent distribution method, and (d) let users choose, according to their needs, the specific extensions that they want to incorporate into EJsS.

3. Methodology Overview

In this section, we describe different methodological aspects of the work presented in this paper. In particular, we first describe how the plugins are to be used from the point of view of different types of EJsS users and afterwards, we explain the methodology followed to determined which changes and which benefits should be supported by the plugins.

3.1. Methodology from the Point of View of EJsS Developers and Users

The methodology presented in this paper is intended to allow the adaptation of the functionality and GUI of EJSs to new domains. To be able to do it, two different programming processes are required.

• On one hand, we (as EJsS users with advanced programming capabilities and previous experience in the development of EJsS code) have already modified the core of EJsS to let it load and include the new functions and visual elements that will be bundled in a Plugin into EJS.
• On the other one, users of EJsS with advanced programming capabilities require writing the code of the Plugin, (a) considering the new functionality and visual elements/windows that they want EJsS to have, and (b) adhering to the guidelines that will be presented in the following sections.

Both programming processes are schematized in Figure 2a, using light blue to represent the part of the EJsS code that already existed (previously to our changes), light-green for the code that we have included into EJsS to handle the Plugins, and purple and red for the code associated with two different Plugins, which are bundled as JAR files. In addition, the code developers (named in Figure 2a EJsS developers and Plugin developers accordingly to the type of coding they have performed) are represented by different human icons colored as the code they have created.

From another perspective, in Figure 2b we show how the normal users of EJsS (i.e., those without advanced programming capabilities that develop applications—including simulations—in EJsS and that are therefore called application developers in the figure) benefit from the existence of the new Plugins. At the top, regular EJsS users (in light blue) that want to develop simulations with the normal EJsS functionality use EJsS as always, without taking advantage of the Plugins. At the middle and at the bottom, new types of EJsS users (in purple and red) exploit, with the purpose of developing new types of applications in EJsS, the new Plugins, using the new functionality that appears in EJsS GUI (framed in red) after only putting the Plugin JAR files in a specific folder of EJsS. Moreover, it is worth noting that an application developer can use several Plugins simultaneously to create its applications. At last, the final users (in gray) of any applications developed within EJsS are not aware of how it has been developed and can take advantage of all the properties that their developers (in EJsS) have included in them.

3.2. Methodology to Determine Which Changes and Benefits Should Be Supported by the Plugins

We started our research wondering how we could improve the way people interact with EJsS. That apparently simple question is easier to state than to answer, but we took it as an inspiration to search for ideas and tips that can help us understand how other people use EJsS, and identify the weaknesses that we could address to enhance the tool. In the search for an answer, we extracted information and conclusions from different sources:

• The authors’ experience of many years using EJsS from different perspectives: as normal users (developing simulations and remote labs front ends [23,24,25,26,27,38]) and as software developers (either modifying EJsS, creating Model Elements or integrating with external libraries).
• An informal extraction of needs and requirements of EJsS users, from direct talks with people involved at different levels, and through the study of Model Elements of other developers, looking at what they have done and how. This is somewhat subjective, but an invaluable source of knowledge.
• Based on the study of many remote lab applications that were gathered and analyzed for different literature reviews [39,40].

With all the previous information, we identified some patterns or difficulties that many people faced in their use of EJsS. We cite here the most relevant that will be discussed in the rest of the paper.

• Version conflicts. We found out that it is frequent to have problems due to the use of different versions of EJsS, or extensions that provide extended functionality which are not up to date.
• Distribution. Moreover, sometimes updating such extensions can be problematic, in particular when the user must copy one or more files manually to a specific folder.
• Unspecialized interface. Though EJsS is easy to use, and the Model Elements allow the provision of new functionality, sometimes it can be difficult to completely integrate them in the interface of EJsS, what was degrading the experience of some users.

The rationale of the extension mechanism that we will explain in detail in the following sections is to address the identified difficulties and provide a better interaction with EJsS. Moreover, in Section 4.3, we explain the methodology that the developers of the new Plugins must follow, and in Section 5 we discuss and illustrate how the Plugins are created and used through several case studies, with the intent that newcomers can confidently face these tasks.

4. Extension Plugins to Enhance EJsS

In this section, we overview the main characteristics and allowed adaptation of the extension mechanisms presented in this paper, describe how we have modified EJsS to support them, and explain how to implement them properly.

4.1. Characteristics Overview and Allowed EJsS Adaptations

The extension mechanism presented in this paper is based on the concept of Plugins that must allow (1) to centralize the addition of different capabilities in EJsS, and (2) to customizet/adapt the GUI of EJsS to users with different needs.

Moreover, to ensure the usability of the approach, the new plugin mechanism must also fulfill the following requirements:

• Simple distribution, to facilitate the plugin download and installation.
• Self-contained, to ensure that a plugin contains all the libraries and components it needs to work and that it does not depend on additional actions in the side of the user.
• Non-intrusive, to be able to completely revert its installation if needed.

Before describing the new Plugins mechanism presented in this paper is worth noting that it is a generalization of the EJsS Extensions provided in [41], which encapsulate different Model Elements in different EJsS extension bundles. The novelty of our approach consists of allowing the modification, at some extent, of other parts of the EJsS layout, by providing new Main Editors, or new elements that can be nested inside the Model and HTMLView Editors, or inside the Buttons Bar (as the highlighted red framed areas of the GUI of the new version of EJsS presented in Figure 3 show). In other words, we inherit the possibility of bundling new functionality within EJsS, by not only supporting the inclusion of new Model Elements as previously, but also by giving access to other tools that can be helpful for some EJsS users.

The benefit of the approach, if used properly, will allow the adoption of EJsS as a tool to centralize different tasks that the users should perform for their projects. Let us illustrate it with an example: using EJsS as a central tool to set up a remote laboratory. In this case, the Main Editor menu can include a new tab to give access to a panel that facilitates the configuration of the communications with the remote system. It is also possible to add new Buttons that give instant access to actions that the instructor performs frequently, such as configuring the authentication credentials to connect with the remote lab. Of course, new Model Elements (which encapsulate functionality relevant to the remote lab) or new View Elements (with graphical representations often used in it) can also be added to the EJsS GUI and grouped in a distributable Plugin, bundled in a JAR file.

4.2. Supporting the New Plugins Infrastructure

During the initialization process of EJsS, it creates all the elements of its interface that will be available to the user. In fact, since 2016, it already performs a minor customization, because it allows users to select between two possible versions (Java and JavaScript), each one with a different View panel and slight differences.

To add support for the Plugin mechanism, we have modified EJS initialization process, to make it incorporate, roughly, the following steps:

• Searching for Plugins, i.e., the plugin JAR files that the users have placed in folder workspace/config/CustomPlugins.
• For each plugin JAR file:

  (a)

  Loading resources (panels, buttons, View Elements, and Model Elements).

  (b)

  Adding panels to the Main Editor.

  (c)

  Adding buttons to the Button Bar.

  (d)

  Adding View Elements to the HTML View Editor.

  (e)

  Adding Model Elements to the Model Editor.

From a conceptual point of view, there is a clear separation between the functionalities that the Plugin provides and the structures that must adhere to with the purpose of being integrated within EJsS. Regarding its functionalities, they obviously depend on the particular aims of each Plugin and cannot be discussed here. With respect to the integration, however, it is mostly a systematic task that does not depend on the nature of the Plugin, but rather on the type and quantity of elements that is composed of.

As explained before, the elements the plugin aggregates are instances of the following ones: Main Editor, Bar Button, Model Element and View Element. Moreover, we also allow them to be instances of the Nested Editor, to support the inclusion of multiple editors within a new Main Editor tab. Additionally, each Plugin must implement a JAVA interface, named Plugin, that informs of and lets EJsS use its capabilities. For each element included in the Plugin, it must also provide the implementation of an interface or extend a base class dependent on the type of element. Moreover, Plugins are distributed in the form of single JAR files that contain everything that is needed for running them inside EJsS, a way of proceeding that fits perfectly with the simple distribution and self-containment requirements stated at the previous section. Finally, although the installation of a new Plugin is extremely easy too (and consists of copying the JAR file into a specific folder), the Plugin Manager, presented as the first case of study of Section 5, provides extended features to manage Plugins within the EJsS interface.

To support the extension, we have had to modify the EJsS code, as discussed in Section 2.2 and Section 3.1. However, this is a one-time modification of EJsS, already incorporated in version 6.0, that makes it capable of supporting the Plugin infrastructure, i.e., of discovering, loading and using new Plugins. Hence, the impact in future changes of EJsS are bounded to that part of the code, reducing the maintenance effort. The other side of the coin are the Plugins, which would adapt EJsS to a specific application, following an implementation template that provides the means to add new functionality and customize EJsS interface. Since the Plugin architecture requires the user to be able to modify how things are presented in EJsS, it is clear that we must introduce some changes in the way EJsS builds its interface. However, we have tried to be so little intrusive as possible, because we expect the major changes to be done at the Plugin programming side.

4.3. Plugin Implementation and Architecture

A Plugin implementation is composed of JAVA and JavaScript code, which follows a predefined structure that allows EJsS to load, instantiate, and communicate with it. That way, the tool is aware of the Plugin and can benefit from the capabilities supplied by its code.

Every Plugin must have a main class which implements the JAVA interface Plugin, providing a set of methods required by EJsS. This is the only essential one, but there are many EJsS-provided JAVA classes and interfaces that are at disposal of the developer who wants to build an extension. The most frequently used are the class Editor, which provides a main or nested editor, and the class AbstractModelElement, which provides a template to create new Model Elements. The architectures of the examples described in the following section are later depicted within it.

Regarding the Plugin functionalities, we should remember that EJsS is a tool originally intended to design simulations and generate its corresponding running HTML and JavaScript code. Hence, the Plugin can provide actions that will run either during the designing or running phases, the former coded in JAVA (to be used within the EJsS layout/functionality) while the latter implemented in JavaScript (to be used during the simulations).

Moreover, the development of a new Plugin generally consists of two differentiated tasks: the implementation of the functionalities that the plugin adds to EJsS, and the incorporation of that functionalities into the template that EJsS provides through its extension mechanisms. Although the functionalities are highly Plugin dependent, their incorporation into EJsS is mainly a repetitive task. It is important to distinguish clearly between both tasks, since doing so properly will facilitate the creation of the Plugin and improve the maintainability of its code.

Independently of the complexity of the Plugin, the development of any new one adheres to the following steps:

• Integrating it with EJsS: creating a new class that implements the JAVA interface Plugin.
• Developing its Graphical User Interface: creating the Plugin GUI elements (e.g., editors and buttons).
• Implementing its core functionalities: programming the tools provided by the Plugin to EJsS.

That methodology is followed by the case studies that are discussed in the following section.

5. Case Studies

This section presents three case studies of increasing complexity that illustrate the philosophy of the Plugin adaptation mechanism and give a practical insight on a Plugin development. The first two cases have been selected to show the benefits from adding a simple functionality and a small GUI change to EJsS, while the third is used to explain how to revamp it to present a more friendly interface to a specific type of user.

Prior to each Plugin implementation, there must be a design phase to specify its functionalities and identify the EJsS GUI modifications and components to add. Hence, each case study begins with a statement of the necessities that motivate each extension, follows with an informal specification of the requirements that gather the important technical and functional aspects to be considered, and ends with the actual implementation of the JAVA and JavaScript code that materialize the Plugin.

Finally, although it is out of the scope of this work, we want to remark that an essential part of a successful Plugin design (which consequently should not be neglected) is how the EJsS GUI should be modified for each new application. In other words, the modifications implemented in each Plugin will make the difference between enhancing or degrading the experience of the users of the adapted versions of EJsS.

5.1. Plugin Manager

The Plugin Manager is a simple yet useful Plugin that illustrates the philosophy of our approach. As we have already explained, each plugin is contained in a JAR file that must be put in a certain folder to let EJsS use it. Though the process is straightforward, it still requires the intervention of the user outside the tool. Clearly a better option would be to have a Plugin Manager integrated within the EJsS development environment.

To develop the Plugin Manager, we start listing the basic functionalities it should provide:

• Installing or uninstalling a new Plugin, provided in a JAR file, automatically. In other words, it must let users copy/delete, from EJsS GUI and in/from EJsS designated Plugin folder, each Plugin JAR file.
• Enabling and disabling Plugins, without uninstalling them, to let users decide if a Plugin should or not be loaded into EJsS, without needing to delete its corresponding JAR file.
• Showing the list of installed Plugins, with detailed information about each of them.

We want to make these functionalities accessible through a simple interface that consists of: a list that shows the installed Plugins and lets the user enable or disable them, an area to show detailed info on a specific Plugin, and buttons to install/uninstall Plugins. With these three elements, we have the ingredients to build the graphical interface of the Plugin Manager, but still need to find the better place to put it inside EJsS. Since the Plugin Manager that we are developing is directly related to the EJsS environment, rather than to a simulation, it is appropriate to make its GUI accessible from the Buttons Bar, by including a new button that opens a dialog window with the interface of the Plugin Manager.

After identifying the graphical elements that the Plugin must provide (the button and dialog window), we must implement several classes. The class PluginManager implements the interface Plugin that EJsS needs to be aware of the Plugin, and provides a PluginInstallerButton that builds the GUI that allows the interaction with the Plugin, instantiating a PluginInstallerEditor. The classes PluginInstaller and PluginModel implement its core functionality: the former provides methods to actually handle the installation, uninstallation, enabling or disabling of Plugins; while the latter loads and parses the information (authors, purpose, how to use it,...) of each Plugin. In Figure 4, we can observe the relationships among the classes, and that there is a clear separation among the code that provides the functionality (implemented in PluginInstaller and PluginModel), the code that builds the GUI (PluginInstallerButton and PluginInstallerEditor), and the code that allows the plugin integration with EJsS (PluginManager and Plugin). This division will be followed in all the examples of the paper, because it is a good programming practice for developing and maintaining the Plugins.

Finally, and after implementing the different classes, bundling them in the archive PluginManager.jar, copying it in the appropriate folder and launching EJsS, EJsS main window includes, as Figure 5a shows, the plugin button, which opens the dialog window displayed at Figure 5b. Besides, it is worth noting that the Plugin Manager allows the enabling/disabling of any of the Plugins installed in the designated folder except itself, because disable Plugins are not loaded in EJsS, and therefore a disable Plugin Manager will not be available to let the user enable/disable itself or any other Plugin.

5.2. Users Manager

The Users Manager Plugin is another example of a Plugin that extends the capabilities of EJsS, in this case to provide EJsS users with a tool to manage the database of users of a server that provides access to a remote laboratory. This database is used, for security reasons, to control the access of users who can connect, carry out experiments, monitor the lab or perform maintenance tasks. With every new academic year, the teacher (or person in charge of the lab maintenance) must edit the user database, revoke permissions from students that have passed the course and incorporate the new students to the access list. To facilitate all these tasks, it seems reasonable to integrate the user database editing into the EJsS workflow, making instructors life easier, a tedious process more friendly and less error prone.

To develop the Users Manager, we start again stating what this Plugin must support:

• Retrieving the user database from a remote server.
• Displaying the user information (username, permissions, etc.).
• Modifying user data.
• Importing users from an external file.
• Sending database updates to the remote server.

After determining the Plugin functionality, we focus on its interface: the user needs to be able to configure the server access (i.e., to provide the URL of the server and the credentials of the users), to request/update the user database from the remote server, and to edit the user data. All these elements can be put in the same dialog window that should be accessible from EJsS. In this case, we consider that the best option is to make them accessible from a new tab added to the Main Editor Panel, since from the remote laboratory perspective it can be equally relevant to handle its HTMLView correctly and to update its users efficiently.

To implement this Plugin, we need to take into account the lab server implementation, as it determines the communication protocols and Application Programming Interface (API) that will be used to create it. However, since a thorough discussion of the lab server implementation is not essential to understand this section (and can entangle the vision we want to provide through the examples), we detail it in Section 6, for those readers who are interested in using the remote lab infrastructure that we have developed to test the new Plugins.

During the implementation of this Plugin we have developed the classes that are schematized in Figure 6. In particular, the class UsersManagerPlugin implements the interface Plugin (to let EJsS be aware of it) and registers the class UsersEditor, which is responsible for building the layout of the new main Users editor/manager. Moreover, the class UserUpdater communicates with the server (using Apache HttpComponents), parses and generates the exchanged JSON structures, and imports the database CSV file (using Apache Commons CSV). Finally, the class UserModel encapsulates the user data information (username, password, etc.).

Finally, after the Plugin is implemented and installed, EJsS displays, as Figure 7 shows, the new Users tab in the Main Editor Panel and, after selecting it, the corresponding Users Editor window. Hence, from the point of view of the person in charge of the remote lab, EJsS is now offering a specialized environment that allows the management of the remote laboratory users, avoiding the necessity of additional software tools to do it.

5.3. Remote Laboratory Management

The next case presents a more complex Plugin to use EJsS as an integrated development environment for setting up experiments supported by the remote lab server presented in Section 6. In this case, the Plugin modifies several elements in EJsS GUI and functionality to make it a friendly interface for the lab designers, who will be able to do from it the following tasks:

• Configuring the connection (url, credentials, ...) of different lab instances, to be able to gain access to them.
• Exchanging data with the lab instances during the experiments, to be able to interact with the components of the remote lab, monitoring the evolution of its variables and modifying its configurable parameters.
• Reusing visual and interactive elements designed to automatize and homogenize the experiments interface. The rationale behind this task is that remote labs (especially those included in the same courses) can share many elements of their graphical interface (e.g., login area, execution buttons or data visualizers) that can be reused to (1) facilitate the lab developer task and to (2) present visually coherent experiences to the students (to optimize their time of study and with the system).

Regarding the Plugin interface, we must decide which set of visual elements will provide the previous functionality. To show the remaining types of Plugin extensions supported by the new version of EJsS:

• We have created a new subpanel, named Remote Labs and implemented with class LabControlModelEditor, inside the main Model Editor, where the lab developer must provide the connection information (server IP address and connection port) of the remote labs that would be accessible from EJsS. Moreover, after connecting with the lab, this panel will also show information about which variables of the remote lab will be accessible (readable and/or writable) from EJsS.
• We have developed a new Model Element, named Lab and implemented with class LabControlModelElement, to create, for each of the accessible remote labs, a variable that encapsulate the methods that give access to the remote lab. Thus, different labs will be represented by different instances of the LabControlModelElement, that will be accessible from different parts of EJsS (e.g., from Model Custom code or View elements). Arguably, the LabControlModelElement for the lab instances could introduce redundancy in the remote lab configuration. To avoid duplicity, the configuration of the lab is only included in the LabControlModelEditor. Besides their purpose is clearly different: the LabControlModelEditor is used to know which variables of the lab are accessible from EJsS, while the instances of LabControlModelElement are actually used to access them.
• We have developed two new View Elements. The first one is a button bar to control the execution of the remote lab during each student experiment (i.e., it starts, stops and resets the experience, and connects and disconnects from it). The second one is a grouped set of labels and editable fields to let the student provide its user and password.

To implement this Plugin we have developed the classes that are represented in Figure 8. First, the Java class LabControlModelElement (and its homonym JavaScript object that provides the runtime functionality) implement a Model Element following the traditional extension method (see Section 2.2). Hence, they not depend on the new Plugin mechanism presented in this paper, and could actually be used without it. However, the Plugin extends the functionality of the Model Element to provide an enhanced interface to manage/build remote labs within EJsS. In fact, this approach could be a good way to reuse existent model elements, while providing a better EJsS integration layer. Second, the class LabControlPlugin implements the interface Plugin and is responsible for instantiating and registering the other components: a LabControlModelEditor (which provides the Remote Laboratory configuration panel) and two View Elements (LabControl and LabLogin, for the lab control buttons bar and the student login information). Please note that while the previous components (LabControlPlugin and LabControlModelEditor) are implemented in Java, the latter ones (LabControl and LabLogin) are JavaScript objects that will be directly included into the simulation, which allows for more control and flexibility. Since this Plugin adds more functionalities and graphical elements to EJsS than the Plugins presented in the previous sections, it has also grown in complexity and number of classes/components.

After implementing and installing the Remote Laboratory Management plugin, EJsS layout looks different, as the screenshots of Figure 9 show. On the front screenshot we can see, on the left, that the information of three remote labs has been provided under the Remote Labs tab, and on the right, the details (connection and variables) corresponding to the selected lab instance on the left. On the back-left screenshot, we can observe the instances of the three Lab Model Elements, which can be used in the code and visual elements of the application that the user will develop with EJsS. Finally, on the top right screenshot, the HtmlView Editor shows, on the left that its tree of elements incorporates a student login interface and a lab control button bar, and, on the right, the new View Elements that are available to the developers.

Finally, this study case demonstrates the versatility of the new Plugin extension mechanism: it lets Plugins developers accommodate the EJsS interface and functionality to new users and scopes, which will benefit from the usual simulation and visualization tools of EJsS, and from the extended capabilities supported by each Plugin.

6. The Remote Laboratory

To let readers take advantage of the developed Plugins, this section (1) describes the main characteristics of the remote laboratory which has been specifically implemented to test the Users and Remote Laboratory plugins (described in Section 5.2 and Section 5.3), (2) outlines how to adapt the code of the Lab server for different applications, and (3) explains how to set up the laboratory from EJsS.

6.1. Overview of the Remote Laboratory

The interactions with the remote laboratory are supported by a lab server that we have implemented in Python [42], using the lightweight web development framework Flask [43] and a REpresentational State Transfer (REST) API [44]. We have implemented the server in Python because it is a convenient, popular and open-source programming language, used by a huge community of software developers and supported by many software libraries of different purposes, including several ones that facilitate the interaction with the hardware of a remote lab through different communication ports. We have selected Flask, instead of other popular and featureful web development frameworks such as Django, Tornado and CherryPy, since Flask is a popular framework for web applications developed in Python; it allows the easy set-up, testing and debugging of a minimal server; and can be deployed in different OS and platforms, such as a PC or a Raspberry PI, either as a standalone server or integrated into another web server such as Apache or Nginx. We have selected the REST API for letting the client — EJsS — interact with the lab server that we have developed, since it provides a standardized way to support HTTP requests, which is already used in other remote lab implementations [45,46,47]. Finally, as a discussion of laboratories technologies is out of the scope of this paper, we suggest the following works [4,40] to those readers specifically interested in them.

The remote lab server must provide the functionality required (1) by the User Manager and Remote Laboratory Manager plugins, and (2) by the experiment itself (dependent on the purpose of each lab).

More in detail, to cover the functionalities related with the Plugins (which have been explained in Section 5.2 and Section 5.3), the server API must expose several capabilities, including the users database management required by the Users Manager plugin, and reading/writing the values of the server objects (e.g., inputs and output signals, server variables, parameters) that need to be accessible from the Remote Laboratory Manager plugin. These features are encapsulated into the API GET/POST methods summarized in

Table 1. Methods of the REST API exposed by the remote lab server.

Method	Path	Purpose	Used by
GET	/users/get	Request the user database	Users Manager Plugin
POST	/users/set	Update the user database
GET	/signals/info	Request signals description	Remote Lab Manager Plugin
GET	/signals/get	Request the values of one or more signals
POST	/signals/set	Update the values of one or more of signals

, which are invoked as web services from EJsS.

Additionally, from the perspective of the experiments themselves, the code of the server provides the backbone to create a functional remote laboratory. Essentially, it acts as a middleware that provides the means to connect the client (EJsS) with the code that accesses the hardware, including the student authentication and the management of the signals. The task of the laboratory developers is to fill the gaps between the middleware (server) and the laboratory hardware with the adequate code. For example, a remote laboratory deployed on a Raspberry PI could use the module wiringPi to access its peripheral ports (i.e., its general-purpose inputs/outputs) or pyserial to communicate with serial/USB devices.

6.2. Adapting the Server Code for a Particular Application

To set up the laboratory server, we need to provide the code that implements the specific functionality of each lab, and then integrate it with the generic functionality of the server by providing, in the lab configuration code, the information (name, type and accessibility) of the experiment signals that will be exchanged with EJsS and the handler to the function that the server will invoke when it receives a request to read/write any of those variables.

In order to illustrate this process, we will set up a remote lab that controls an analog single-input single-output system. To do it, we first develop a Python module (named HardwareInterface) that communicates with a Digital-Analog and an Analog Digital Converter (DAC and ADC), which are both connected to an I2C port. For that purpose, our Python module provides two functions: readADC():value and writeDAC(value). Next, we map in the lab configuration file the hardware signals to the server signals that will be exposed to EJsS. For that purpose, and as Figure 10 shows, we create (1) a SIGNALS array that contains an object for each signal (in particular, input and output) with the fields (name, type, read and write) and (2) a HANDLERS array that contains the mapping between each variable and the functions that will actually do the reading or writing (in particular, input is mapped to readADC and output to writeADC). Hence, when the server receives a request to read the variable input it will call the readADC function.

Moreover, another thing that needs to be configured is the user database. To do it we have two options: (1) do it from EJsS (exploiting the Users Manager plugin and the fact that our server includes by default and Admin user) or (2) modify it by hand, editing the file users.db which is a human-readable JSON object.

6.3. Setting up the Lab from EJsS

Once the lab server is well configured and put in production, laboratory developers need to configure the lab client that is used by the students to interact with the lab hardware. We do it from EJsS, enhanced with the brand-new Remote Lab Management and User Management plugins.

The first step is to open EJsS and create a new project or load the existent simulation that we want to use as the front-end of our new lab. Then, and as Figure 11a illustrates, we configure a new lab instance that represents our remote lab by instantiating a LabControlModelElement that encapsulates, as explained in Section 5.3, the API exposed by the lab server. Now that EJsS knows where the lab is located, we may want to look at the LabControlModelEditor that shows the info retrieved from the lab (including the signals that the server exposes, which types they have and whether they can be read, written or both). Should we want to have access to more than one lab server (e.g., two or more replicas of the lab to increase the availability of the experiences from the client side) we could repeat this process to instantiate more labs.

Next, we must develop (or adapt) the client GUI. Hence, we go to the HTMLView Editor and add the elements that allow the interaction with the lab to a new view (or to an existent view, in case we already have one). With that purpose, and as Figure 11b shows, we add a new login widget to the laboratory front-end/client that we are developing, with the purpose of letting the students authenticate and access to the remote laboratory. This widget, LabLogin, which relies on the lab object instantiated in the previous step, provides to the finally developed view, displayed partially in Figure 11b and completely in Figure 11d, with two fields for the credentials (user and password).

At this point, we already can generate a web application that is able to connect to the remote lab. However, it is still not very useful. To improve it, we add, as Figure 11b depicts, the lab control bar. Again, its functionality is provided by the instance of the lab model element created in the first step of this section. After adding the lab control bar to the tree of elements of the view, the view itself contains a bar with 3 buttons (start, stop and connect/disconnect). Their names are very explicit, and do not need much explanation. One cannot send or receive data unless the experiment has been started. One can finish the data exchange when the experiment is stopped. Finally, the connect/disconnect button is included in the lab control bar for convenience to allow connection and disconnection directly from the lab interface.

There is still one important thing to do to keep the web application synchronized with the server: reading and writing the values of the server objects. To that end, the LabControlModelElement provides the following two methods: lab.get(vars, callback) and lab.set(vars, values, callback). Generally, the best place to invoke these methods is within an evolution page that runs periodically, as Figure 11c presents.

At this stage, and once everything has been set up, the laboratory developer uses EJsS play button to run the application, or EJsS package button to generate the client application (whose complete front-end appears in Figure 11d) that can be distributed to the students or hosted in a web server.

Finally, after performing all the previous steps, the student database should be updated (if it has not been done manually during the adaptation of the lab server), taking advantage of the Users plugin for that tasks. To do it from EJsS, we only need, as Figure 7 shows, to provide the lab address and user login, retrieve the database from the lab, modify the student information, and send it back to the lab server.

7. Conclusions

EJsS is a popular open-source tool to develop computational interactive simulations for science and engineering. Its versatility has been exploited in other fields, after extending its functionality.

This works presents a standardized way to enhance EJsS functionality and GUI to new users based on Plugins. The main contribution of the new extension mechanism is that it lets software developers customize EJsS to their workflow or to the workflow of other users that exploit EJsS to develop applications (including simulations), in the way that better fulfills their needs. Through several examples we show the versatility of our proposal and encourage all types of EJsS users to analyze how they use EJsS and to determine what could be improved and adapted in their processes.

At this point, we want to highlight the differences in methodology between the standard approach to enhance EJsS and the one proposed in the paper. The traditional Elements extension mechanism has a particular and limited scope, while our Plugins can also adapt EJsS GUI to specific applications and modify the building environment to expose new functionalities better.

Finally, as two of the illustrative presented Plugins are directly related with the management of remote laboratories, to let their prospective users to exploit the possibility of setting up part of the lab from EJsS, we also provide the lab back-end, a streamlined remote laboratory server that can be easily adapted to different types of experiments.

In the future, and if the plugin architecture finds acceptance between EJsS users, the next step would be to reduce the vanilla EJsS version to a minimal core that provides the base functionality (ODEs, Model/View, ...) and the extensibility mechanism, and move the non-essential EJsS components to Plugins that focus on specific applications, such as process control, robotics, remote laboratories, or whatever a user would find useful. Moreover, we would be happy to provide support during the development of new Plugins, to help users with limited programming capabilities customize EJsS to their needs.