19 mars 2018

Introduction à Vert.x, une librairie réactive

Regex : pourquoi il faut aimer les expressions régulières – Partie 1

Utilisée à la manière des outils de recherche de texte dans un document, une expression régulière, aussi dénommée « regex » ou « regexp », fournit un moyen concis et flexible pour la correspondance de chaînes de texte, tel que des caractères...

Algorithme Python : jouons avec les entiers

Nombre de problèmes mathématiques et les algorithmes associés tournent autour des entiers. Bien souvent ces algorithmes sont simples et accessibles à des développeurs débutants. PGCD Explications Le calcul du plus grand commun diviseur est un classique des...

Livret de stages – Invivoo

[dipi_breadcrumbs bc_custom_home="on" bc_home_text="Accueil" bc_home_url="https://www.invivoo.com" bc_home_icon="on" bc_home_color="#c7cce2" bc_separator_icon="%%3%%" bc_schema="on" bc_separator_color="#c7cbe1" bc_item_bg_color="rgba(0,0,0,0)"...

De JAVA 9 à JAVA 15 : Évolutions et nouveautés

Introduction : de Java 9 à Java 15 Utilisée par neuf millions de développeurs à plein temps, selon le dernier rapport d’IDC (International Data Corporation), Java reste un des langages le plus populaire et le plus utilisé dans le monde d’entreprise. En effet,...

Réussir mon entretien technique Java : Equals & Hashcode

Introduction Cet article, s’inscrivant dans la suite de la thématique « Réussir mon entretien technique en Java », traite de la redéfinition des méthodes « Equals » et « Hashcode » et de son impact sur la performance d’une application en...

Le Product Owner (3/3) : Son outillage pour construire un Backlog Produit efficace

Nous avons débuté cette série par un premier article qui définissait la culture produit en comparaison à la culture projet bien implantée dans l’industrie logicielle depuis de nombreuses décennies. Cet article a été l’occasion de vous montrer l’importance d’avoir une...

Le rôle du Product Owner (2/3) : Mais quelles sont réellement ses activités ?

Lors du dernier article nous avons fait la distinction entre la culture de développement dite Projet et celle dite Produit. Nous avons aussi pu introduire le cadre de travail Scrum (l’une des méthodes les plus adaptées pour la gestion de problèmes complexes et...

Le Product Owner (1/3) : Une introduction à la culture de développement et au rôle de PO

Lors du dernier article nous avons introduit l’agilité en essayant d’être didactique pour clarifier les possibles sources d’incompréhension sur ce sujet de Product Owner. Sur ce nouvel article, nous allons faire de même, en ciblant maintenant l’un des rôles...

Support utilisateurs dans le secteur bancaire

[dipi_breadcrumbs bc_custom_home="on" bc_home_text="Accueil" bc_home_url="https://www.invivoo.com" bc_home_icon="on" bc_home_color="#c7cce2" bc_separator_icon="%%3%%" bc_schema="on" bc_separator_color="#c7cbe1" bc_item_bg_color="rgba(0,0,0,0)"...

Justine Charon – Chargée de recrutement

Invivoo vit au travers de ses collaborateurs, c'est pourquoi nous avons voulu mettre en avant leurs expériences et leur donner la parole sur leur parcours et leur évolution chez nous. Les meilleurs ambassadeurs de l'entreprise sont les visages et les personnalités qui...

Initiation au TDD

[dipi_breadcrumbs bc_custom_home="on" bc_home_text="Accueil" bc_home_url="https://www.invivoo.com" bc_home_icon="on" bc_home_color="#c7cce2" bc_separator_icon="%%3%%" bc_schema="on" bc_separator_color="#c7cbe1" bc_item_bg_color="rgba(0,0,0,0)"...

Comment détecter des anomalies dans vos datasets grâce au Machine Learning

[dipi_breadcrumbs bc_custom_home="on" bc_home_text="Accueil" bc_home_url="https://www.invivoo.com" bc_home_icon="on" bc_home_color="#c7cce2" bc_separator_icon="%%3%%" bc_schema="on" bc_separator_color="#c7cbe1" bc_item_bg_color="rgba(0,0,0,0)"...

Envisagez Kafka dans votre architecture

[dipi_breadcrumbs bc_custom_home="on" bc_home_text="Accueil" bc_home_url="https://www.invivoo.com" bc_home_icon="on" bc_home_color="#c7cce2" bc_separator_icon="%%3%%" bc_schema="on" bc_separator_color="#c7cbe1" bc_item_bg_color="rgba(0,0,0,0)"...

Partager une vision centralisée sur la disponibilité des services applicatifs

[dipi_breadcrumbs bc_custom_home="on" bc_home_text="Accueil" bc_home_url="https://www.invivoo.com" bc_home_icon="on" bc_home_color="#c7cce2" bc_separator_icon="%%3%%" bc_schema="on" bc_separator_color="#c7cbe1" bc_item_bg_color="rgba(0,0,0,0)"...

Sonar Smash

[dipi_breadcrumbs bc_custom_home="on" bc_home_text="Accueil" bc_home_url="https://www.invivoo.com" bc_home_icon="on" bc_home_color="#c7cce2" bc_separator_icon="%%3%%" bc_schema="on" bc_separator_color="#c7cbe1" bc_item_bg_color="rgba(0,0,0,0)"...

Initiation au DevOps

[dipi_breadcrumbs bc_custom_home="on" bc_home_text="Accueil" bc_home_url="https://www.invivoo.com" bc_home_icon="on" bc_home_color="#c7cce2" bc_separator_icon="%%3%%" bc_schema="on" bc_separator_color="#c7cbe1" bc_item_bg_color="rgba(0,0,0,0)"...

Simplifiez le cheminement d’une RFQ

[dipi_breadcrumbs bc_custom_home="on" bc_home_text="Accueil" bc_home_url="https://www.invivoo.com" bc_home_icon="on" bc_home_color="#c7cce2" bc_separator_icon="%%3%%" bc_schema="on" bc_separator_color="#c7cbe1" bc_item_bg_color="rgba(0,0,0,0)"...

Documenter une API Springboot avec Swagger

[dipi_breadcrumbs bc_custom_home="on" bc_home_text="Accueil" bc_home_url="https://www.invivoo.com" bc_home_icon="on" bc_home_color="#c7cce2" bc_separator_icon="%%3%%" bc_schema="on" bc_separator_color="#c7cbe1" bc_item_bg_color="rgba(0,0,0,0)"...

PLATEFORME RISK & FINANCE

[dipi_breadcrumbs bc_custom_home="on" bc_home_text="Accueil" bc_home_url="https://www.invivoo.com" bc_home_icon="on" bc_home_color="#c7cce2" bc_separator_icon="%%3%%" bc_schema="on" bc_separator_color="#c7cbe1" bc_item_bg_color="rgba(0,0,0,0)"...

WORKFLOW DE CONTRÔLE DU PNL

[dipi_breadcrumbs bc_custom_home="on" bc_home_text="Accueil" bc_home_url="https://www.invivoo.com" bc_home_icon="on" bc_home_color="#c7cce2" bc_separator_icon="%%3%%" bc_schema="on" bc_separator_color="#c7cbe1" bc_item_bg_color="rgba(0,0,0,0)"...

TRANSFORMATION DE BATCHS

[dipi_breadcrumbs bc_custom_home="on" bc_home_text="Accueil" bc_home_url="https://www.invivoo.com" bc_home_icon="on" bc_home_color="#c7cce2" bc_separator_icon="%%3%%" bc_schema="on" bc_separator_color="#c7cbe1" bc_item_bg_color="rgba(0,0,0,0)"...

RISQUES DE CONTREPARTIE

[dipi_breadcrumbs bc_custom_home="on" bc_home_text="Accueil" bc_home_url="https://www.invivoo.com" bc_home_icon="on" bc_home_color="#c7cce2" bc_separator_icon="%%3%%" bc_schema="on" bc_separator_color="#c7cbe1" bc_item_bg_color="rgba(0,0,0,0)"...

VALUE AT RISK “Sign-Off”

[dipi_breadcrumbs bc_custom_home="on" bc_home_text="Accueil" bc_home_url="https://www.invivoo.com" bc_home_icon="on" bc_home_color="#c7cce2" bc_separator_icon="%%3%%" bc_schema="on" bc_separator_color="#c7cbe1" bc_item_bg_color="rgba(0,0,0,0)"...

Algorithme : définition & fonctionnement

Vouloir écrire des programmes c’est bien, mais garantir qu’ils fourniront le service attendu c’est mieux. Un programme est l’implémentation d’un algorithme dans un langage donné. Ne reste plus qu’à savoir ce qu’est un algorithme (définition)… Quelle est la définition...

Anouar Hassine – Développeur Sénior

Invivoo vit au travers de ses collaborateurs, c'est pourquoi nous avons voulu mettre en avant leurs expériences et leur donner la parole sur leur parcours et leur évolution chez nous. Les meilleurs ambassadeurs de l'entreprise sont les visages et les personnalités qui...

Cet article est le premier d’une série d’articles basée sur la présentation de l’université Applications réactives avec Eclipse Vert.x à laquelle j’ai assisté le 04/04/2017, première journée de l’édition 2017 de Devoxx France. L’université était présentée par Julien Viet(lead actuel du projet Vert.x) et Julien Ponge(contributeur du projet Vert.x).

Vert.x est un projet dont j’ai entendu parler durant une édition de Devoxx France il y a 3 ou 4 ans, et que j’ai découvert ensuite à travers une présentation de Devoxx France en 2015, dans une tools in action (présentation de 30mn). Si techniquement les concepts de la librairie étaient clairs, je n’arrivais cependant pas à résumer ce qu’elle était en une phrase. Mon intérêt récent pour l’approche des systèmes réactifs m’a amené à m’intéresser à Vert.x, qui se réclame être conforme à cette approche. Sous cet angle, Vert.x se résume en une phrase : une boîte à outils permettant de construire des systèmes réactifs. Cela sous-entend des cadres d’usage divers, aussi bien dans le domaine classique des applications d’entreprise que dans le domaine de l’embarqué, où l’outil propose un cadre simplifiant la construction d’applications réactives. Vert.x a aussi la spécificité d’être une librairie polyglotte, implémentée actuellement en Java, Javascript, Groovy, Ruby, Ceylon, Scala et Kotlin.

Vert.x étant décrit comme une boîte à outils pour la construction de systèmes réactifs, nous allons commencer par montrer à travers un exemple d’application Vert.x type Hello World ce que cela veut dire.

Rappel sur les systèmes réactifs d’après le manifeste

Le manifeste considère que les systèmes réactifs sont des systèmes qui répondent aux propriétés suivantes :

  • Disponibilité: capacité à répondre rapidement dans toutes circonstances.  Cela implique une capacité à détecter rapidement les erreurs et à les gérer.
  • Résilience: capacité du système à rester disponible en cas d’erreurs. La résilience peut être atteinte par la réplication des services, par la circonscription des effets des erreurs et la délégation des responsabilités.
  • Elasticité : capacité du système à rester disponible durant les variations de charge, par l’allocation ou la désallocation de ressources.
  • Orienté message: le caractère asynchrone de la communication par message renforce le cloisonnement entre les composants et favorise ainsi le découplage et la transparence de localisation.

Première version de Hello World

1 public class HelloWorld extends AbstractVerticle {
2 
3     @Override
4     public void start() {
5         vertx.createHttpServer().requestHandler(request -> request.response().end("Hello World!")).listen(8080);
6     }
Listing 1‑1 Serveur web HelloWorld avec Vert.x

Le listing 1.1 présente la plus simple version de l’application Hello World en Vert.x, un serveur HTTP qui répond en retournant le message « Hello World ! ».

Attardons-nous un instant sur ce code relativement simple mais qui comporte l’usage d’un des principaux éléments de Vert.x : les verticles. On reviendra aux verticles plus tard, pour l’instant il faut considérer les verticles comme les composants d’une application Vert.x, sujets à des cycles de vie contrôlés par Vert.x. Notre serveur devient donc un verticle en héritant simplement de la classe AbstractVerticle de Vert.x.

Notre application telle quelle est-elle réactive ?

  • Disponibilité : l’application étant un monolithe, une erreur est totale et ne donne aucune chance de réponse au client. Evidemment, l’exemple est tellement simple qu’on se demande qu’est-ce qui pourrait ne pas fonctionner dans cette application à part une erreur matérielle. Pour faciliter le raisonnement, imaginons que le message « Hello World ! » soit le résultat d’un appel potentiellement sujet à des erreurs, c’est souvent le cas dans la réalité.
  • Résilience: Encore une fois, l’aspect monolithique fait que l’erreur du système ne donne pas facilement la possibilité de contenir l’erreur à un certain endroit du système.
  • Elasticité : Lors de la variation des charges, c’est le nombre d’instances de l’application entière qui doit être augmenté ou diminué. Cela n’est pas optimal, car si c’est un service particulier qui est fortement sollicité, alors il est dommage de devoir déployer l’application entière juste pour répliquer ce service enfoui dans le monolithe.
  • Orienté message : l’application étant un monolithe, les composants sont fortement couplés et ainsi exposés mutuellement à leurs erreurs respectives.

Donc pour que notre système puisse être évalué comme étant réactif ou pas, nous voyons qu’on devrait commencer par le repartir en services distribués. Faisons donc cette répartition dans la prochaine étape.

Deuxième version de Hello World

Comme nous en avions évoqué la possibilité, supposons que le message « Hello World ! » soit fourni par un service, et faisons de ce service un composant à part, autrement-dit un autre verticle, exposant son interface à travers HTTP. Le serveur web va donc contacter ce service par un appel HTTP pour récupérer le message, et le retourner comme réponse à la requête reçue. Appelons donc le nouveau service GreetingService.

Par besoin de clarté on va présenter le code du nouveau service, mais c’est l’évolution du code du serveur initial qui doit retenir notre attention :

1 public class GreetingService extends AbstractVerticle {
2 
3     @Override
4     public void start() {
5 
6         vertx.createHttpServer().requestHandler(
7                 request -> request.response().end(new JsonObject().put("message", "Hello World!").encode())).listen(8081, "localhost");
8     }
9 }
Listing 1‑2 Nouveau service GreetingService

Et voici donc l’évolution du serveur HelloWolrd :

public class HelloWorld extends AbstractVerticle {
 2 
 3     @Override
 4     public void start() {
 5         WebClient client = WebClient.create(vertx);
 6         HttpRequest<JsonObject> httpRequest = client.get(8081, "localhost", "/").as(BodyCodec.jsonObject());
 7         vertx.createHttpServer().requestHandler(request -> {
 8             httpRequest.send(ar -> {
 9                 if (ar.succeeded()) {
10                     String message = ar.result().body().getString("message");
11                     request.response().end(message);
12                 } else {
13                     request.response().setStatusCode(500).end();
14                 }
15             });
16         }).listen(8080, "localhost");
17     }
18 }

Listing 1‑3 HelloWorld faisant appel à GreetingService Evaluons les propriétés de la nouvelle version de l’application :

  • Disponibilité : Nous notons une amélioration dans ce sens, car à présent en cas d’erreur de l’appel du GreetingService, un traitement explicite est effectué pour retourner le statut au client(ligne13). Cette gestion d’erreur reste améliorable cependant, nous ne sommes pas épargnés par des problèmes de timeout de l’appel par exemple qui impactent tout autant l’utilisateur.
  • Résilience: en cas d’erreur irrécupérable du GreetingService, nous n’avons malheureusement aucun moyen de rétablir un service normal pour l’utilisateur qui est condamné à recevoir la réponse de fallback. La résilience n’est donc pas vraiment atteinte.
  • Elasticité : à cause de la référence explicite de l’adresse du GreetingService (machine plus numéro de port), la réplication du service ne bénéficierait pas au serveur HelloWorld, en tout cas pas sans devoir passer par des outils extérieurs qui permettent de remplacer les références explicites par des noms logiques dans les systèmes distribués. Mais comme on le verra dans la 3eme et dernière version de notre application, un des principaux atouts de Vert.x est de permettre d’atteindre la résilience en utilisant directement les fonctionnalités natives de la librairie.
  • Orienté message : la communication entre les deux composants est certes asynchrone, mais le client a une référence explicite vers le serveur.

Nous allons donc procéder à une dernière évolution toujours dans le but de rendre l’application réactive.

Troisième et dernière version de Hello World

Le changement dans cette version va consister à utiliser une des principales fonctionnalités de Vert.x : l’event bus. L’event bus comme son nom l’indique est un bus de messagerie qui permet la communication orientée message avec les patterns que nous connaissons : publish-subscribe, point-to-point avec possibilité d’émission de réponse. L’event bus va surtout nous apporter la propriété de transparence de localisation, et cela aura les conséquences que nous allons bientôt évaluer. Pour l’instant, voici les codes des nouvelles versions des deux composants.

 

1 public class GreetingService extends AbstractVerticle {
 2 
 3     @Override
 4     public void start() {
 5         vertx.eventBus().consumer("GreetingService", message -> {
 6             JsonObject reply = new JsonObject().put("message", "Hello World!");
 7             message.reply(reply);
 8         });
 9     }
10 }
Listing 1‑4 GreetingService avec l'event bus
1 public class HelloWorld extends AbstractVerticle {
 2 
 3     @Override
 4     public void start() {
 5         vertx.createHttpServer().requestHandler(request -> {
 6             vertx.eventBus().<JsonObject>send("GreetingService", "", reply -> {
 7                 if (reply.succeeded()) {
 8                     String message = reply.result().body().getString("message");
 9                     request.response().end(message);
10                 } else {
11                     request.response().setStatusCode(500).end();
12                 }
13             });
14         }).listen(8080, "localhost");
15     }
16 }
Listing 1‑5 HelloWorld avec l'event bus

Pour envoyer ou consommer des messages sur l’event bus, il suffit de spécifier l’adresse virtuelle vers laquelle envoyer ou recevoir le message, et là réside une différence fondamentale par rapport à la communication HTTP basique qui exige l’indication d’une adresse physique. Dans notre exemple, le nom(arbitraire) de l’adresse utilisée est GreetingService par GreetingService et HelloWorld, pour envoyer des messages ou répondre aux messages reçus.

Evaluons à présent le degré de conformité de cette version de l’application aux propriétés des systèmes réactifs.

  • Disponibilité : l’introduction de l’event bus n’a pas vraiment amélioré directement la capacité de disponibilité de l’application.
  • Résilience : grâce à l’adresse virtuelle utilisée par la communication à travers l’event bus, la transparence de localisation est atteinte entre les deux composants, et par conséquent, en cas d’erreur irrécupérable du GreetingService, le message du serveur HelloWorld pourra être transmis à une autre instance du service, déjà existante ou créée sur l’occasion, pour continuer à fournir un service normal à l’utilisateur. La résilience est donc atteinte.
  • Elasticité: tout comme pour la résilience, la transparence de localisation permet de rendre l’application élastique. En cas de forte sollicitation, le GreetingService peut être répliqué, et Vert.x balancera dynamiquement les appels vers les différentes réplications. Cela devient possible par l’usage de l’adresse virtuelle utilisée dans la communication à travers l’event bus.
  • Orienté message : grâce à la communication asynchrone et l’adressage virtuelle, nous atteignons le niveau d’isolation souhaité entre les composants.

Cet exemple d’application a donc permis de voir à travers ses évolutions pourquoi Vert.x est considéré comme réactif. C’est parce qu’il fournit les fonctionnalités requises pour construire naturellement des applications répondant aux propriétés des systèmes réactifs.

Nous venons de voir que grâce à ses fonctionnalités Vert.x permet la construction de systèmes réactifs.

Pour comprendre les principes de bases sur lesquels repose Vert.x, cinq sujets essentiels seront abordés dans une série de 5 articles « Vert.x Basics » :

  • x Basics (1/5) : le modèle de concurrence
  • x Basics (2/5) : concurrence et scalabilité avec les verticles
  • x Basics (3/5) : haute disponibilité et failover
  • x Basics (4/5) : gestion des évènements asynchrones
  • x Basics (5/5) : l’event bus

Expertise Design & Code

$

Python, Java, C++, C# et Front-End

Découvrez nos formations

$

Parcourir le catalogue

Boostez votre carrière !

$

Nos offres pour Développeurs

Tous les mois recevez nos derniers articles !

Try X4B now !

Découvrez gratuitement XComponent for Business. Notre solution logicielle BizDevOps !

Écrit par Grow Together

0 Comments

Submit a Comment

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *