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é
MetricsProcessorqui
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 :
–
interceptqui intercepte chaque étape de traitement durant le routage d'un échange dans une
route.
–
interceptFromqui intercepte l’échange entrant dans la route.
–
interceptSendToEndpointqui 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