Cloud-Based Code Execution Framework for scientific problem solving environments

The project we are working on is driven by the breath research domain [1, 2] but can be used for similar structured research area as well. In many scientific domains several different specialists (e.g. physician, mathematicians, chemists, computer scientists, etc.) are working together and executing long running CPU-intensive computations.

Figure 1 shows the common workflow of a scientific study with probands. Proband is a term used most often in medical fields to denote a particular subject (person or animal) being studied or reported on. Several different specialists, such as physician, medical researchers, technician, chemists and mathematicians could be involved in a single study. In this example, sample data of a proband are collected and used for further analysis (e.g. breath sample, electrocardiogram data). At step (1), a physician takes the sample of a proband and collects additional information (e.g. smoker/non smoker). At step (2), the chemist measures the sample with several different sensors; each sensor device type generates its own raw data format. The chemist mostly uses a problem-solving environment, such as MATLAB, to pre-process the raw data (3). The mathematician uses the pre-processed data to create/adapt/improve/maintain new mathematical algorithms (4). Depending on the goal of the study, different mathematical algorithms are performed (e.g. classification, pattern recognition, clustering, generate mathematical models). The mathematician must be able to recalculate the pre-processed data if required, even if the specific PSE is not installed locally. In our test example his/her results are the output of one single study.

The proposed Code Execution Framework (CEF) will support scientists to work together on the same study during all data preparation and data analysis steps, which could be executed recursively.

The following list outlines some challenges that we handle within this effort.

● All involved specialists will iteratively improve this workflow during the development phase. To increase these iterative steps, each researcher should be able to use his/her favorite problem solving environment. At the moment MATLAB [3], Octave [4] and R [5] are supported. The CEF has been implemented in an ongoing project with the breath analysis community. In this domain the researcher mostly uses MATLAB for pre-processing the data and R or MATLAB for all further mathematical analysis.

● Different specialists use different PSEs for their calculations and provide their results to other scientists for further analysis, probably with another PSE. For example a chemist uses MATLAB to prepare the input data of a mass-spectrometry to identify the required substances and a statistician uses this data to generate statistical analysis in R. That means that two different PSEs must work together within a single study.

● Each scientist must be able to execute different problem solving environment source files out of his/her favorite PSE, without having the other PSE installed. This is especially important for non open source or free PSEs, such as MATLAB. The CEF provides a solution to execute MATLAB code without having MATLAB installed.

● Long running calculations block the computer of the scientists and in terms of a failure (e.g. no disk space) the whole calculation may fail. If the scientist uses the CEF it will manage the failure recovery and invoke the calculation at a new machine again. Additionally, the client computer is free for other uses.

● Nowadays most desktop computers have multiple cores or even multiple processors. MATLAB already supports multi-threaded computation for a number of functions [6]. Some problem solving environments (e.g. Octave and R) are generally single-thread applications. However, these PSEs use existing numeric libraries that can take advantage of parallel execution. R and Octave provide different toolboxes to support multiple cores or the scientist must start the PSE several times for different calculations. Within the CEF, the user specifies the specific method that should be executed in the cloud with different parameter sets in parallel. The results will be merged together and returned back to the client.

The goal of the proposed CEF is to support multiple different problem solving environments and to execute long running CPU-intensive calculations in parallel in a cloud infrastructure. Depending on the requirements of the user, specific calculations must be finished within a certain amount of time. The system can be configured to use a local Eucalyptus installation meeting the demand for base level computations; if required, Amazon EC2 instances can be connected to speed up (bursting) the calculations (hybrid cloud). This can have advantages in terms of time and costs.

The main contributions of this paper include: (a) executing PSE code (R, Octave and MATLAB) in parallel in a cloud platform (preliminary, for Amazon EC2 and Eucalytpus), (b) supporting researchers in PSE code execution, even if the required problem solving environment is not installed locally, (c) allowing the CEF-clients to use the research prototype as a Platform as a Service (PaaS) solution, and (d) in the future, the whole CEF will be offered for a local installation using an own cloud platform.

The rest of the paper is organized as follows. Section ‘Background and related work’ gives some background information about problem solving environments, parallel execution services, cloud environments, and workflow management systems. The usage of the CEF can be seen in Section ‘Usage of the Code Execution Framework within different PSEsFramework within different PSEs.́ In Section ‘Code Execution Framework (CEF) concept’ the CEF is specified and all involved components are defined. Section ‘Implementation’ describes the the prototype implementation. Section ‘Performance tests’ contains the performance results. At the end the open problems and our future work are described in Section ‘Open problems and future work and future work’.

