Benoît Verhaeghe

Nicolas Anquetil

Stéphane Ducasse

Abderrahmane Seriai

Laurent Deruelle

Mustapha Derras

Migrating GWT to Angular 6 using MDE

In the context of a collaboration with Berger-Levrault, a major IT company, we are working on the migration of a GWT application to Angular. We focus on the GUI aspect of this migration which, even if both are web frameworks, is made difficult because they use different programming languages (Java for one, Typescript for the other) and different organization schemas (e.g. different XML files). Moreover, the new application must mimic closely the visual aspect of the old one so that the users of the application are not disturbed. We propose an approach in three steps that uses a meta-model to represent the GUI at a high abstraction level. We evaluated this approach on an application comprising 470 Java (GWT) classes representing 56 screens. We are able to model all the web pages of the application and 93% of the widgets they contain, and we successfully migrated (i.e., the result is visually equal to the original) 26 out of 39 pages (66%). We give examples of the migrated pages, both successful and not.

Introduction

During the evolution of an application, it is sometimes necessary to migrate its implementation to a different programming language and/or Graphical User Interface (GUI) framework [START_REF] Brant | Extreme maintenance: Transforming Delphi into C#[END_REF][START_REF] Zirkelbach | On the modernization of explorviz towards a microservice architecture[END_REF]. Web GUI frameworks in particular evolve at a fast pace. For example, in 2018 there were In: A. Editor, B. Coeditor (eds.): Proceedings of the XYZ Workshop, Location, Country, DD-MMM-YYYY, published at http://ceur-ws.org two major versions of Angular, three major versions of React.js, four versions of Vue.js, and three versions of Ember.js. This forces companies to update their software systems regularly to avoid being stuck in old technologies.

Our work takes place in collaboration with Berger-Levrault, a major IT company selling Web applications developed in GWT. However, GWT is no longer being updated with only one major release since 2015. As a consequence, Berger-Levrault decided to migrate its GUI to Angular 6.

The company developes 8 applications using GWT. Each application has more than 1.5 MLOC and represents more than 400 web pages. The applications are built from more than 45 kind of widgets and 29 kind of attributes. The company estimated the migration for one application to 4 000 man-days. So, migrating automatically the visual part of an application would already be a useful step for the modernization of the company's applications. Because of fast evolution of GUI framework, the company also needs a reusable solution for the migration to the next programming language.

There are many published papers on supporting GUI migration (e.g. [START_REF] Erfani | Reverse engineering iOS mobile applications[END_REF][START_REF] Samir | Swing2script: Migration of Java-Swing applications to Ajax Web applications[END_REF][START_REF] Shah | Reverse-engineering user interfaces to facilitate porting to and across mobile devices and platforms[END_REF]). None of them discuss the case of GUI migration of web-based applications.

We present an approach to help developers migrate the GUI of their web-based software systems. This approach includes a GUI meta-model, a strategy to generate the model, and how to create the target GUI. To validate this approach, we developed a tool which migrates Java GWT applications to Angular. Then, we validated our approach on an industrial project that is used to present all the widgets and their usage. It is composed of 470 Java classes and 56 web pages. Our approach imported correctly 93% of the widgets and 100% of the pages. Since not all the existing widgets are re-implemented in Angular, we tried to migrate 39 pages and were successful (same visual appearance) for 26 of them (66%).

First, in Section 2, we review the literature on GUI metamodeling. We describe the context of our project in Section 3. In Section 4, we describe our migration approach. We present our implementation in Section 5. Section 6 describes the experiment we made to validate our approach. In Section 7, we present our results. Finally, in Section 8 and Section 9 we discuss the results obtained with our tool and future work.

2 State of the Art Section 2.1 presents the techniques used to migrate an application. In Section 2.2, we describe the user interface meta-models found in the literature.

Existing migration strategies

To define a migration strategy, we identified research work related to application migration. Some of the proposed approaches do not perform a full migration, but only a part of it. Also, there are numerous publications dealing with programming language migration. We do not, however, consider them if they do not explicitly discuss the GUI migration. This is the case, for example, with the work of Brant et al. [START_REF] Brant | Extreme maintenance: Transforming Delphi into C#[END_REF] that reports on a large Delphi to C# migration.

We identified three techniques to create a representation of the GUI: static, dynamic, or hybrid.

Static. The static strategy consists in analyzing the source code and extracting information from it. It does not execute the code of the analyzed application.

Cloutier et al. [START_REF] Cloutier | WAVI: A reverse engineering tool for web applications[END_REF] analyzed directly the HTML, CSS, and JavaScript files. The analysis builds a syntax tree of the source code of the website and extracts the widgets from the HTML files. The work consists mainly in the identification of links between code source elements of the program (JavaScript classes, HTML tags, etc.). The work presented does not tackle the full migration of the GUI.

Lelli et al. [START_REF] Lelli | Automatic detection of GUI design smells: The case of blob listener[END_REF], Silva et al. [START_REF] João | The GUISurfer tool: towards a language independent approach to reverse engineering GUI code[END_REF] and Staiger [START_REF] Staiger | Reverse engineering of graphical user interfaces using static analyses[END_REF] used tools that analyze source code of desktop applications. The tools look for widget definition in the source code, then they analyze the methods that invoked or are invoked by the widgets and identify the relationships between widgets and their visual properties.

Sánchez Ramán et al. [START_REF] Sánchez Ramán | Model-driven reverse engineering of legacy graphical user interfaces[END_REF] and Garcés et al. [START_REF] Garcés | White-box modernization of legacy applications: The oracle forms case study[END_REF] developed approaches to extract the GUI of Oracle Forms applications. With this framework, developers define the user interfaces in external files where the position of each widget is specified. Their approaches consist in the creation of the hierarchy of widgets from their position. However, the case studies are simple with only few forms or labels. The page layout is also simple because all the elements are displayed below one another.

The static strategy allows one to analyze an application without having to execute it or even compile it. Apart from the classical problem of showing all the potential facts rather than only the real one, another limitation appears for example, with a client/server application, when a part of the graphical interface depends on the result of a request to a server.

Dynamic. The dynamic strategy consists in the analysis of the graphical interfaces of an application while it is running. It explores the application state by performing all the actions on the user interface of the software system and extracting the widgets and their information.

Memon et al. [START_REF] Memon | GUI ripping: reverse engineering of graphical user interfaces for testing[END_REF], Samir et al. [START_REF] Samir | Swing2script: Migration of Java-Swing applications to Ajax Web applications[END_REF], Shah and Tilevich [START_REF] Shah | Reverse-engineering user interfaces to facilitate porting to and across mobile devices and platforms[END_REF] and Morgado et al. [START_REF] Coimbra Morgado | Reverse engineering of graphical user interfaces[END_REF] developed tools that implement a dynamic strategy. However, the solutions proposed are only available for desktop rather than Web applications.

The dynamic analysis allows one to explore all the windows of an application and to gather detailed information about them. However, automatically running an application to methodically capture all its screens might be a difficult task depending on the technology used. Also, if a request is done to build a GUI, the dynamic analysis does not detect this information which may be essential for a full representation of a GUI.

Hybrid. The hybrid strategy tries to combine the advantages of the static and dynamic analyses.

Gotti and Mbarki [START_REF] Gotti | Java swing modernization approach -complete abstract representation based on static and dynamic analysis[END_REF] used a hybrid strategy to analyze Java applications. First they create a model from a static analysis of the source code. The static analysis finds the widgets and attributes of a user interface and how they are structured. Then, the dynamic analysis executes all the possible actions linked to a widget and analyze if a modification occurs on the interface.

Despite the usage of both static and dynamic analysis, the hybrid strategy does not solve the request problem inherent to client/server applications. It also has the same issues as the dynamic analysis of running automatically an application and capturing its screens.

Fleurey et al. [START_REF] Fleurey | Model-Driven Engineering for Software Migration in a Large Industrial Context[END_REF] and Garcés et al. [START_REF] Garcés | White-box modernization of legacy applications: The oracle forms case study[END_REF] worked on full migration of software systems. They developed a tool that semi-automatically performs the migration. To do so, they used the horseshoe process (Kazman et al. [START_REF] Kazman | Requirements for integrating software architecture and reengineering models: Corum ii[END_REF]). The migration is divided into the following four steps:

1. Generation of the model of the original application. None of the authors considered the migration from web GUI to web GUI. Also, none had the constraint of keeping similar layout except Sánchez Ramán et al. [START_REF] Sánchez Ramán | Model-driven reverse engineering of legacy graphical user interfaces[END_REF]; however, they worked on Oracle Forms applications which are very different from a web GUI. As a consequence, their work is not directly applicable to our case study.

