Design of Experiment Planning Environment

Quick shortcuts


The Experiment Planning Environment is the name of the tool that will be used to create new ViroLab-related applications. The main task of this part of the ViroLab presentation layer is to provide a powerful GScript editor for creating applications in an easy way. EPE however is not only an editor – it has to be able to assist the user in different aspects of application development. Features such as Ontology Browser and Grid Resource Registry have to be integrated into EPE, as specific plugins. EPE is responsible for delivering the following functionalities (Figure 6):

Experiment Developer Use Cases
Figure 6. Experiment Developer Use Cases.

The main use-cases are described in details in Section 3.2.

As presented in Figure 7, EPE functionality will be accessible in two different ways:

  • Standalone application – the user will be able to download the environment onto the computer using Java Web Start Technology. This application will be based on the Eclipse RCP/Eclipse SDK with integrated ViroLab plugins.
  • Eclipse Plugins – all the functionality will be encompassed in separate plugins (like Script Editor Plugin, Ontology Browser Plugin). The user can download and integrate these plugins into a normal Eclipse distribution using Java
Experiment Planning Environment – distribution summary
Figure 7. Experiment Planning Environment – distribution summary.

The description of the RCP technology is detailed described in Section 3.2.

The Experiment Planning Environment is an important part of ViroLab components. Together with portal the EPE will be a facade of most of functionality that offered by ViroLab (for the user or for the ViroLab applications developer). So it is crucial to correct design these components.

Decomposition – collaboration with others ViroLab Components

EPE cooperates with many parts of the ViroLab Environment. In Figure 8 we present a diagram of the Experiment Planning Environment components together with connections to the related ViroLab virtual laboratory modules.

ViroLab components together with Experiment Planning Environment
Figure 8. ViroLab components together with Experiment Planning Environment.

The main part of the ViroLab EPE is the Core. It will be developed as a standalone application by using Eclipse Rich Client Platform and will be based on the Eclipse SDK. It will provide a common development environment and offer users some basic functionality like support for workspaces (workspaces are local repositories of projects). More features will be integrated into EPE as plugins – therefore another task of EPE is to provide ‘extension points’ to easily integrate new functionality. With help of RCP this becomes very simple (the programming model is also based on ‘plugin style’ applications).

Communication between ViroLab EPE and other ViroLab Gems (e.g. between Grid Resource Registry Plugin and Grid Resource Registry) will be mostly based on Web Services and the SOAP protocol. Of course there will be some exceptions – such as communication with the Experiment Repository –communication will be done via the HTTP protocol.

Below we present a short summary of the components that EPE depends on:

  • Runtime System – the Runtime system layer is represented by an experiment scripting runtime library. It will provide proper interfaces for the aforementioned data access and computation access subsystems in order for the developed application to use these capabilities. This library will be a central point of ViroLab System - part of it will be integrated into ViroLab EPE as a special designed Ruby’s library. Connection to the core of the runtime system could be possible via a local call or a dedicated protocol over a TCP/IP connection. The integration with the runtime system may in future be supported with the Shibboleth authentication system (for security reasons). The special plugin will be developed.
  • Experiment Repository – Repository is the place where all experiments will be stored. It should support sharing the same ViroLab Project between many different developers. The solution used in ViroLab is the Subversion system (SVN). All protocols supported by Subversion could be used in a plugin to establish connections.
  • Grid Sphere Portal – the Grid Sphere portal will present the result of the experiment for the user. It will also allow to run an experiment plan (created in EPE) by the user. So in this area the dependency between the portal and EPE is done through Experiment Repository. In some cases the experiment will require an additional data to be able to run properly. This data will be inserted by the user via the portlet that will be prepared by the developer in the EPE. This part of GUI will be described in XML files attached in the Experiment Project and stored in the Experiment Repository.
  • Domain Ontology Store - The user wants to browse available resources using a high-level, so the special semantic description is needed which involves communication to the Ontology Browser. The user will interact with dedicated dialogs exposed within his workspace which in turn accesses the server side remotely with a query-response model; this does not involve real data transmission connections but rather a logical set of associations between parts of Registry records and the concepts inside the Domain Ontology Store (DOS). The communication protocol used is SOAP and Uniform Resource Identifiers (URIs) are used to point to exact entities inside an ontology. As the ontology models may grow large the remote lookup mechanism may prove too slow for interactive mode of operation. In such a case, assuming that DOS content will not be changing frequently, some cache system will be supported (EPE will be able to store the ontology in an internal cache on startup).
  • Monitoring Subsystem – The launched experiment may return on-line feedback in order to allow tracing of the experiment’s execution. The responsible for feedback collection and its propagation towards the EPE is Monitoring Subsystem. Since Monitoring Subsystem enables tracing experiment execution on gradual level of abstraction moreover will be generic and highly customizable, execution task might be followed by preparation (configuration) of experiment runtime monitoring. Further utilization of the emerging Monitoring Subsystem is checking out the infrastructure load of the available computing resources which will be implemented by providing a dedicated view embedded in the EPE.
  • Grid Resource Registry –The GRR is a registry where all the relevant information about the available computational resources in the virtual laboratory is stored. It will help the experiment developer search for a suitable processing component capable to carry out the required tasks. The communication layer will be developed by using the SOAP protocol.