Cloud computing [7] provides computation, software, data access, and storage resources without requiring cloud users to know the location and other details of the computing infrastructure. In general, the amount of data is growing rapidly and the systems processing this data must deal with several data management challenges. Moshe Rappoport [8] outlines the challenges as the four V’s: the Volume, Variety, Velocity and Veracity. This big amount of data must be analyzed with innovated technologies to discover new knowledge. The book [9] presents the most up-to-date opportunities and challenges emerging in knowledge discovery in big data, helping readers develop the technical skills to design and develop data-intensive methods and processes.

According to the applied deployment model, the cloud infrastructure can be divided into public clouds, community clouds, private clouds, and hybrid clouds [10]. The difference between these groups are the location, owner, payment, and user. Several different cloud platforms exist, such as Amazon Web Service (AWS) [11], Eucalyptus [12], and so on. Each cloud infrastructure uses its own storage resources. At AWS it is called S3 [13], at Eucalyptus they use Walrus. Walrus is an open source implementation of S3 and provides the same interface. Different types of service models can be accessed on a cloud computing platform - the most favorite types include Infrastructure as a service (IaaS), Platform as a Service (PaaS) and Software as a Service (SaaS).

A Problem Solving Environment (PSE) is a specialized computer application for solving mathematical or statistical problems, mostly with a graphical user interface [14]. Many scientific research groups use PSEs, such as MATLAB [3], Octave [4] and R [5] for their calculations. For example, in [15] several different applications of MATLAB in science and engineering are shown.

Considering parallel execution services, there are several frameworks described in the literature, such as ParallelR [16], NetWorkSpace for R [17], RevoDeployR [18], and Elastic-R [19] for executing R code in parallel. There are packages and extensions for MATLAB and Octave including Parallel-Octave [20], Multicore [21], and MatlabMPI [22].

There exists already some Web/cloud based tools to remotely communicate with PSEs. There are two different approaches to use MATLAB within the Cloud. The first approach was developed by MathWorks and uses concrete licenses (e.g. MATLAB Distributed Computing Server license). The latter one uses the Component Runtime (MCR) of MATLAB, which does not require licenses for each node. The white paper [23] describes the MathWorks approach in detail. This white paper walks you through the steps of installation, configuration, and setting up clustered environments using these licensed products from MathWorks on Amazon EC2. This license based approach is very expensive, depending on the number of nodes. The advantage of using the Parallel Toolbox is to be able to execute even a for-loop in parallel on different nodes. It is possible to use Red Cloud [24] as a Cloud Service (IaaS) to execute MATLAB code with the MATLAB Distributed Computing Server. With the MCR-approach it is possible to develop a WebService without any costs for licenses. In the paper [25] exactly this approach was addressed within the Grid infrastructure. As further work, the author mentioned that they would like to find out how GridMate behaves on Cloud resources.

With Octave and R, which are developed under the GNU license, all license problems are solved. There already exists a possibility to use Octave as a Cloud Service [26]. With the R-Cloud workbench [27] it is possible to execute R code in parallel in a provided cloud infrastructure (R-Cloud). For R there are solutions to execute R in the Amazon EC2 Cloud [28].

The above mentioned parallel or cloud based execution frameworks have great potential allowing to manage parallel/cloud based code execution for a single PSE. However, the challenge the scientists are facing, e.g. in our ABA-project [29], is dealing with code of different PSEs, sometimes within a single study. Therefore, an infrastructure is needed that provides services to execute own PSE code in the cloud independent from the PSE type or without the need to have a particular PSE installed. Most existing parallel execution services support homogeneous parallelization (execute code in parallel within one PSE type), while our CEF can be used in a heterogeneous environment, as well. For example, it is possible to execute R code within an Octave code execution.

Workflow engines, such as Taverna [30], Kepler [31], ClowdFlows [32], and ADAMS [33], can be used to orchestrate analysis tasks in a workflow. A user of a workflow management system is able to define its own workflows and execute it. A workflow can consist of data services, calculation services, and other services. Our system does not directly include any workflow engine. However, with our CEF it is possible to execute arbitrary R/Octave and MATLAB code in the cloud. The framework provides a Web service interface that can be used within a complex workflow to execute PSE code in parallel. We have already implemented a Taverna activity that is based on these CEF Web services.