User Interface representation

In the previous section, many abstract representations of a GUI are used. We looked to the proposed representations and compared them. We now present the two GUI meta-models defined by the OMG. The Knowledge Discovery Metamodel (KDM) allows one to represent any kind of application. The Interaction Flow Modeling Language (IFML) is specialized in applications with a GUI. Section 2.2.2 presents other representations described in the literature and compare them to the ones of the OMG.

OMG standards

The OMG defines the KDM standard to support the evolution of software. The standard defined a meta-model to represent a piece of software at a high level of abstraction. It includes a UI package which represents the components and behavior of a GUI. It can be refined as UIDisplay or UIField. UIDisplay corresponds to the physical support on which the interface will be displayed, e.g. a computer screen, a printed report, etc. UIField corresponds to a user interface widget, e.g. a form, a text field, a panel, etc. The composition between UIResource and AbstractUIElement is used to define the DOM (Document Object Model). Each UIResource can contain another one to represent a widget that contains another widget.

AbstractUIElement

A UIResource can have, through composition, an UIAction to represent the behavior of the user interface.

The aim of IFML [START_REF] Brambilla | Interaction flow modeling language: Model-driven UI engineering of web and mobile apps with IFML[END_REF] is to provide tools to describe the visible parts of an application, with the components and the containers, the state of the components, the logic of the application and the binding between data and GUI.

Figure 2 represents the meta-model of the visual part of an application. The visible elements of the GUI are called A ViewContainer represents a container of other View-Containers or ViewComponents. For example, it can be a window, an HTML page, a panel etc. The composition between ViewContainer and ViewElement is used to define the DOM.

A ViewComponent corresponds to a widget which displays its content, e.g. a form, a data grid, an image gallery etc. It can be linked to multiple ViewComponentPart. A ViewComponentPart represents an element of a ViewComponent. For example, an input field inside a form, a text which is displayed inside a data grid, or an image element of a gallery.

GUI meta-models

Other GUI meta-models have been proposed in the literature. We compare them to the OMG standards.

All the meta-models use the Composite pattern to represent the DOM of a GUI and define a kind of UIResource entity to represent a graphical element of the interface.

Gotti and Mbarki [START_REF] Gotti | Java swing modernization approach -complete abstract representation based on static and dynamic analysis[END_REF] and Sánchez Ramán et al. [START_REF] Sánchez Ramán | Model-driven reverse engineering of legacy graphical user interfaces[END_REF] proposed a meta-model inspired by the KDM models. The meta-model has the main entities defined by KDM. Both authors added the Attribute entity to the meta-model. They also define different kinds of widgets such as Button, Label, Panel, etc.

Fleurey et al. [START_REF] Fleurey | Model-Driven Engineering for Software Migration in a Large Industrial Context[END_REF] did not explicitly describe the GUI meta-model, but we extracted information from their navigation model. They have at least two elements in their UI model that represent a Window and a GraphicElement. The Window corresponds to the Display entity of the KDM model. And because the GraphicElement and the Window are not linked, we can suppose that the GraphicElement is a UIRessource. The GraphicElement has an Event.

Morgado et al. [START_REF] Coimbra Morgado | Reverse engineering of graphical user interfaces[END_REF] used a UI meta-model but did not describe it. We only know that the UI is represented as a tree which is similar to the DOM.

The UI meta-model of Garcés et al. [START_REF] Garcés | White-box modernization of legacy applications: The oracle forms case study[END_REF] differs a lot from the previous ones. There are the attributes, the events, and the screen but the notion of widget is present as a field which displays data of a table. They also used an Event entity to represent the interaction of the user with the user interface. The Event entity corresponds to the Action and the Event entities of the KDM model.

Memon et al. [START_REF] Memon | GUI ripping: reverse engineering of graphical user interfaces for testing[END_REF] represented a user interface with only two entities. A UI window which is composed of a set of widgets that can have attributes. Representing the DOM was not in the scope of their work. It is not possible to represent it with their meta-model.

Samir et al. [START_REF] Samir | Swing2script: Migration of Java-Swing applications to Ajax Web applications[END_REF] worked on the migration of Java-Swing applications to Ajax Web applications. They created a meta-model to represent the UI of the original application. This meta-model is stored in a XUL (XML-based User interface Language) file and represents the widgets with their attributes and the layout. Those widgets belong to a Window and can fire events when a UI input is performed. The input and the event correspond to the Action and the Event entities of the KDM model. The XUL format has been discontinued.

Shah and Tilevich [START_REF] Shah | Reverse-engineering user interfaces to facilitate porting to and across mobile devices and platforms[END_REF] used a tree architecture to represent the UI. It allows them to model the DOM. The root of the tree is a Frame. It corresponds to the UIDisplay entity. The root contains components with their attributes.

Joorabchi and Mesbah [START_REF] Erfani | Reverse engineering iOS mobile applications[END_REF] represented a user interface with a set of UI elements. Those elements correspond to the definition of a UIField. For each UI element, the authors' tool is able to handle the detection of multiple attributes and actions.

Memon [START_REF] Atif | An event-flow model of GUI-based applications for testing[END_REF] used a UI Model to represent the state of an application. A state is defined as the GUI's widgets and their properties.

Mesbah et al. [START_REF] Mesbah | Crawling ajax-based web applications through dynamic analysis of user interface state changes[END_REF] did not present directly their metamodel for the user interfaces. However, they explain that they use a DOM-tree representation to analyze different web pages. They also used the notion of events that can be fired. They used different instances of their UI metamodel to represent the web pages of the application. Those instances can be compared to multiple UIDisplay entities.

All the authors used the notion of widget that represents a visual entity of the user interface. Most of them have an entity attribute that represents a characteristic of a widget. Finally, the navigation links are represented with an action entity.

Context of the migration project

The goal of our work is to migrate the user interfaces from a given graphical interface framework to another. This is an industrial project, migrating web applications from GWT to Angular. The objective is to produce a running user interface in the target framework. We now present the conditions of the projects. In Section 3.1 we list some constraints that we must fulfill. In Section 3.2 we describe the main differences between GWT applications and Angular ones.

In Section 3.3 we present a categorization of the front-end source code.

Constraints

From the previous works of Moore et al. [START_REF] Moore | Knowledge-based user interface migration[END_REF] and Sánchez Ramán et al. [START_REF] Sánchez Ramán | Model-driven reverse engineering of legacy graphical user interfaces[END_REF], we identify the following constraints for our case study:

• From GWT to Angular. In the context of the collaboration with Berger-Levrault, our migration approach must work with Java GWT as source language and TypeScript Angular as target one.

• Approach adaptability. Our approach should be as adaptable as possible to different contexts. For example, it can be used with different source and target languages. This constraint includes the Source and target independence and the Modularity constraints.

• Keep visual aspect. The migration must keep the visual aspect of the target application as close as possible to the original. This constraint includes the Layout-preserving migration which it is in opposition to the GUI Quality improvement.

• Code quality conservation. As a relaxed Code Quality improvement constraint, our approach should produce code that looks familiar to the developers of the source application. As far as possible, the target code should keep the same structure, identifiers and comments. However, we will see in the next section that there are strong differences in GWT and Angular organization schemas.

• Automatic. An automatic solution makes the approach more accessible. It would be easier to use an automatic approach on large system [START_REF] Moore | Knowledge-based user interface migration[END_REF]. This constraint corresponds to the Automation constraint of the literature.

Comparison of GWT and Angular

In this project, the source language and the target language impose two different organization schemas. Their differences are syntactic and semantic.

GWT is a framework that allows developers to write a web application in Java. The GUI code is compiled to HTML, CSS and JavaScript code. Angular is a front-end web application platform that allows developers to write a web application with the TypeScript language. It is used to create Single-Page Applications 1 .

Table 1 summarizes the differences between GWT applications and Angular ones, concerning: web page definition, their style and the configuration files. Before explaining these three differences, we note one major similarity: • Web Page Definition. In the GWT framework, only one Java file is necessary to define a web page (an excerpt is proposed in Figure 5, page 7). The Java (GWT) file includes the main graphical components (widgets) of the web page, their positions and hierarchical organization. In the case of an actionable widget (as a button), the action is implemented in the same file. In Angular, there is a file hierarchy for each web page. Each web page is considered as a sub-project independent of the others. A sub-project contains two files: an HTML file, containing the widgets of the web page and their organizations; and a TypeScript file, containing the code to execute when an action is performed.