Use cases of the interface – sequence diagrams

As introduced before (please refer to Section 3.2 for more details), this section presents the main use cases exploited in Experiment Planning Environment. Some of the use cases from Figure 6 are skipped here – because EPE is a complex application they will be considered for development in the future.

Starting the Experiment Planning Environment

In most cases the user will use ViroLab EPE as a standalone application. Figure 9 demonstrates the sequence of running RCP EPE – this could be initiated by clicking the icon on the user’s desktop.

Starting and stopping Experiment Planning Environment
Figure 9. Starting and stopping Experiment Planning Environment.

After the user clicks on the Desktop Icon (or from command line – step 1) the EPE is preparing to start. After that developer is able to choose a workspace – EPE could have many workspaces in which user works and saves projects (steps 2-4). While ViroLab EPE is starting up, each plugin is activated. It is very important thing – because some of the plugins could do additional activities when EPE is starting. For example – the Ontology plugin will be able to grab all ontology from the registry to its internal cache. The same action could be taken by the Grid Resource Registry Plugin (steps 5-9). After that user can see EPE start page from which he/she can select what he/she is going to do (like create a new experiment, etc.). This is step 10 from Figure 9.

Creating the new Experiment

Creating a new Experiment in ViroLab EPE will be one of the most important functionality – it will help the user create a complete Experiment Project. Figure 10 presents this process.

Creating a new Experiment Project
Figure 10. Creating a new Experiment Project

This process is quite simple – it will be implemented as a wizard. On each page the user will provide information about the experiment.

The crucial thing is to standardize experiment plan and project - it is important from the point of view of Runtime Layer. In most cases ViroLab Experiment may consist of (of course it could be extended in the future with new data):

  • plan source files (JRuby sources) – in the EPE there will be "src" directory,
  • default license file – in the experiment directory (if created),
  • an experiment meta-information file (like the user who creates experiment, description of experiment) - in the experiment directory it will be stored in experiment.xml file,
  • files related to user interface rendering in ViroLab Portal (provided by ViroLab Servlet Generator Plugin) – in the experiment directory in gui directory,
  • dedicated feedback file - an XML file, where users may put their feedback regarding experiment use and the authors may see it, will be stored in feedback.xml file

EPE may also support creating new ViroLab Gems – in this case some additional information are needed (e.g. files connected to deploying gems as the MOCCA component – stored in the main experiment directory). The additional check button will be added to the first wizard page. User invokes wizard by clicking in menu or with special short-key (step 1). After that he/she has to fill in required data (steps 2-8), provide licensing information and confirm the new project (step 10). After creating the new Experiment Project properly, the project structure will be generated with stubs’ files. At this moment the developer could create an Experiment Plan in a script by using the GScript Editor Plugin.

Store Experiment in Experiment Repository

Storing an experiment to the repository is needed if the Experiment is intended to be run by scientists (they simply could not use Experiment Planning Environment – the portal and collaboration tools will be developed for them) or by other developers. The second reason is the situation when two or more developers are working simultaneously on the same Experiment. These are very common situations that occur in real life – when working e.g. on Java, Ruby or C# project. Since many developers got used to version controlling systems (e.g. CVS), the ViroLab Experiment Repository will exploit one of the most known systems – SubVersion (SVN). It keeps track of all work over experiments and allows several (potentially widely separated) developers to collaborate.

