• Aucun résultat trouvé

Outils de mesures

Dans le document Orchestration d'agents mobiles en communauté (Page 157-160)

CHAPITRE 5 : Résultats et mesures

2.1 Outils de mesures

Afin de mesurer les avantages de notre solution et de pouvoir la comparer avec d’autres solutions

existantes, nous avons essentiellement utilisé l’outil SoapUI combiné avec des processeurs Camel.

SoapUI nous permet de lancer des tests et d’avoir des mesures d’un point de vue externe à notre

plateforme. Les processeurs Camel nous permettent d’avoir des mesures plus précises en intervenant

à l’intérieur de notre plateforme.

2.1.1 L’outil SoapUI

SoapUI est un outil de test fonctionnel Open Source (licence GNU) distribué en version gratuite et

commerciale, SoapUI Pro, présentant des fonctionnalités supplémentaires. Il est produit par

l’entreprise Eviware. Il est également disponible comme un plug-in pour les environnements Netbeans

157

entre autres. Son développement en Java (API Swing pour son interface utilisateur) lui permet de

fonctionner sur la plupart des systèmes d’exploitation.

SoapUI est utilisé essentiellement pour tester les Web services (SOAP et REST) et les services HTTP

aussi bien que les services basés sur les échanges de messages (JMS). L’utilisation de SoapUI en tant

qu’outil de test fonctionnel n’empêche pas le fait qu’il soit capable d’effectuer des tests de

performance ou bien d’assurer la simulation des Web services. Cet outil facilite l’implantation des tests

et la création des bouchons appelé « Mocks ». La fonctionnalité « Mocking » est parmi les plus

intéressantes, elle permet d’utiliser le contrat d’interface WSDL d’un service métier pour créer un

programme de simulation de ce Web service et d’éventuellement l'étendre avec des fonctionnalités

supplémentaires.

SoapUI offre la possibilité de définir un projet de test pour des agents d’orchestration. Vu que nos

agents d’orchestration sont exposés comme Web services SOAP, ils exposent un contrat d’interface

WSDL. Nous construisons un projet de test SoapUI nommé « orchestrator-soapui-project.xml » en nous

basant sur ce WSDL. De cette manière, les méthodes offertes par l’agent d’orchestration sont

automatiquement intégrées au projet de tests. SoapUI permet de mesurer le temps de réponse qui est

l’un des paramètres fondamentaux pour évaluer le coût d’une migration.

2.1.2 Processeurs de mesure

Avec l’outil SoapUI nous détenons des mesures vues de l’extérieur de notre plateforme. Mais nous

avons besoin de mesurer aussi des temps internes à notre plateforme tels que la durée d’exécution de

chaque étape dans une orchestration ou bien le temps d’application du Template de migration qui ne

sont pas visibles d’un point de vue externe. Pour ce faire, nous avons implanté des processeurs de

mesure que nous plaçons dans notre orchestration afin de journaliser le passage par des points

d’exécution prédéfinis.

package fr.upec.lacl.charif.migration.processor.metric;

import org.apache.camel.Exchange; ...

public class MetricsProcessor implements Processor { public static String METRIC_TAG = "MIG_METRIC_TAG"; @Override

public void process(Exchange exchange) throws Exception {

String metricLine = (String) exchange.getProperty(METRIC_TAG);

...

if (metricLine == null){

metricLine = exchange.getExchangeId() +" ; "; }

metricLine += System.currentTimeMillis() + " ; " ; exchange.setProperty(METRIC_TAG, metricLine); }

}

158

Le code Figure 5-1 illustre l’implantation d’un processeur de métriques appelé

MetricsProcessor

qui

définit une propriété d’échange dans laquelle il journalise le moment de l’appel d’une étape dans le

cadre d’une orchestration.

Afin de récupérer les informations sur les temps d’exécution, on injecte un processeur appelé

MetricsWriterProcessor

(cf : Figure 5-2) à la fin d’un agent d’orchestration, ce processeur génère une

ligne au format CSV dans un fichier de log (code en gras). La ligne contient l’information concernant le

moment d’exécution de chaque étape de cette orchestration.

package fr.upec.lacl.charif.migration.processor.metric;

import org.apache.camel.Exchange; ...

public class MetricsWriterProcessor implements Processor { Log log = LogFactory.getLog(MetricsWriterProcessor.class);

@Override

public void process(Exchange exchange) throws Exception {

String metricLine = (String) exchange.getProperty(MetricsProcessor.METRIC_TAG);

log.info(metricLine); }

}

Figure 5-2 illustration de la classe « MetricsWriterProcessor»

Afin de faire appel au processeur de mesure suite à chaque étape d’exécution, nous utilisons les

intercepteurs Camel. En effet, Camel définit des intercepteurs qui permettent de traiter les échanges

chaque fois qu’ils sont envoyés d’un processeur à un autre. Camel définit trois types d’intercepteurs :

intercept

qui intercepte chaque étape de traitement durant le routage d'un échange dans une

route.

interceptFrom

qui intercepte l’échange entrant dans la route.

interceptSendToEndpoint

qui intercepte l’échange avant son envoi à l'Endpoint donné.

Nous utilisons le type «

intercept

» afin de router l’échange intercepté entre deux étapes vers les

processeurs de mesure, pour ce faire, nous rajoutons la définition de l’intercepteur au contexte Camel

de l’agent d’orchestration utilisé pour notre cas d’étude (cf : section 3.2). Le code qui suit représente

la définition de l’intercepteur :

<bean id="MetricsProcessor" class="fr.upec.lacl.charif.migration.processor.metric"/>

<camelContext ...> <intercept>

<process ref="metricProcessor"> </intercept>

...

</camelContext>

Figure 5-3 Déclaration de l’intercepteur

L’intercepteur présenté en Figure 5-7 nous permet d’agréger des mesures suite à chaque étape de

notre agent d’orchestration, mais ne nous permet pas de les enregistrer dans un fichier afin de pouvoir

les exploiter ultérieurement. Pour remédier à cela, nous utilisons du concept « Complétion » qui est

une unité de travail s’activant par callback invoquée suite à la fin de l’échange. Ce concept peut être

associé soit à un échange particulier, soit de manière globale à la route. Nous définissions une balise

159

«

<onCompletion>

» de manière globale afin de déclencher l’enregistrement des métriques agrégées

par l’intercepteur dans un fichier de log comme illustré dans la Figure 5-4.

<bean id="MetricsWriterProcessor" class="fr.upec.lacl.charif.migration.processor.metric"/>

<camelContext ...> ...

<onCompletion>

<process ref="MetricsWriterProcessor"> </onCompletion>

...

</camelContext>

Figure 5-4 Déclaration de la complétion

Ce mécanisme fait donc plusieurs interceptions qu’il agrège avant d’utiliser la complétion pour

enregistrer le résultat dans un fichier.

Dans le document Orchestration d'agents mobiles en communauté (Page 157-160)