• Visual Aspect. The visual aspect of a web page includes color or dimension of specific displayed elements. In the case of GWT, the specific visual aspect is defined in the Java file of the web page definition.

In Angular, there is an optional distinct CSS file. GWT uses one XML file that defines the binding between a Java file, a web page and the URL of the web page. Figure 3 presents a snippet of the XML file of a Berger-Levrault application. The tag phase (line 3) defines a web page of the GWT application: The web page title is "Home"; it is defined by the Java class PhaseHomeKitchenSink (in package fr.bl.client.kitchensink); and the URL to access the web page is http://myserver.com/KITCHENSINK_HOME. For Angular, there are two configuration files: module, defines the components of the application, e.g. web pages, distant services and graphical component; and, routing, defines for each web page, its associated URL.

Front-end application structure

As proposed by Hayakawa et al. [START_REF] Hayakawa | Maintaining web applications by translating among different ria technologies[END_REF], we divided the migration project in multiple sub-problems. To do so, we define three categories of source code: the visual code; the behavioral code; and the business code.

• Visual Code The visual code describes the visual aspect of the GUI. It contains the elements of the interface. It defines the inherent characteristics of the components, such as the ability to be clicked or their color and size. It also describes the position of these components compared to others.

• Behavioral code The behavioral code defines the action/navigation flow that is executed when a user interacts with the GUI. The behavioral code contains control structures (i.e. loop and alternative).

• Business code The business code is specific to an application. It includes the rule of the application, the distant server address and the application-specific data.

Because of the size and diversity of source code, migrating one of this code category is already an important problem.

Migration Approach

This section presents the migration approach we designed. In Section 4.1, we describe the migration process we designed. Section 4.2 presents our GUI meta-model.

Migration process

From the state of the art, the constraints and the decomposition of the user interfaces, we designed an approach for the migration.

The process, represented in Figure 4, is divided into the three following steps: FAMIX model [START_REF] Ducasse | MSE and FAMIX 3.0: an Interexchange Format and Source Code Model Family[END_REF] of the application using a metamodel capturing Java concepts. We also need to parse the XML configuration file described in Section 3.2.

2.

Extraction of the GUI model. We analyze the source code model to detect the Visual code elements describing the GUI and we build a GUI model from these elements. The GUI meta-model is described Section 4.2.

3.

Export. We re-create the GUI in the target language. This step exports the user interface files and the configuration files of the application.

Note that currently we treat neither the Business code nor the Behavioral code of the application. This will be the focus of future work.

GUI meta-model

To represent the user interfaces of desktop or web-based applications, we designed a GUI meta-model from the ones presented in Section 2.2.2. In the rest of this section, we present the entities of the meta-model.

Our meta-model is an adaptation of KDM metamodel(see Figure 1). As many others, we separate the graphical resources corresponding to the DOM from the actions and events. In our meta-model, graphical resources are called Widget. They can be refined as Leafs or Containers In our context, the user interface will always be displayed on a screen. So we do not represent all the kind of UIDisplay and define an entity Page. The Page represents the main container of a graphical interface. It is either a window of a desktop application or a web page. The Page is a kind of Container.

As proposed by many other authors, we added the entity Attribute in our GUI meta-model. An Attribute represents the information of a widget and can change its visual aspect or behavior. Some common attributes are the height and the width to precisely define the size of a widget. There are also attributes that contain data. For example, a widget representing a button may have a text attribute that contains the text of the button. An attribute can change the behavior of a widget, this is the case of the attribute enable. A button with the enable attribute set to false represents a button on which one cannot click. Finally, the widgets can have attributes that impact the visual aspect of the application. This type of attribute allows us to define a layout to be respected by the widgets contained in the main one and potentially the dimensions of the latter to respect a particular layout.

Implementation

To test our approach, we implemented a migration tool. It is implemented in Pharo2 and the meta-model is represented using the Moose platform3 .

Case Study

Applications at Berger-Levrault (our industrial partner) are based on the BLCore framework. This framework consists in 763 classes in 169 packages. It is developed by the company on top of GWT and defines the widgets that developers should use, the default visual aspect of the applications, and Java classes to connect the front-end of the application to the back-end. It also encourages some coding conventions.

For the Berger-Levrault applications, we add a new entity (Business Page) to the GUI meta-model presented Section 4.2 to fit the company's specific organization. It is a kind of Container. One convention is that each Page has one or more Business Pages represented as tabs in the Page. The widgets (buttons, text fields, tables, . . . ) are included in the Business Pages, never directly in the Page.

Import

In part because of the complexity of setting up a tool to run automatically and capture all screens of such large web applications, we rely on static analysis to create our model. The results so far seem to indicate that it will be sufficient.

As presented Section 4.1, the creation of the GUI model is divided in two steps: the source code model extraction and the GUI model extraction. For the source code metamodel, we use the Java meta-model of Moose [START_REF] Ducasse | MSE and FAMIX 3.0: an Interexchange Format and Source Code Model Family[END_REF][START_REF] Nierstrasz | The story of Moose: an agile reengineering environment[END_REF] which comes with a Java extractor 4 . Figure 5 presents a snippet of the source code of a Berger-Levrault application. It shows the method buildPageUi(Object object) that builds the GUI of the business page SPMetier1 (a "simple business page").