Working with the repository could be divided into two stories:

  • share the new Experiment to the repository
  • release the new version of Experiment to the Repository

All of above will be implemented as wizards started by user from EPE menu or by key-shortcut. The first scenario is presented below in Figure 11.

Storing new Experiment
Figure 11. Storing new Experiment

Releasing a new version of Experiment is also quite simple. the experiment developer needs only to provide information about version of the experiment. Two types of Experiment release stage could be used - development and release. The development version is a normal commit – no additional information is needed. Release versioning will be realized by moving current content of the development branch to the experimentName_<version> directory in the releases branch. The complete process is presented in Figure 12.

Storing a new version of the Experiment
Figure 12. Storing a new version of the Experiment

Browse Ontology Repository

Browsing an ontology could be divided into two aspects:

  • Data search scenario involves an experiment developer as the user who contacts the Ontology Repository (hidden by Ontology Facade) with the Ontology Browser Plugin. The purpose of this action is to help the developer to select a data concept that suits the needs of the planned experiment. First of all, the Plugin has to download the relevant model from the store. As this communication is remote and will most probably travel through a high latency network, an approach based on loading the required chunks of the model (in an ad-hoc manner) will probably not provide sufficient interaction quality from the user’s perspective. Therefore this action will be taken when EPE is starting up (could be disabled/enabled in settings), or on user request at background. Please refer to Section 3.2 for more details about starting EPE.
Browse Ontology Repository – grid object search
Figure 13. Browse Ontology Repository – grid object search
  • Grid Object search sequence (see Figure 13) concerns the user who wants to include a specific Grid Object Class into the experiment plan code. These abstract Object Classes will also be arranged in a taxonomy (one per specific domain) based on several possible types of associations (the most popular one to appear in this context is the hyponymy relation that occurs between a specification and a more general term). This taxonomy, when acquired from the store and loaded into the user’s workspace, helps choose a suitable Grid Object Class. Following this step, the Class identifier may be used to contact the Grid Resources Registry (see Section 4 for more details about GRR) and to obtain further information on the selected Grid Object Class.

Browse Grid Resource Registry

Grid Resource Registry Plugin is created for helping the developer in coding with GScript Editor. In Figure 14 a sample use case of the Grid Resource Registry scenario is presented.

Usage of Grid Resource Repository
Figure 14. Usage of Grid Resource Repository

User will be able to display and iterate through all content of Grid Resource Repository in a special window. This window will be displayed after developers choose it from menu or by special shortcut (steps 2-5). Afterwards the user will be able to pick up the object from the repository plugin and paste it into GScript code (steps 6-10).

Another common situation when the user will be able to use the Grid Resource Repository Plugin is code completion. After the user had hit a special combination of keys (like alt+space) a list of the selected object methods will be displayed, of course with the possibility to select a method and paste it into code as a stub – it is covered by steps 11-15.

Browse monitored infrastructure state

Infrastructure Monitoring Plugin is a browser which provides a view of a available computation and network resources and their current state (e.g. its load). As a part EPE plugin it runs independently and separately from other EPE elements – if so it is integrated solely with EPE solely in the presentation layer. Therefore, user will be allowed to browse Grid infrastructure in the one and the same integrated development environment.

Browse monitoring infrastructure state use case
Figure 15. Browse monitoring infrastructure state use case

Infrastructure Monitoring Plugin will extend EPE by providing a view of a monitored infrastructure and by enhancing Grid Resource Registry browsing by complementing Grid Object Instances’ state-related information.

Run experiment

Running the experiment is an easy and convenient process from the user’s point of view. Once the ViroLab runtime (JRuby interpreter with libraries created within ViroLab project) is set as the Ruby interpreter running experiment is analogous way as applications in eclipse environment. In order to select ViroLab runtime, both in standalone application and eclipse with plugin, the following actions are required: open Window -> Preferences in the menu bar, choose Ruby->Installed interpreters options and finally click Add button and enter the name for the interpreter (for instance ViroLab Runtime) and path to the inerpreter executable. In some cases it may be necessary to select open Run wizard (Run->Run…in he menu bar), choose experiment configuration, go to Evironment->Interpreter tab and select the ViroLab Runtime interpreter.

