CHAPITRE 5 : Résultats et mesures
3.3 Implantation
La démarche d’implantation que nous avons suivie est celle que nous avons déjà décrite dans la section
3 du chapitre 2 qui décrit la transformation entre PIM et le PSM. Nous avons suivi les trois étapes de
transformation en partant des quatre équations (5-1), (5-2), (5-3) et (5-4) qui représentent les
spécifications π-DSL de notre scénario. Nous avons utilisé l’outil Pi2Camel afin de générer un squelette
en Camel ce qui représente le premier niveau de transformation. Nous avons ensuite implanté les trois
processeurs pour obtenir le deuxième niveau de PSM. Nous illustrons dans le code qui suit
l’enrichissement du processeur 𝐴𝑔𝑔𝑟𝑒𝑔𝑎𝑡𝑖𝑜𝑛𝑃𝑟𝑜𝑐𝑒𝑠𝑠𝑜𝑟 (cf : Figure 5-8) que nous jugeons intéressant
car il montre l’ajout du résultat de l’appel du premier partenaire au contexte d’orchestration et
configure l’échange sortant pour faire appel au deuxième partenaire.
package fr.upec.lacl.charif.comparator.orchestrator.flight;
import org.apache.camel.Exchange;
...
public class AggregationProcessor implements Processor { @Override
public void process(Exchange exchange) throws Exception {
OutputFlightDetails out = exchange.getIn().getBody(OutputFlightDetails.class);
exchange.setProperty("Price1", Long.valueOf(out.getPrice()));
InputFlightDetails details = new InputFlightDetails("source", "dest", "date", exchange.getProperty("MIG_NumberPassagers", Integer.class));
exchange.getIn().setHeader(CxfConstants.OPERATION_NAME, "flightInfo"); exchange.getIn().setHeader(CxfConstants.OPERATION_NAMESPACE,
"http://flight.srv1.comparator.charif.lacl.upec.fr/");
exchange.getIn().setBody(details); }
}
163
Dans ce deuxième niveau du PSM, nous rajoutons aussi l’interface Java ainsi que les POJOs
InputFlightDetails
et
OutputFlightDetailsqui sont utilisés par le framework CXF afin de générer le
web service exposé par l’agent d’orchestration. Nous remarquons que les deux POJOs sont utilisés
dans le processeur
AggregationProcessorafin de manipuler des données émises et reçues depuis les
services partenaires. Le code Figure 5-9 illustre l’interface Java que nous utilisons comme signature du
web service.
package fr.upec.lacl.charif.comparator.orchestrator.flight; public interface OrchestratorService {
public OutputFlightDetails flightOrch(InputFlightDetails in); }
Figure 5-9 Illustration de l’interface « OrchestratorService »
A ce stade, nous disposons de toutes les classes et interfaces Java nécessaires pour l’implantation de
notre cas d’utilisation. La dernière étape de notre implantation consiste à intégrer ce code Java à la
configuration Camel XML comme nous l’avons décrit dans le troisième niveau du PSM dans la section
4.4 du chapitre 2.
Après son enrichissement, cette implantation est packagée en utilisant le plug-in Maven tel que nous
l’avons décrit dans la section 5.1 du chapitre 2. Le déploiement de l’agent d’orchestration sur notre
environnement de test (cf : section 2.2) est fait suivant la méthode décrite dans la section 5.2 du
chapitre 2.
Cependant, cette implantation ne couvre pas la partie client et les services. Pour couvrir ce manque,
nous avons implanté les services en utilisant deux technologies différentes. Le service « Service1 » (qui
représente le premier partenaire) est développé avec le framework CXF et apache Camel. Le code
Figure 5-10 illustre la définition du service CXF ainsi que le contexte Camel qui permet sa mise en
œuvre.
<?xml version="1.0" encoding="UTF-8"?> <blueprint ...>
<cxf:cxfEndpoint id="compareEndpoint" address="/compare/"
serviceClass="fr.upec.lacl.charif.comparator.srv1.flight.FlightService" /> <bean id="flightProcessor"
class="fr.upec.lacl.charif.comparator.srv1.flight.FlightProcessor" />
<camelContext xmlns="http://camel.apache.org/schema/blueprint"> <route id="cxf">
<from uri="cxf:bean:compareEndpoint" /> <recipientList>
<simple>direct:${header.operationName}</simple> </recipientList>
</route>
<route id="compare">
<from uri="direct:flightInfo"/> <log message="compareEndpoint Call"/> <process ref="flightProcessor"/> <to uri="log:output" />
</route> </camelContext> </blueprint>
164
Le deuxième service « Service2 » est développé comme Mock avec l’outil SoapUI nommé
«
FlightService-Mock-soapui-project.xml». Nous avons opté pour cette solution afin de souligner
l’interopérabilité de notre approche. Afin de pouvoir générer des retours dynamiques pour le service
SoapUI, nous avons défini un script Groovy qui permet de générer des nombres aléatoires que nous
assignons à une propriété nommé
randomPricecomme illustré dans le code Figure 5-11.
context.setProperty( "randomPrice", Math.random() )
Figure 5-11 Valorisation aléatoire des propriétés
Nous avons configuré le retour du service SoapUI afin de retourner une nouvelle valeur aléatoire
générée suite à chaque invocation tel illustré dans le playload de retour dynamique dans la Figure 5-12.
Ce payload est ajouté au projet Mock «
FlightService-Mock-soapui-project.xml». afin qu’il soit
retourné par ce dernier.
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:flig="http://flight.srv1.comparator.charif.lacl.upec.fr/"> <soapenv:Header/> <soapenv:Body> <flig:flightInfoResponse> <return> <code>SOAPSERVICE</code> <price>${randomPrice}</price> </return> </flig:flightInfoResponse> </soapenv:Body> </soapenv:Envelope>
Figure 5-12 Payload de retour dynamique
SoapUI substitue la variable
${randomPrice}par la valeur de la propriété valorisée par le script Groovy
de génération de valeurs aléatoires.
Le client est généré en utilisant SoapUI comme un nouveau projet à base du descripteur WSDL de
l’agent d’orchestration. Grâce à ce projet, nous disposons d’un squelette de requête tel qu’illustré dans
le code Figure 5-13.
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:flig="http://flight.orchestrator.comparator.charif.lacl.upec.fr/"> <soapenv:Header/> <soapenv:Body> <flig:flightOrch> <!--Optional:--> <arg0> <!--Optional:--> <date>?</date> <!--Optional:--> <dest>?</dest> <numberPassagers>?</numberPassagers> <!--Optional:--> <source>?</source> </arg0> </flig:flightOrch> </soapenv:Body> </soapenv:Envelope>
Figure 5-13 Squelette du payload d’invocation