For the second step of the extraction, our tool creates the GUI model from the source code model and an analysis of the XML configuration file. The entities we want to extract are, first, the Pages. We parse the XML configuration file in which is defined the information about the pages (see 1 c l a s s S P M e t i e r 1 e x t e n d s A b s t r a c t S i m p l e P a g e M e t i e r { 3) its name and the name of the Java class that defines it. Then, the tool looks for Widgets.

First, the tool determines the available widgets. To do so, it collects all the Java subclasses of the GWT class Widget. For the Buisiness pages, the tools looks for the classes that implement the IPageMetier interface. Then, the tool looks where the Widget constructors are called and creates the links between the Widgets and their parent Widget. In Figure 5, there are two calls to Widget constructors: line 4, the constructor of BLLinkLabel is called, and line 11, the constructor of Label. The variable vpMain corresponds to the main panel of the Business page. Lines 11 and 12 correspond to adding a widget inside a panel widget thanks to the method add().

Finally, to detect attributes and actions which belong to a widget, the tool detects in which Java variable the widget has been assigned. Then, it searches the methods invoked on this variable. If a widget invokes the method "ad-dClickHandler", it creates an event. If it invokes a method "setX", it creates an attribute. These heuristics were found in the literature [START_REF] Samir | Swing2script: Migration of Java-Swing applications to Ajax Web applications[END_REF][START_REF] João | The GUISurfer tool: towards a language independent approach to reverse engineering GUI code[END_REF]. In Figure 5, the BLLinkLabel, whose variable is lblPg, is linked to one event and one attribute. Lines 5 to 9 correspond to the creation of one event with the executable code. Line 10 corresponds to adding the attribute enabled with the value false.

Export

Once the GUI model is generated, it is possible to export the application. To generate the code of the target application, the tool includes an exporter. The exporter creates the folders of the target application and the configuration files. Then, it visits the pages. For each Page, the exporter creates an Angular sub-project in the form of a directory containing several configuration files and a default blank web page. Then, for each business page of the current visited Page, the exporter generates one HTML file and one TypeScript file. For the HTML file, the exporter builds the DOM thanks to the Composite pattern used by the GUI meta-model (see Section 4.2). Each widget provides its attributes and actions to the exporter.

Validation

In this section, we describe the industrial application on which we used our tool to validate our approach. Section 6.1 presents the industrial application. Section 6.2 presents the metrics we used to evaluate our approach.

Industrial application

We experimented our strategy on Berger-Levrault's kitchensink application. This software system, dedicated to developers, aims to gather inside a single simple application all the components available for building a user interface. This application is smaller than a production one but still uses the BLCore framework. The company framework guarantees us the kitchensink application works exactly the same way as the industrial applications. It contains 470 Java classes and represents 56 web pages. Although it is the sample and demo for developers, the kitchensink application contains code misuses.

Note that the kitchensink application, as the other industrial applications of the company, does not have test. Therefore, there is no possibility to use tests to validate the migration.

Validation metrics

The validation is done in three steps: First, we check the constraints defined in Section 3.1; Second, we validate that all GUI entities of interest are extracted and correctly extracted; Third, we validate that we can re-export these entities in Angular and that the result is correct.

For the first validation, we manually identify and count the entities in the kitchensink application and compare the results of the tool to this count. Our analysis focuses on the migration of three entities: Pages, Business Pages and Widgets • Pages. From the XML configuration file of the application we manually count 56 pages. This configuration file also provides the name of each page.

• Business Pages. As explained before, the business pages correspond to a concept specific to Berger-Levrault. They are defined in the BLCore framework as a Java class which implements the interface IPageMetier. Thanks to this heuristic, we manually count 76 Business Page instances in the original application.

• Widgets. In the literature survey, we did not find an automatic way to evaluate the detection of widgets. Checking all widgets in the application would be long and error-prone as there are thousands of them. As a fallback solution, we take a sample of the pages of the kitchensink application and count the widgets in the DOM of these pages. We consider a sample of 6 Pages which represents a bit more than 10% of the Pages of the application. These Pages are of different sizes and contain different kinds of widgets. In total, we found 238 Widgets in these 6 Pages. To get a more exact idea of the representativeness of our sample, we also count the number of Widget creation (i.e. new AWidgetClass()) in the code. There are 2,081 such creation. This may not represent the exact number of widgets in the entire application, but it is a good estimate. We note that the number of Widgets in our sample (slightly more than 10% of the pages) is also slightly more than 10% of our estimate of the total number of widgets.

For the evaluation, we also check that the Widgets are correctly placed in the DOM of the interface (i.e., they belong to the right Container in the GUI model).

In our results we consider only the recall of the tool because the precision is always 100% (there are no false positive). This is a sign that the BLCore framework provides clear (if not complete) heuristics to identify the entities.

For the second validation, we check that the entities are exported correctly. In the Angular application, each Page corresponds to a sub-project and is represented by a folder. The name of the folder must correspond to the name of the Page. The Business pages are represented by a sub-folder inside the Page project. The names must also match at this level.

We also check visually that the exported Page "looks like" the original one. This is a subjective evaluation, and we are looking for options to automate it in the future.

Results

This section presents the results of the migration validation on Berger-Levrault's kitchensink application. Section 7.2 summarizes the extraction results. In Section 7.1, we confront the exported result with the constraints defined in Section 3.1.

Satisfaction of constraints

We set the following constraints in Section 3.1: From GWT to Angular, Approach adaptability, Code quality conservation, Keep visual aspect, and Automatic.

Our tool can use Java code as input and generate Angular code. The exported code is compilable and executable. The target application can be displayed. We can thus confirm that our tool fulfill the GWT to Angular constraint.

Our tool is applicable on other source target technologies. Our heuristics have been designed to be easy to adapt, a user of our tool can thus add a new kind of widget for the import or the export phases. We shortly describe a small experiment in that sense in Section 8.5. Those possibilities satisfied the adaptability constraint.

The Code quality conservation and Keep visual aspect constraints are discussed in Section 7.3, in the third validation results.

Finally, the results described here were obtained automatically from application of our tool to the subject application. This validates the last constraint.

Extraction results

Table 2 summarizes the extraction results. The tool extracted 56 Pages from the original GUI. This corresponds to the number of pages defined in the configuration file of the kitchensink application.

The tool extracted 76 Business pages. This value corresponds exactly to the number of business pages in the original application. Moreover, the tool correctly assigned each Business page to its proper Page.

We got 100% of the Widgets on the evaluated sample were correctly detected. However, 27 out of the 238 Widgets of our sample (11%) were not correctly assigned to their parent container. All these problems come from one single Page (containing 75 Widgets in total).

Export results

We manually checked the name of all the 56 exported pages. They all conserve their original name. Figure 6 presents the visual differences between the original (GWT) version, left hand, and the migrated (Angular 6) one, right-hand. We can see that there are only minimal differences. In the exported version, the color of the header is a bit clearer, and the lines are a little more distant.

Figure 7 presents the visual differences for the Page Input box. Again on the left-hand side there is the original Page and on the right-hand side the same Page after the migration. Because the two images are large, we

Discussion

Section 8.1 and Section 8.2 presents two parts of the user interface we did not work on. Section 8.3 discusses the impact of the choice of the kitchensink application as case study. Section 8.4 highlights the difficulties in large scale validation of our tool. Finally, Section 8.5 discusses the impact of the BLCore framework.

Layout management

As shown in Section 7.3, the export may give incorrect results because of layout issues (Figure 7). It is due to the representation of the layout in our GUI meta-model. Currently, layouts are represented in our GUI meta-model as an attribute on a Container widget defining if the children of this widget are placed ones beside the other or one below the other (i.e. vertical or horizontal flow layouts). However, many other layouts exist [START_REF] Lok | A survey of automated layout techniques for information presentations[END_REF]. For example, the BLCore framework offers BLGrid, a Widget inheriting from the GWT Grid class and implementing a grid layout. Currently, complex layouts are not considered in our GUI meta-model.

A solution is proposed by Sánchez Ramán et al. [START_REF] Sánchez Ramán | Model-driven reverse engineering of legacy graphical user interfaces[END_REF]. They designed a layout meta-model. The idea consists in linking widgets with a layout and combining the layouts to create a precise representation. The authors defined a subset of possible layout to connect to widgets.

Moreover, with such layouts, the position of the children Widgets might be computed at run time. For example, in a grid layout, the children may be positioned according to the values of some row and col variable. Guessing these values with a static analysis is not practical, and this is a case where an hybrid approach might be necessary.

Managing behavioral and business code

Currently, only the visual part of the GUI is migrated. To take into account the whole application, the migrations of the Behavioral and Business code (see Section 3.3) are needed. The Behavioral represent the user interactions (i.e. click, drag-and-drop, hover, ...) and the control structures (i.e. loop and alternative). In the case of a client/server application, requesting a server is part of Behavioral code, whereas the query in itself and the data belongs to Business code.

Demo application

Although the results are encouraging, we only evaluated our tool on the kitchensink application. The kitchensink application is a good training ground for our tool as it contains all kinds of widgets that developers have at their disposal and the way to use them. However, it might diverge from production applications as it should contain less irregularities or coding tricks than the later.

Validation tools

The automatic validation of the screens migration is currently an unsolved problem. It is possible to manually check the result of the migration for a few pages but it would be better to do it automatically for hundreds of pages (more than 400 on Berger-Levrault applications).

We found, in the literature, only few approaches considering automatic visual validation. In two papers [START_REF] Erfani | Reverse engineering iOS mobile applications[END_REF][START_REF] Sánchez Ramán | Model-driven reverse engineering of legacy graphical user interfaces[END_REF], the authors simply count the number of widgets in the source application and target applications. But we saw in Figure 7 that this not guarantee visual similarity. An other article [START_REF] Moran | Detecting and Summarizing GUI Changes in Evolving Mobile Apps[END_REF] propose to compare screenshots of the original and the exported applications pixel by pixel. However, we saw in Figure 6 that barely distinguishable screens may have differences at the level of pixels.

Impact of BLCore

As explained in Section 5.1, the Berger-Levrault applications are based on the BLCore framework. By specializing GWT, BLCore provides specific widgets and a dedicated API. This may have an impact on our approach or not. To evaluate this possible impact, and also to validate the generality of our approach, we performed two small experiments considering (i) Spec (a desktop UI framework in Pharo [START_REF] Fabry | The Spec UI Framework[END_REF]) as the source framework and, (ii) Seaside (a web framework in Pharo [START_REF] Ducasse | Dynamic Web Development with Seaside[END_REF] -also described at seaside.st) as the target framework. These experiments thus consider different programming languages (Pharo instead of Java (GWT) and TypeScript), different GUI frameworks, and desktop and web applications. We experimented migrating the GUI of small demo application from Spec to Angular, and migrating the Berger-Levrault kitchensink application to Seaside. Some conclusions are:

• It was harder to import Spec code than GWT because of a larger variability in defining the GUI. We conclude that the BLCore framework eased our work on the import by standardizing how to build the pages.

• For Seaside, it was easy to migrate simple widgets (e.g. Label, Button, Panel), but the BLCore framework also defines complex widgets with no direct equivalent in Seaside. A library similar to BLCore should be defined in Seaside to ease the migration.

• the power of our GUI meta-model and the two steps extraction (first, source code model extraction, then GUI model extraction, see Figure 4) are validated by the fact that we were able to migrate a Pharo desktop application with little extra work.

Conclusion and Future works

We created a tool with promising results on the representation of GUI to migrate GWT applications toward Angular.

In the following, we conclude the presentation of this work and propose some future research directions we want to explore.

Conclusion

In this paper, we exposed a preliminary work on the problem of visual preservation and respect of the target architecture during the GUI migration of an application. We proposed an approach based on a GUI meta-model and a migration process in three steps. We implemented this process in a tool to perform the migration fof GWT applications to Angular 6. Then, we validated our tool with an experiment on a kitchensink application. We were able to extract correctly all pages of the application and 89% of the widgets. The migration results are visualizing equivalent as long as complex widgets (e.g. GridLayout) are not used. Dealing with these layouts is our next challenge.

Our solution also allows us to respect the naming conventions used in the source application as well as the structure of the code as far as the differences in the GUI frameworks allow it.

Future work

To improve the migration of an application user interface, we will enhance our meta-model and our tool to support the management of the layout and the behavioral and business code.

We did not find an approach or metrics to automatically evaluate the validity of the migrated screens. So, it is important to find a new way to evaluate that the migrated screens conserve the visual aspect of the original ones.

Having a good GUI meta-model also opens the door for a generic GUI builder that could export the GUI in several different GUI frameworks.

2 . 3 . 4 .

 234 Transformation of this model into a pivot model. This includes data structure, actions and algorithms, user interface, and navigation. Transformation of the pivot model into a target language model. Generation of the target source code.

Figure 1 :

 1 Figure 1: KDM -UIResources Class Diagram

1 < 3 < 6 <Figure 3 :

 1363 Figure 3: Example of a GWT configuration file in XML • Configuration Files. For the configuration files,GWT uses one XML file that defines the binding between a Java file, a web page and the URL of the web page. Figure3presents a snippet of the XML file of a Berger-Levrault application. The tag phase (line 3) defines a web page of the GWT application: The web page title is "Home"; it is defined by the Java class PhaseHomeKitchenSink (in package fr.bl.client.kitchensink); and the URL to access the web page is http://myserver.com/KITCHENSINK_HOME. For Angular, there are two configuration files: module, defines the components of the application, e.g. web pages, distant services and graphical component;

1 .Figure 4 :

 14 Figure 4: Our GUI migration process

7 SFigure 5 :

 75 Figure 5: User interface creation in GWT Section 3.2). It provides for each Page (called phase in the XML file, Figure3) its name and the name of the Java class that defines it. Then, the tool looks for Widgets.First, the tool determines the available widgets. To do so, it collects all the Java subclasses of the GWT class Widget. For the Buisiness pages, the tools looks for the classes that implement the IPageMetier interface. Then, the tool looks where the Widget constructors are called and creates the links between the Widgets and their parent Widget. In Figure5, there are two calls to Widget constructors: line 4, the constructor of BLLinkLabel is called, and line 11, the constructor of Label. The variable vpMain corresponds to the main panel of the Business page. Lines 11 and 12 correspond to adding a widget inside a panel widget thanks to the method add().Finally, to detect attributes and actions which belong to a widget, the tool detects in which Java variable the widget has been assigned. Then, it searches the methods invoked on this variable. If a widget invokes the method "ad-dClickHandler", it creates an event. If it invokes a method "setX", it creates an attribute. These heuristics were found in the literature[START_REF] Samir | Swing2script: Migration of Java-Swing applications to Ajax Web applications[END_REF][START_REF] João | The GUISurfer tool: towards a language independent approach to reverse engineering GUI code[END_REF]. In Figure5, the BLLinkLabel, whose variable is lblPg, is linked to one event and one attribute. Lines 5 to 9 correspond to the creation of one event with the executable code. Line 10 corresponds to adding the attribute enabled with the value false.

  (a) GWT original (b) Angular migration