Sequence of Running the Experiment
Figure 16. Sequence of Running the Experiment

Having configured the EPE correctly experiment can be run in many ways. Figure 16 presents the case in which user can choose among run types (local or remote) and insert arguments for the experiment. Runtime wizard can be invoked by clicking Run->Run… in the menu bar or by clicking right mouse button on the experiment file and choosing Run As->Run… in context menu. Once a configuration for launching the experiment is created it can be started simply by clicking Run As->Experiment in context menu or by clicking run button.

EPE main components description with screenshots

In this section we describe main ViroLab’s components.

EPE core

The core of standalone ViroLab Experiment Planning Environment is based on Eclipse Rich Client Platform. It is a part of the Eclipse project created to simplify the process of developing a Rich Client Application.

This framework extends the plug-in development process for Eclipse and allows developers to create a standalone application with the core Eclipse functionality. Therefore, after creating a plugin for Eclipse, there is no need to redesign it at a later stage. This plugin could be used in the RCP environment. So it fits our previous requirements about two possibilities of use EPE as standalone application and as Eclipse Plugin (please refers to the paragraph 3.2). The plugins described in a few next points will be integrated into standalone EPE as it possible to use them in the standard EPE.

Since our EPE has to be compatible with normal Eclipse we will need to use Eclipse SDK core packages as the core of EPE. These packages together with their dependencies will be used in a process named “branding”. Branding is a process of changing high level visual elements to fits requirements in new product. Branding is realized by integration into Eclipse extension points. ViroLab will use extension point’s presented in Figure 17.

Extension points from Eclipse Plugins used by ViroLab Core
Figure 17. Extension points from Eclipse Plugins used by ViroLab Core

Below a description of the main Extension points used in EPE Core is presented:

  • org.eclipse.core.runtime.products – this extension point is responsible for creating properly an application name, preference customization, ViroLab icons, and about text presented in

the ViroLab EPE Help->About dialog.

  • org.eclipse.ui.intro, org.eclipse.ui.intro.config – this extension point is responsible for special form that is shown while ViroLab EPE is started (see Figure 18). This will be a start point of the ViroLab EPE – all main functionalities could be enabled from within this form by clicking one button – like create new Experiment, browse Ontology Repository (please refer to Figure 19) and Browse Grid Resource Registry.
  • – this extension point is used for providing online help with search support. We will support search in the and pages.
ViroLab EPE main window
Figure 18. ViroLab EPE main window

In Figure 18, the start screen of the ViroLab EPE is presented (see previous paragraph for details). Below there is a description of the main menu:

  • File – from this menu developer is able to run ‘new Experiment’ wizard, save the current edited file, close file, switch the current workspace, end, exit the EPE.
  • Edit – standard edit operations like Copy, Paste, Undo, Redo, etc.
  • Navigate - standard navigate operation like Go To, Forward, Back, etc.
  • Ruby – common commands for Ruby syntax – like block comment, uncomment, etc.
  • Search – search for string occurrence in the current project or file
  • Project - standard operation for managing project like Open project, Close project, etc.
  • Run – this menu is integration point for Runtime Plugin – it will be able to start ‘run project wizard’ from this menu
  • Window – menu for windows, perspectives and views management – functionality for opening and closing those entities; from here it will be also possible to run the settings page. This will be the integration point for all additional plugins – they could provide additional settings forms that will be included into main settings dialog.
  • Help - from this menu the user will be able to show ‘Welcome’ page – (presented in Figure 18), run help and show ‘About’ dialog.

Editor Plugin

Editor Plugin is based on Ruby Development Tools developed under open source licence (please refer to page). The screenshots from the main Editor Plugin are in Figure 19.

ViroLab Editor
Figure 19. ViroLab Editor

This plugin will provide at least two views – Main Editor view and Navigator Menu. Main editor is the GScript editor (based on Ruby syntax) equipped with syntax colouring and code completion (for this purpose integration with Grid Resource Repository is needed). Navigator view is required for browsing locally stored ViroLab Experiments. The user will be able to choose an Experiment, next the script that should be opened in the Main Editor window.