In many domains, personal data (e.g. patient data) is involved and therefore privacy and security are very important. The proposed CEF uses a Kerberos based security concept. In [34] we discussed several challenges and their solution, including how to (a) use client authentication through all levels of the system, (b) guarantee secured execution of time consuming cloud based analysis, and (c) inject security credentials into dynamically created virtual machine instances.

In this section, we will demonstrate how the CEF can be used to execute MATLAB or R code in parallel in the cloud. The corresponding Octave code can be implemented in a similar way. To illustrate the usage of the framework, we calculate PI with a Monte-Carlo method [35] as an example for a compute intensive job that can easily be parallelized. This example will be used in Section ‘Performance tests’ for the performance evaluation.

To execute the Monte-Carlo method in parallel, we put a grid over the unit circle (Figure 2) and calculate the number of points in the circle and the total number. PI can be calculated with the following formula

$\Pi =4·\frac{\underset{\sum }{}\text{number\_of\_points\_in\_circle}}{\underset{\sum }{}\text{total\_number}}$

First of all the provided MATLAB or R Code Execution Library must be installed. Secondly we must implement the MATLAB function that should be executed in parallel, as described above. This function uses one array as parameter with 3 values. The first value contains y _{m i n} , the second value y _{m a x} , and the last value is the step size. The code iterates from y _{m i n} to y _{m a x} and from 0 to 1 (x-coordinate) with the given step size and calculates the number of values inside the unit circle (numCircle) and the total number (numAll).

The y_min and y_max parameters are used to select a specific area of the unit circle. Figure 3 shows the calcPi code that calculates the numbers of points inside the unit circle (numCircle) and the total number (numAll).

Figure 4 shows the codes (MATLAB and R) to (a) generate the parameter sets, (b) make a connection to the Code Execution Controller (CEC), (c) execute the calcPi function, and (d) load the calculated result from the CEC. With the three parameters of the CodeExecution constructor you are able to specify whether you would like to execute the calculation in the cloud or locally (1st parameter), the domain name and the port of the used CEC, and whether you would like to use the GUI login or the console login. During the development phase the scientist is able to test her/his method at her/his local machine (the required PSE must be installed). By adopting the first parameter, the whole code will be executed at the cloud based Code Execution Infrastructure.

At the executeCalculation method the scientist must provide the different parameter sets, the method name that should be executed in parallel, and whether this method should be blocked (synchronous) until the parallel execution in the cloud is finished.

To execute PSE code within another PSE (e.g. execute Octave code within R) the scientist can (a) download an existing one by using our PSE, (b) download an existing code by using the Web portal [36], or (c) create a zip file with the new code and a specific property (codeExecution.properties) file. The property file must contain the methodName and the PSE type (e.g. methodName=calcPi, PSE=R). Figure 5 shows how to download PSE code from an already executed calculation and execute the existing code with your favorite PSE and a new parameter set. This can be done even within a remotely executing calculation (recursive). All other methods (described in Section ‘Code Execution Framework (CEF) concept’), can be used in the same way as executeCalculation or getCalculationResults.

In the following sections, the concept of the CEF will be described. We start with describing how the CEF access activation is selected by the specific system parameter useCEF accepting the values FALSE and TRUE. If the value useCEF is FALSE, the whole calculation will be executed in the PSE on the local machine separately. The scientist is able to use all features of the PSE, such as debugging, printing, but must wait until the calculation is completely finished. Without parallel extensions a PSE uses only one core. Depending on the power of the computer used, long running calculations can take a while. If the scientist sets useCEF to TRUE, the CEF will be used. The Code Execution Controller starts the required amount of VMs, transmits the calculation to VMs, executes the calculations, and generates the combined result. The administrator of the CEF must define which cloud platforms (e.g. Amazon EC2, Eucalyptus) are used. For each cloud platform he/she must set (a) what machines types should be used (e.g. m1.small, m1.xlarge), (b) how many instances can be started simultaneously, (c) the shut down behavior (e.g. shut down immediately after all waiting calculations are finished or just before the researcher has to pay for another hour for this idle machine), and (d) the total available daily/monthly budget for this cloud platform. The Code Execution Controller (CEC) is able to call the WorkerNodeStatus Web service from each VM to request the number of available cores, core usage, total and available memory. At the moment the CEC starts the maximum available amount of virtual machines if required, the maximum cost boundary is not yet implemented. The CEC stores all started VMs in a queue. If a calculation is waiting, the first free VM will be used for this execution. In terms of security, the worker node (VM) only accepts requests of the CEC that started the VM. When the calculation at a worker node is finished or failed, the result and log information will be sent to the CEC and afterwards all files from this calculation will be deleted immediately. In the future, the CEC will send sub-calculations from one user to a worker node at the same time, even if multiple cores are available. Therefore it is impossible to spy out data of other users by executing dangerous PSE code.