Figure 6 :

 6 Figure 6: Visual comparison of a Page migration

Figure 7 :

 7 Figure 7: Visual comparison of a Page migration: All the Widgets are migrated but with a wrong layout. trimmed them to display this area of interest. Even though the two images look completely different, all the widgets are present in the migrated version. The visual differences are due to a problem in the layout management. The visual constraint is thus partially satisfied. This point is discussed Section 8.1.

ViewElement. A ViewElement can be refined as a ViewCon- tainer or a ViewComponent.

	+viewContainer	0..1	+viewElements 0..*	<<Metaclass>> IFML::CORE:: ViewElement	+parentViewComponentPart
						0..*
		<<Metaclass>> IFML::CORE::		<<Metaclass>> IFML::CORE::	0..*	<<Metaclass>> IFML::CORE::
		ViewContainer		ViewComponent	ViewComponentPart	+subView
	+ isLandmark : Boolean			ComponentPart
	+ isDefault : Boolean
	+ isXOR : Boolean			<<Metaclass>>
						IFML::Extensions::
	<<Metaclass>> IFML::Extensions:: Window	<<Metaclass>> IFML::Extensions:: Menu	<<Metaclass>> IFML::Extensions:: List	Field	<<Metaclass>>
	+ isModel : Boolean + isNewWindow :	<<Metaclass>> IFML::Extensions::	<<Metaclass>> IFML::Extensions::	IFML::Extensions:: Slot
	Bollean			Details	Form
			Figure 2: IFML -View Elements

Table 1 :

 1 Comparison of GWT and Angular organization schema

		GWT	Angular
	Web page definition	One Java class	One TypeScript file and one HTML file
	Main visual aspect of the application One CSS file	One CSS file
	Specific visual aspect of a web page	Included in the Java file One optional CSS file
	Number of configuration files	One file	Two files
	both GWT and Angular applications have a main CSS file
	to define the general visual aspect of the application.

Table 2 :

 2 Extraction results

		Pages Business Pages	Widgets
				(sample)
	Number	56	76	238
	Correctly imported 100%	100%	89%

Single-Page Applications (SPAs) are Web apps that load a single HTML page and dynamically update that page as the user interacts with the app.

Pharo is a pure object-oriented programming language inspired by Smalltalk. http://pharo.org/

Moose is a platform for software and data analysis. http://www. moosetechnology.org/

verveineJ : https://github.com/moosetechnology/verveineJ


Jean-Emile Dartois
email: jean-emile.dartois@b-com.com

Jalil Boukhobza
email: boukhobza@univ-brest.fr

Vincent Franc
email: vincent.francoise@b-com.com

Olivier Barais
email: barais@irisa.fr

Tracking Application Fingerprint in a Trustless Cloud Environment for Sabotage Detection

Keywords: Correct Execution, Resource Management, Cloud, Fingerprint, Sabotage

Companies are more and more inclined to use collaborative cloud resources when their maximum internal capacities are reached in order to minimize their TCO. The downside of using such a collaborative cloud, made of private clouds' unused resources, is that malicious resource providers may sabotage the correct execution of third-partyowned applications due to its uncontrolled nature. In this paper, we propose an approach that allows sabotage detection in a trustless environment. To do so, we designed a mechanism that (1) builds an application fingerprint considering a large set of resources usage (such as CPU, I/O, memory) in a trusted environment using random forest algorithm, and (2) an online remote fingerprint recognizer that monitors application execution and that makes it possible to detect unexpected application behavior. Our approach has been tested by building the fingerprint of 5 applications on trusted machines. When running these applications on untrusted machines (with either homogeneous, heterogeneous or unspecified hardware from the one that was used to build the model), the fingerprint recognizer was able to ascertain whether the execution of the application is correct or not with a median accuracy of about 98% for heterogeneous hardware and about 40% for the unspecified one.

I. INTRODUCTION

Companies are using more and more computing resources for processing their data and for providing the best Quality of Service (QoS) possible to their customers [START_REF] Kaisler | Big data: Issues and challenges moving forward[END_REF]. These computing resources have a significant cost and companies are seeking solutions to reduce their Total Cost of Ownership (TCO) without sacrificing the correct execution of their applications.

A promising alternative for optimizing the cost of processing applications on Cloud infrastructures is to opportunistically exploit their allocated but momentarily unused computing resources [START_REF] Dartois | Using quantile regression for reclaiming unused cloud resources while achieving sla[END_REF]. Many platforms (e.g., BOINC [START_REF] Anderson | Seti@ home: an experiment in publicresource computing[END_REF], Condor [START_REF] Litzkow | Condor-a hunter of idle workstations[END_REF]) enable the leveraging of these unused resources for a variety of purposes (e.g., scientific computing, big data) and business models (e.g., free, reward). However, any infrastructure owner (i.e, Farmer) can join such platforms to provide/share his computation capacities. These farmers seek to reduce their TCO by making their unused computing resources available to other users. Allowing any farmer to join such platforms exposes an Operator (i.e, interface organizations between the farmers and the customers) to malicious behavior. Malicious farmers can potentially produce erroneous or inaccurate results without effectively running the applications to obtain higher benefits from the Operator (e.g., while saving their computation capacities) [START_REF] Sidiroglou-Douskos | Managing performance vs. accuracy trade-offs with loop perforation[END_REF]. In such a scenario, one needs to investigate how can an operator prevent malicious infrastructure owners from sabotaging the remote computation of its customers.

Many studies have been conducted to provide secure remote computation [START_REF] Arnautov | SCONE: Secure linux containers with intel SGX[END_REF], [START_REF] Sarmenta | Sabotage-tolerance mechanisms for volunteer computing systems[END_REF]. Most of the traditional approaches such as replication voting, ringers, and spot checking -whether with or without blacklisting -have a high overhead on the compute resources (it may double the used resources) to verify each application execution or requires a dedicated hardware such as Intel SGX with 60% of the native throughput and about 2x increase of the application code size [START_REF] Arnautov | SCONE: Secure linux containers with intel SGX[END_REF].

In this paper, we propose a different but complementary solution to state-of-the-art work having the following properties:

• Backward compatibility: non-invasive/non-intrusive on the application code and not limited to a type of application or hardware. • Online execution: continuous verification of the correct execution of the application. • Efficiency: proving a small overhead to verify each application execution

Our approach relies on the use of classification techniques to build a fingerprint model of an application execution in a trusted environment using the Random Forest learning algorithm. In this work, we assume that performance metrics are continuously sent by the farmer as in [START_REF]cadvisor online documentation[END_REF], [START_REF] Aceto | Cloud monitoring: A survey[END_REF]. Then, the built trusted fingerprint model is continuously compared with the current workload metrics sent from the untrusted environment to detect an application execution sabotaging or the alteration of its behavior. To do so, three different cases can be observed: hardware is specified but varies from machine to machine. This means that the model is trained with the same (heterogeneous) hardware mix as the targeted one.

• The unspecified hardware case where the targeted hardware is both unspecified and heterogeneous. This means that the model is not trained with the same hardware mix as the targeted one. We have investigated five applications: multimedia processing, file server, 3D rendering, software development, web application. The used dataset represents about 10 hours of applications execution on the four tested physical heterogeneous machines.

Our experimental results show that our fingerprint recognizer is able to detect the correct execution of applications in a trustless environment with a median accuracy of 99.88% for homogeneous hardware, 98% when using heterogeneous hardware and 44% in case of unspecified hardware during the training phase (see Section IV).

The remainder of the paper is organized as follows. Section II presents some background knowledge. Then, our methodology is described in Section III. Section IV details the experimental evaluation performed. Section VI reviews related work. Finally, we conclude in Section VII.

II. BACKGROUND

This section gives some background on machine learning. Machine learning investigates automatic techniques to make accurate forecasts based on past observations [START_REF] Alpaydin | Introduction to machine learning[END_REF]. Datasets contain a set of parameters called features, used to build a forecasting model for some specific output response metrics. Datasets can either be quantitative (e.g., throughput) or categorical (e.g., spam/not spam). Metrics such as CPU, memory, I/O, and network resources are examples of features while the application name is the label.

There are three different categories in machine learning: supervised, unsupervised and reinforcement learning. Our objective in this study is to build a forecasting model that detects existing relationships between features (e.g., CPU usage, dirty page, I/O read, active file) and a label (the running application). As a consequence, our problem fits in the supervised learning category. Since we want to predict the running remote application which is a categorical value, we used classification-based algorithms.

III. METHODOLOGY

In order to monitor application resource usage, different metrics (e.g., CPU usage, memory usage, throughput, etc.) are utilized. Analyzing and characterizing these metrics would enable one to create predictive fingerprint recognition models that make it possible to verify that the remote machines are effectively executing the requested applications.

One assumption we made is that the farmers are providing those resource usage metrics online for the container used to execute the customer application.

To create such predictive fingerprint recognition models, we propose a framework that is able to control the correct execution of applications in a trustless environment. Our framework is made of three components (see Figure 1). This paper focuses on the Fingerprint Tracker and Fingerprint Builder.

1) The Decision Engine is responsible for handling customer requests which consist in executing the designated applications (1). To do so, the decision engine first verifies whether the fingerprint recognition model for the requested application is available. If not, it requests the Fingerprint Builder to generate one for this new application [START_REF] Dartois | Using quantile regression for reclaiming unused cloud resources while achieving sla[END_REF]. Then, the Decision Engine chooses a suitable farmer that will be in charge of executing the customer application (3) [START_REF] Dartois | Cuckoo: a mechanism for exploiting ephemeral and heterogeneous cloud resource[END_REF]. Finally, it requests the Fingerprint Tracker to verify the correct execution of this application (4).

2) The Fingerprint Builder is responsible for constructing the predictive fingerprint recognition models. To do so, this component uses an environment of trust in order to ascertain the correctness of such models (see Section III-A).

3) The Fingerprint Tracker is in charge of controlling continuously the correct execution of applications in a trustless environment (i.e., the farmer infrastructure) using the predictive fingerprint recognition models previously built by the Fingerprint Builder. In order to achieve that, it first collects the required execution metrics [START_REF] Sidiroglou-Douskos | Managing performance vs. accuracy trade-offs with loop perforation[END_REF]. Then, it identifies the application based on its fingerprint obtained via its resource usage. Finally, it compares this result with the expected application that was communicated by the Decision Engine to determine whether or not the application was correctly executed to trigger potential counter measurements when necessary (6) (see Section III-B). This section details how the Fingerprint Builder constructs the fingerprint recognizer models. Figure 2 describes the overall approach followed with three different steps performed in the trusted environment: Data generation step, Learning step, and Evaluation step.

1) Data Generation step: In the dataset generation phase, we have mainly two steps (see Figure 2): generating the traces by executing different applications and collecting their respective container metrics. We have selected five applications that were deployed in a container-based environment covering various use-cases. Table I summarizes the benchmarks used. To generate the dataset, we used the tools Nginx [START_REF] Reese | Nginx: the high-performance web server and reverse proxy[END_REF], MySQL [START_REF] Mysql | Mysql[END_REF], and WordPress [START_REF] Brazell | WordPress Bible[END_REF] for the web application, FileBench [START_REF] Tarasov | Filebench: A flexible framework for file system benchmarking[END_REF] for the email, ffmpeg [START_REF] Bellard | Ffmpeg[END_REF] for the video application, and blender 1 for the rendering application, GNU Compiler Collection [START_REF] Stallman | Using the gnu compiler collection[END_REF] for the compilation application. Server application: We chose two typical enterprise server applications: an n-tiers web application (WordPress), and email servers (Filebench). WordPress is an Open Source content management system. In our setup, WordPress is deployed with Nginx, PHP, and MySQL.

In the case of a WordPress website, we varied the number of concurrent readers/writers between 1 and 50. Varying the number of users has a direct impact on resource usages. The tool that generates the traffic was executed on a separate host. We used Filebench to evaluate email to generate a mix of open/read/write/close/delete operations. Multimedia processing: ffmpeg is a framework dedicated to audio and video processing. We used two videos, a FullHD (6.3 GB) and an HD (580MB) video. For the transcoding of the H.264 video, we varied the PRESET parameter between slow and ultrafast. This parameter has a direct impact on the quality of the compression as well as on the file size. Blender is a toolset for making 3D rendering, visual effects, art, and interactive 3D applications. We used five 3D models. Software build: Linux kernel compilation uses thousands of small source files. Its compilation demands intensive CPU usage and short intensive random I/O operations 1 blender.org to read a large number of source files and write the object files to the disk. For the sake of our study, we compiled the Linux kernel 4.2. 2) Learning step: Choosing the right learning algorithm for a specific problem is a challenging issue. Many stateof-the-art studies such as [START_REF] Feurer | Efficient and robust automated machine learning[END_REF] have discussed the way to select the appropriate learning algorithm(s) depending on the datasets and the type of problem to solve. The accuracy of a model strongly depends on the dataset and the used learning algorithm. In our case, we used Random Forests (RF) to recognize application fingerprints. RF was introduced in [START_REF] Breiman | Random forests[END_REF], the authors enhanced decision trees by building a large collection of de-correlated trees, and then averaging them. RF are a combination of CART (Classification and Regression Trees) models, which are binary trees, such that each model depends on the values of a random vector sampled from training data independently with the same distribution for all trees in the forest. In CART, the split aims to maximize the accuracy score by splitting the training data with the best feature on each node of the tree. RF accuracy depends on the tuning parameters, called hyperparameters. These hyperparameters impact the complexity of the learning model, and they are estimated to minimize the error.