The advantages for the scientists are (a) the result will be available much faster than running locally, (b) the scientists can use the client computer for other purposes, (c) the scientist can look up the status of the calculation at the CEF-Portal, (d) the scientist is able to download the result to another computer, and (e) the scientist is able to execute other PSE code, even if the required PSE is not installed locally.

Figure 6 shows an overview of the whole CEF. It provides a framework for executing code from different PSEs, including MATLAB, R, and Octave. The system consists of four main parts. That is (a) the Code Execution Controller (CEC) Web application, (b) the different client libraries, (c) the Cloud infrastructure, and (d) the required Code Execution Framework virtual machine. Components depicted in color represent third party libraries that are being reused.

Execution sketches

In this section we walk through a complete execution sketch.

Figure 7 shows more details of the whole calculation process. The arrows show the direction of the communication between the involved systems. At the moment, the CEF can exchange CSV data. To be more generically usable in the future, we are planning to support HDF5 [38] as well. The whole code execution workflow can be started within a supported PSE, Taverna or the Web. Each client has to prepare the code and parameter data. At the first step the client converts the parameter set (e.g. in MATLAB cells or arrays) to a CSV string and zips the required code files (step 1). The maximum number of parallel executable sub-calculations is the number of rows of the parameter set. At the moment, the CEC starts one sub-calculation per row on idle VMs. In the future, the CEC is able to execute several sub-calculations with one Web service invocation at one worker node VM to reduce the transfer and Web service overhead. The number of starting VMs depends on (a) the number of available worker nodes, and (b) the duration of one single sub-calculation. The zip file contains the PSE code and a text file (java properties file) that includes information about the PSE used, compilation status, function name, and their input/output parameters. After the data preparation the client invokes the executeCalculation Web service at the CEC (step 2). The Code Execution Controller (a) stores the received data on the disk, (b) compiles the MATLAB source code, if required (for further information have a look at Section ‘MATLAB Component Runtime approach’), (c) generates the sub-calculations, (d) adds all sub-calculations to the calculation queue (step 3), and (e) starts additional Code Execution VMs, if required (step 4, step 5). A specific thread processes the calculation queue. For each calculation the code will be sent once to the Walrus or S3, depending on the cloud infrastructure used (step 6). This reduces the amount of transmitted data and the required time and costs. Afterwards the sub-calculation will be executed at an idle Code Execution VM(step 7). The worker node (a) requests the Code from Walrus/S3 (step 8), (b) executes the code in the shell (step 9), (c) generates the result CSV, (d) sends the result back to the CEC (step 10), and (e) deletes all generated files. Step (e) is important to keep a minimal amount of free disk space, otherwise we have to start a new instance if the Worker Node has not enough free disk space for further calculations. Additionally this must be done because of security reasons. At the end of the execution, the CEC checks the received data and updates the status information of the calculation. The researcher is able to request the status of the calculation (e.g., running, finished) and the results. Therefore the client invokes the loadCalculationResult Web service method with the id to download the result (step 11). The CEC (a) authorizes the user, (b) checks if the calculation is finished, and (c) generates the result CSV. At the end, the client converts the received CSV result set to the internal data structure of the corresponding PSE.

In this section, detailed information about the implementation is given. Each component provides different Web services as described in Section ‘Code Execution Framework (CEF) conceptwork (CEF) concept’. All Web services are implemented with CXF [40]. The data (PSE source code and CSV parameters) are streamed with MTOM [41]. In our project personal related data is involved and we must implement a fitting security concept. The whole CEF is implemented with a Kerberos based security concept which has been described earlier by us in [34].