3) Data Pre-processing: The goal of the pre-processing step is to create the matrix of input features noted x and the vector of the observed labels noted y (i.e., the running application) from the traces stored in the time-series database. The selection of the input features x is a key step to build a good predictive fingerprint model. One needs to consider the variables that have an influence on application fingerprints for the learning algorithms to find the (hidden) relationships between x and y (see Section II).

4) Feature Extraction: In a container environment, there are more than 50 collected metrics such as active files, CPU usage, I/O async, mapped file, pgpgout. This large number of potential features does not allow for an exhaustive search [START_REF] Jain | Feature selection: Evaluation, application, and small sample performance[END_REF]. According to [START_REF] Chandrashekar | A survey on feature selection methods[END_REF] a good feature selection algorithm can be used based on the following considerations: simplicity, stability, number of reduced features, classification accuracy, storage, and computational requirements. According to [START_REF] Hao | Comparison of genetic algorithm and sequential search methods for classifier subset selection[END_REF], PTA(l,r), GPTA(l,r), Sequential Feature Selection (SFFS), and genetic algorithm perform well for such a task.

We used a genetic algorithm to derive a combination of features that maximizes the accuracy of the fingerprint recognition model. Genetic Algorithms (GA) are stochastic optimization methods that mimic the process of natural evolution [START_REF] Yang | Feature subset selection using a genetic algorithm[END_REF]. In GA, a population is composed of individuals. An individual is a potential solution of the optimization problem (i.e., the selection of the best features for detecting the running application). Individual can be scored using at least one fitness function (FF). In our study, the individual is composed of a vector of 1 and 0 indicating whether or not the feature (i.e., the metrics) is selected and the fitness function which is the accuracy classification score calculated by counting the number of correct classifications and divide it by the total number of samples. At each GA step, individuals from a generation of a population mutate using two-point crossover to generate new individuals who inherit from both parents on which random flip could be applied (i.e., a previously selected feature can become unselected). Then, through the fitness function, the best children of the new generation (i.e., those who maximize the classification score) are selected to produce the next generation. Finally, after 100 generations the selected features are then used in a classification process with a Random Forest classifier.

B. Fingerprint Tracker: Tracking application executions

This section details how the fingerprint tracker leverages the fingerprint recognition models in order to ascertain both remotely and online whether or not a sabotage is taking place.

In Figure 3 we highlight the interactions that occur between the trusted (i.e., Operator) and the trustless environment (i.e., Farmer) in order to track the correct execution of the customer applications. To do so, the methodology is the following. First, the operator requests the execution of an application to a farmer (i.e., a trustless resource provider) (1), which subsequently triggers the creation of a container that will host the execution of the application. Then, this designated farmer is asked to supply, every second, the resource usage measurements of the machine that is used to execute the customer application within a predefined time interval (3). These measurements are then ingested by the Fingerprint Tracker to detect the correctness of the execution of the application (4). If either the resource usage measurements are not delivered in a timely fashion or the Fingerprint Tracker detects that the fingerprint is not complying with the expected one for a duration of at Sequence diagram of the interaction between the trusted environment and the trustless environment least 2 minutes (this duration can be adjusted based on the desired confidence level as explained in Section IV), then the Fingerprint Tracker considers that there is a sufficiently high likelihood that a sabotage has taken place during this time frame. In such a case, the Fingerprint Tracker notifies the Decision Engine of a potential sabotage with the associated confidence level [START_REF] Sidiroglou-Douskos | Managing performance vs. accuracy trade-offs with loop perforation[END_REF] so that it can trigger countermeasures, such as spot-checking with blacklist [START_REF] Sarmenta | Sabotage-tolerance mechanisms for volunteer computing systems[END_REF]. Finally, upon completion of the application and after its hosting container has stopped, the Fingerprint Tracker ends its tracking and notifies it to the decision engine [START_REF] Arnautov | SCONE: Secure linux containers with intel SGX[END_REF].

IV. EVALUATION

This section describes the obtained results. Through this experimental part, we try to answer 4 research questions (RQ):

• RQ1: What are the best features for tracking application fingerprint?

• RQ2: What is the accuracy of the fingerprint Tracker for the three use cases: homogeneous, heterogeneous, and unspecified hardware?

• RQ3: How does the accuracy change with regards to the size of the training dataset (learning curve)?

• RQ4: What is the minimum period of monitoring required?

A. Experimental setup

We used four heterogeneous physical machine configurations running Ubuntu 14.04 with Docker 18.06.0-ce. Table II describes the hardware characteristics of machines used by the farmers. We used two DELL server configurations that are very common in data center infrastructures and two uncommon configurations (a laptop and an embedded board).

We made use of Python with the scikit-learn [24] version 0.18 library which provides state-of-the-art machine learning algorithms. Besides, all training and forecasts done by the Operator were performed on servers with an Intel(R) Xeon(R) E5-2630 v2 CPU clocked at 2.60GHz and with 130GB of RAM. In our experiments, we used five applications: video processing, 3D rendering, email server, software development, and web application, which are detailed in Section III-A1. We used the Ubuntu 14.04 LTS GNU Linux distribution with a kernel version 4.2 for M1, M2, and M3, and for M4 a kernel 4.14. The virtualization system used was Docker version 18.06. Finally, we have experimented with 4 heterogeneous physical machines in terms of CPU performance and architecture, and storage (e.g., SSD or HDD) to explore the fingerprint accuracy as compared to the used hardware. 1) RQ1-Selected features: Our approach uses a genetic algorithm to select a subset of the monitored metrics to be used to efficiently train the fingerprint models. For the 5 applications, it emerged that among the 48 metrics the GA method has selected a total of 5 features for homogeneous hardware (see Table III) and 13 features for heterogeneous hardware (see Table IV) for all the applications. We observed that they are mainly related to CPU, memory and storage usage. (comprising all the applications) to build the model and the remaining 30% to evaluate its accuracy for a given hardware architecture. For each execution, we have fixed the hardware architectures and assumed that on the trustless side, the hardware used was the same (i.e., the homogeneous hardware case). We observed that the resulting predictive fingerprint recognition model was very accurate and succeeded in distinguishing between the 5 applications with an accuracy of 99.88%. Figure 5 follows the same methodology as the previous experiment but for the heterogeneous hardware case (i.e., four hardware architectures were combined in a unique dataset so that an application could be run on very different hardware on the trustless side). We remark that WordPress was the most inaccurate application to track with an accuracy of 84%. Figure 6 shows the confusion matrix for five applications in case of unspecified hardware. The accuracy is evaluated as follows: during the training the hardware M1, M2 and M3 are used and then M4 is used for testing. We have chosen the M4 hardware for the test because it is the most different in terms of hardware characteristics. The goal is to be able to evaluate the impact on the fingerprint recognizer accuracy in the (extreme) unspecified hardware case. We observe that compared to the heterogeneous hardware case, the accuracy drops to about 40%. This result means that the application fingerprinting technique may not be relevant when the hardware used for the training is too different from the one used for the test.

3) RQ3-Learning curve: The learning curve shows the evolution of the model accuracy according to the number of training samples [START_REF] Alpaydin | Introduction to machine learning[END_REF], [START_REF] Friedman | The Elements of Statistical Learning[END_REF]. In order to build our learning curve, we performed a progressive sampling by increasing the dataset sizes N training = 1 to N max with a step of 1 second. N max is the total number of samples available. In Figure 7 we show the accuracy of the algorithms according to the training set size. First, we observe, as expected, that the accuracy improves with the increase of the training set size. In case of homogeneous hardware, we observe that with 3000 samples (i.e, 5 minutes) the accuracy reaches 99.95% and 100% with 5500 samples. As compare to heterogeneous hardware, we notice that we need about 3600 samples (i.e., 60 minutes) of application trace to be able to distinguish between the 5 five applications with an accuracy of 97% and it reaches 98% with 5700 samples. Moreover, after about 100 minutes the accuracy does not increase anymore.

4) RQ4-Monitoring Interval:

In Figure 8, we show the size of the monitoring interval in seconds used to predict the running application with regards to the accuracy for the three use cases: homogeneous, heterogeneous and unspecified. We observe that only 1 second is required to achieve 100% accuracy in case of homogeneous hardware. In contrast, we notice that 60 seconds are needed to reach an accuracy of 98% for heterogeneous hardware. Finally, in the unspecified hardware, we observe that the accuracy is capped to 40% and does not improve after about 40 seconds. This application fingerprinting mechanism based on consumed resources can be considered as a second level of security that can be coupled with other existing approaches already proposed in the state of the art studies. Indeed, it may be difficult for a malicious user to cheat on both the output format of the application and the associated stream of measurements that lead to this incorrect result.

In addition, to prevent a saboteur from saving the application usages (e.g., cpu usage) and then sending these metrics to the operator, three actions could be implemented:

1) First, the decision engine scheduler may try to avoid to schedule the same application to the same farmer several times. 2) Second, we propose to use the technique of Proof of Storage [START_REF] Halevi | Proofs of ownership in remote storage systems[END_REF] to ensures that the data is actually stored in the trustless environment. 3) Third, the application binary could be obfuscated to prevent potential reverse engineering by analyzing the binary.

The poor accuracy of fingerprint recognizer in the unspecified hardware case is not a surprise. Indeed, for example, when an application is executed on a physical machine with a large volume of memory buffer, the operating system may delay disk write operations and thus improve the performance [START_REF] Karedla | Caching strategies to improve disk system performance[END_REF]. This could prevent the ML algorithm from identifying the relationship between the application and the selected feature metrics (e.g., utilization of the memory, write back). A consequence, it may fail in identifying the application.

There are several parameters that could affect the accuracy of the model. In the performed experiments, we did not test the sensitivity of the model to changes in kernel parameters. It may be relevant to evaluate the kernel configuration parameters that have a significant impact on model accuracy. Container resource allocation can be configured at runtime using the CGroup configuration interface 2 . As with the static configuration parameter of the kernel, it may be relevant to assess the impact of such a dynamic evolution on the model accuracy. In addition, the virtualization technique used such as Docker, Lxd, Qemu could also have an impact on the model accuracy.

Moreover, the use of a different version of the same application or the modification of the application parameters may also induce a change in the estimated model due to a change in its behavior. We did not consider how co-located application workloads may interfere on applications. We have considered only a fixed capacity per host, while the capacity may depend on all running applications [START_REF] Dartois | Investigating machine learning algorithms for modeling ssd i/o performance for container-based virtualization[END_REF] Finally, monitoring may also affect the estimated model. Indeed, a modification of the implementation of the monitoring component could also affect the model accuracy (e.g., the CPU sampling differs between the training and the testing phase).

VI. RELATED WORK

Numerous studies have already evaluated the correctness of an execution in a trustless environment. In this section, we first focus on the work that tries to validate the computation results. Then, we discuss studies that try to ascertain the correct execution of applications.

A. Ensuring the result correctness and detecting sabotage

In [START_REF] Sarmenta | Sabotage-tolerance mechanisms for volunteer computing systems[END_REF], the objective is to execute the same work unit N times before eventually comparing them -each result being a vote -until converging towards a result. This method has the advantage of ensuring a very high level of certainty with regards to the correctness of the result of a given work unit. However, this comes with two major drawbacks. First, it has a high overhead: N times the initial execution cost with N being the number of votes. Second, the time this method requires to ascertain the falseness of a given execution can be excessively long as many rounds of voting may occur, postponing the decision every time.

In [START_REF] Du | Uncheatable grid computing[END_REF], [START_REF] Zhao | Result verification and trust-based scheduling in peer-to-peer grids[END_REF], a different strategy was used. Contrary to the previous method, the goal here is to minimize the overhead of checking the correctness of an execution by submitting the various resource providers to test. The kind of tests that can be used may rely on four different techniques: naive, quiz, ringers, and spot checking (see [START_REF] Sarmenta | Sabotage-tolerance mechanisms for volunteer computing systems[END_REF], [START_REF] Golle | Uncheatable distributed computations[END_REF]).

B. Application identification and detection

The fingerprinting approach tries to generalize application behavior given its execution traces into a model. This approach has been used in different contexts to identify and detect applications. In [START_REF] Agrawal | Trojan detection using ic fingerprinting[END_REF], [START_REF] Yier | Hardware trojan detection using path delay fingerprint[END_REF], the authors show the benefits of fingerprints to automatically detect hardware Trojan and in [START_REF] Lin | Application classification using packet size distribution and port association[END_REF], Lin et al. are using packet size distribution of the connections to create an application fingerprint.

Side-channel analysis is composed of two steps, commonly referred to identification and exploitation. The identification consists in understanding the leakage and building suitable models. The exploitation consists of using the identified leakage models to extract an information. To build the model, several approaches have shown that it can be approximated in a profiling phase using machine learning techniques. In [START_REF] Gulmezoglu | Cache-based application detection in the cloud using machine learning[END_REF], Gulmezoglu et al. show that the use of cache access profiles could be efficient to classify applications. Zender et al. [START_REF] Zander | Automated traffic classification and application identification using machine learning[END_REF] show the efficiency of unsupervised machine learning to automatically classify traffic and application when the network traffic. In [START_REF] Schuster | Beauty and the burst: Remote identification of encrypted video streams[END_REF], Schuster et al. show that by monitoring an encrypted network traffic a convolutional neural networks can accurately distinguish movies streamed using network traffic bursts.

In this paper, we use machine learning for side-channel analysis. We mainly demonstrate on a set of real applications that a set of 48 metrics commonly used in cloud technology could be utilized to classify application without any assumptions on applications. Contrary to existing work, we neither do any assumption on these metrics nor on the resource usage type of the application (e.g., CPU or memory Intensive) to classify.

VII. CONCLUSION

Tracking the correctness of the application execution over time is necessary to prevent malicious infrastructure owners from sabotaging the computation. Machine learning combined with a fingerprint technique seems to be a relevant approach for homogeneous and heterogeneous hardware. It also shows that the approach is not viable for unspecified hardware.

This paper shows that it is not necessary to take into account application characteristics when trying to track the execution of applications when using our fingerprinting approach that combines both a genetic and a machine learning algorithm.

We evaluated our approach with RF. Our results show that we were able to detect the correct execution with an accuracy of 99.88% with homogeneous hardware, 98% with heterogeneous and 40% with unspecified hardware on the five selected applications.

We will also work toward considering GPU and other processing elements. We also plan to evaluate deep learning algorithms such as Long Short Term Memory (LSTM) which is designed to capture dependencies within an input sequence and GAN (Generative Adversarial Network). Finally, other experiments are underway to apply one-class (i.e., unary classification) to train a model per application.

Finally, as for future work, the prediction ability for unspecified hardware could be improved by normalizing the performance metrics using hardware information provided for example by sysconf. In addition, during the feature selection step, we could also add in the testing set unspecified hardware to let the feature selection algorithm select feature more robust to hardware variations.

Figure 1 .

 1 Figure 1. Overall Approach

Figure 2 .

 2 Figure 2. Training Fingerprint Models Approach

Figure 3 .

 3 Figure 3.Sequence diagram of the interaction between the trusted environment and the trustless environment

  Percentage of CPU utilization active-anon Anonymous memory that has been used more recently inactive-anon Bytes of anonymous and swap cache memory on inactive LRU list pgpgin Number of kilobytes the system has paged in from disk per second. pgfault Number of page faults the system has made per second active-file Bytes of file-backed memory on active LRU list. I/O read, write and sync Number of I/O operations mapped-file Bytes of mapped file (includes tmpfs/shmem) read-bytes Bytes read per second from disk write-bytes Bytes written per second to disk writeback Bytes of file/anon cache that are queued for syncing to disk.

Figure 4 .

 4 Figure 4. Confusion Matrix with Homogeneous Hardware

Figure 5 .

 5 Figure 5. Confusion Matrix with Heterogeneous Hardware

Figure 6 .

 6 Figure 6. Confusion Matrix on Unspecified Hardware

Figure 7 .

 7 Figure 7. Learning curves on the testing set as a function of the number of training samples

Figure 8 .

 8 Figure 8. Accuracy curves as function of the number of testing samples

• The homogeneous hardware case where the targeted hardware is both standardized and specified. This means here that the model is trained with this standardized hardware as the targeted one. • The heterogeneous hardware case where the targeted

https://www.kernel.org/doc/Documentation/cgroup-v1/cgroups.txt

ACKNOWLEDGMENT

This work was supported by the Institute of Research and Technology b-com, dedicated to digital technologies, funded by the French government through the ANR Investment referenced ANR-A0-AIRT-07.