Figure 8 gives an overview on our prototype. The figure depicts all involved components. Server 1 (S1, Ubuntu 11.04) is connected to the Internet with a public IP address, located at the university of applied sciences in Dornbirn; this is necessary to be able to use the system outside of the private institute network. This machine is used for several different services. The Key Distribution Center (KDC) and the DNS-Service are used for our Kerberos based security framework. The CEC manages and monitors all calculations. The Web-Portal (Liferay) can be used to monitor calculations without having any PSE installed. Server 2 (S2, Ubuntu 11.04) has a MATLAB with the Compiler toolbox installed. Additionally the own-implemented Web Service to compile MATLAB code is running in the Tomcat on this machine. As Cloud infrastructure, we tested our own Eucalyptus (2.0) and Amazon EC2. Theoretically, all other EC2 compatible cloud infrastructures should work with our system, however we have not tested it so far. Most likely, the VM image must be created for each cloud infrastructure separately. There exist discrepancies how the assignment of internal IP addresses of the VM must be done. At the moment, we provide an image for Amazon EC2 and Eucalyptus. All different cloud infrastructures can be combined to a hybrid system. This can have advantages in terms of speed and costs. The Code Execution Framework can be used in several different ways. The scientist at the client side has to use one of the provided interfaces.

The VM (Ubuntu 11.04) that is used to execute jobs from the CEC contains:

● Startup Tool - This tool will be executed after booting the VM. It (a) requests the required security information from the CEC, (b) downloads a zip file from the storage controller that contains additional files and scripts, (c) downloads the Web application for the Worker Node from the storage control, and (d) starts the Web application within the Tomcat (7.0) application server. Step (b) is used to be able to change the VM (e.g., install libraries, execute shell scripts, etc.) without creating a new VM. We use this feature during our framework development phase.

● Worker Node Web Services - This Web application only accepts requests from the corresponding CEC and manages and monitors all running calculations.

● PSEs - To be able to execute R and Octave code, these libraries with all required toolboxes must be installed. To execute compiled MATLAB code, the VM needs to have the MATLAB Compiler Runtime (MCR) installed.

At the moment, it is possible to test the CEF with your Web portal [36], the R-Client. You are allowed to use our test CEF infrastructure with two worker nodes to execute R, Octave, or already compiled MATLAB code. For more information have a look to the Online-Demo page at our Web portal.

The Code Execution VM is provided for both, AWS and Eucalyptus Cloud platforms. The key performance characteristics are compute, memory, I/O bound. At the moment, the breath analysis community uses mostly CPU intensive calculations and we decided to evaluate the overhead for these criteria. Therefore most relevant performance measures for our application are number of CPUs, size of memory, and data transfer rates (while using a hybrid infrastructure). Therefore we have defined performance evaluations based on these criteria.

The results of the evaluation represent important information aiming to predict the overhead of different infrastructures, which is required to generate the best possible execution plan if multiple cloud platforms are available. To predict the required execution time, we need to execute at least one sub-calculation.

During the following performance tests we found several important results:

● The execution time for our test calculation mainly depends on the cloud infrastructure used and the problem solving environment used.

● MATLAB is the fastest PSE for executing our time consuming PI calculation, even if we need to compile the PSE code.

● The boot procedure of a VM depends not only on the used virtual machine type: The VM must be transmitted from the S3/Walrus to the host node, if it is not already in the cache.

● The transfer speed between CEC and VM cannot be neglected, especially if the internet connection is slower and large data sets must be transmitted (e.g., input data, code, parameter).

In the following paragraphs we provide the detailed results of our performance tests.

In order to evaluate the first prototype of our Code Execution Services, we have conducted three different experiments. In the first experiment we tested the execution time with CPU intensive MATLAB, Octave, and R examples in order to measure the VM overhead and the performance of the whole framework; in the second test we tried to retrieve the rate for the data transfer, and in the last experiment we measured the boot time of the Code Execution VM. A small Eucalyptus private cloud has been installed at our lab at the University of Applied Sciences.

We have implemented Monte-Carlo methods [35] calculating PI in MATLAB, R, and Octave as shown in Section ‘Usage of the Code Execution Framework within different PSEs’. This PI calculation is CPU intensive and can easily be parallelized. Calculating PI is one of the major cloud (MapReduce) evaluation use cases [42, 43]. The calculations were executed in different code execution scenarios: (a) local (1 thread), (b) on a private Eucalyptus cloud, (c) on Amazon Elastic Compute Cloud (EC2), and (d) on a hybrid cloud (Eucalyptus and Amazon Elastic Compute Cloud). All tests have been executed 50 times and the results are arranged in the following tables showing the arithmetic means and standard deviation of the measured values.

At the moment the CEF supports only parameters specified in the CSV format. Because of that constraint only CSV compatible data structures can be transmitted between the CEC and the worker nodes. We plan to support HDF5 [38] for parameter exchange in the future, as well. It is very important to enable transfer of all different kinds of parameters. Load balancing is another feature which is not yet implemented. We currently simply start one calculation at each available core. In the future we will use CPU- and RAM-usage to enable monitoring virtual machines and start additional calculations if possible. Additionally, it is possible to reduce the transfer or Web service overhead by sending multiple sub-calculations to a worker node VM, depending on the available VMs or the execution time of a single sub-calculation. We plan to use this information to generate an execution plan that matches the required boundary conditions (e.g. costs, time) as good as possible. To be able to use the CEF with different prioritized users, we need to add a priority to each calculation/user. The administrator must be able to set a maximum boundary for the costs. This is very important, especially for Amazon usage (VM per hour, data transfer, etc.). In the future we will test the CEF not only with CPU-intensive calculations, but also with a data-intensive calculation.

In this paper we have presented a novel Code Execution Framework (CEF) that is able to execute problem solving environment (PSE) source code in parallel, using a cloud infrastructure. With this framework the scientists are enabled to use different client applications to communicate with our system, (a) out of his/her problem solving environment, (b) Taverna workflow engine, and (c) from our Liferay Web portal. In the future we will implement different other clients (e.g. Galaxy Project), depending on the requests of the CEF users. Additionally, the scientist is able to execute different PSE source code without having the required PSE installed locally. This can be very important for closed source PSEs (e.g., MATLAB) to reduce the license costs. Depending on the cloud infrastructure used, the Code Execution Framework influences the total cost of ownership [46] (e.g., maintenance and ownership costs), as well. When using a self-owned cloud infrastructure, the hardware, maintenance and the energy costs are increasing, whereas when using Amazon Elastic Compute Cloud (EC2), the machines used must be paid per hour. The whole discussed design concept has been implemented in our first prototype. We implemented the framework for the breath analysis domain, however the system is independent of the underlying scientific field and thus can be used for different domains without any adoptions.

The performance test shows the time improvements while executing a CPU-intensive mathematical calculation. The transfer overhead mainly depends on the infrastructure used (e.g., local Eucalyptus or Amazon EC2), the processing speed depends on the VM-type used (e.g., CPU and available memory). If a given calculation can be parallelized by invoking the same method with different parameter sets, the provided easy to use Code Execution Framework will reduce the total execution time rapidly.

As the next step we will define and implement algorithms to predict the required execution time and to generate the best possible execution plan that fulfills the required conditions (e.g. costs, time). In addition to that we will continue our efforts to integrate our system in a workflow environment that can be extended to support our Kerberos based security concept.

Thomas Ludescher is working at the university of applied sciences in Vorarlberg, Austria. He holds a M.Sc. in computer science from the university of applied sciences in Vorarlberg, Austria. Currently he is writing his Ph.D. at the university of Vienna in the field of high productivity e-Science frameworks. He worked several years as a computer scientist for the international breath research community in the context of the European BAMOD-project. His main duties there were to set up a novel database for volatile organic compounds and to develop tools for their automatize access within PSEs. His research interests include in cloud technologies, distributing time consuming problem solving environment calculations, and all aspects related to security frameworks in e-Science infrastructures.

Thomas Feilhauer is a professor for Computer Science at the Fachhochschule Vorarlberg University of applied sciences in Dornbirn, Austria. He has been involved in the set-up of the diplom-program iTec, the bachelor-program Informatik (ITB), and the master-program Informatik (ITM). To extend his research activities, he became a founding member of the Research Center “Process and Product Engineering”. His research interests are in areas of Distributed Systems, Grid & Cloud computing. Selected Project Experience: (a) Partner in the Austrian Grid project, funded by the Austrian Federal Ministry of Education, Science and Cultural Affairs; (b) SWOP (Semantic Web-based Open engineering Platform) - co-funded by the European Commission under FP6; (c) OptimUns - Josef Ressel-Lab, funded by FFG (Österreichische Forschungsförderungsgesellschaft).

Dr. Peter Brezany is a professor of Computer Science in the University of Vienna Faculty of Informatics. He received his Doctor of Philosophy in Computer Science from the Slovak Technical University in Bratislava in 1980. He is known for his work in the areas of high performance programming languages and their implementation for input/output intensive scientific applications. Now his primary research interests focus on large-scale, high-productive data analytics. He leads the GridMiner project that developed the first full-fledged data mining system operating on data streams and data repositories connected to grids and clouds; the system is being used und further developed in other research projects. He published one book monograph, five book chapters and over one hundred papers.