MAJ du 30/04/2017, la vidéo de la conférence Vertx du Devoxx 2017 étant disponible, en voici le lien:

La conférence Vertx

Après avoir entendu (lu) beaucoup de bien concernant Vertx, j’ai profité du Devoxx 2017 pour m’y intéresser et assister à l’université “Applications réactives avec Eclipse Vert.x”, présentée par Julien Ponge et Julien Viet, tous deux contributeurs sur le projet Vertx. Le format de la présentation était intéressant, de la théorie bien-sûr, quelques exemples et surtout une démo très sympa: chaque personne de l’assistance avait la possibilité de déclencher des sons via une interface web accessible sur nos téléphones, vers un logiciel de MAO (dont le nom m’échappe). Pour cela ils avaient mappé l’interface midi du logiciel sur une application Vert.x, qui réceptionnait de façon asynchrone les différents événements (ici les demandes de son) et les envoyait ensuite au logiciel en question. Enfin, deux intervenants ont présenté succinctement les possibilités offertes par le framework pour les projets IoT.

Alors, qu’est-ce que Vertx ?

Vert.x (qui se prononce « Vertex ») est un Framework backend, événementiel et non bloquant. Il s’agit d’une implémentation du design pattern reactor, créé pour permettre le traitement d’événements dans un environnement concurrentiel. Il est proche du pattern Observer, mais contrairement à celui-ci peut supporter différentes sources d’événements. Vert.x a été inspiré initialement par Node.js et se veut être très facilement scalable. Précisons de plus qu’il est open Source sous « Apache Software License 2.0″ et « Eclipse Public License ».

Le framework a de nombreuses caractéristiques mais on pourrait retenir en particulier celles-ci:

• La simplicité avec laquelle on peut mettre en place une API asynchrone
• La gestion de la concurrence basée sur le model Actor
• Polyglotte, il peut être utilisé avec différents langages, comme Java , Javascript, Python, Scala, Kotlin, Ruby…
• Scalable via la création de nouvelles instances de nos verticles

Il s’appuie sur le framework asynchrone Netty, afin de gérer les entrées / sorties (NIO), et offre donc de nombreuses possibilités de communication (Http, WebSocket, TCP, UDP, RTSP, protocoles binaires). Avec Vert.x on change complètement de paradigme et d’architecture par rapport à du JEE “classique”, et le prix d’entrée peut-être important.

Quelques concepts fondamentaux dans Vertx

Les Verticles “A verticle is a piece of code that can be deployed by Vert.x”
L’implémentation de l’interface “Verticle” permet de bénéficier aisément d’un modèle de déploiement et de gestion de la concurrence du type “Actor”. Typiquement, une application Vert.x s’appuyant sur ce composant aura plusieurs instances de “Verticle” dans chaque instance Vert.x. Ceux-ci pourront communiquer de façon asynchrone via un “EventBus”.

L’EventBus
L’EventBus est un système de distribution de message entre les différents composants d’une application ou entre différentes applications et services, ce qui permet un très faible couplage. La gestion des messages peut-être faîte en point-à-point, par requête/réponse ou en “publish/subscribe”. A noter qu’il n’y a pas de garantie de réception sur les messages envoyés, contrairement à du JMS par exemple.

L’EventLoop
Dans notre application Vert.x, un event loop (cf. pattern reactor) est exécuté afin de distribuer les “events” aux différents verticles (“handlers”). Mais contrairement à Node.js, chaque instance Vert.x peut lancer plusieurs event loop, on parlera dans ce cas de multi-reactor pattern. On pourra donc bénéficier de la puissance des processeurs multi-cores, et afin d’éviter une exécution concurrente des handlers, chacun d’eux ne pourra être appelé que par une event loop.

En gros ça donne ça:

NB. Dans le cas ou l’on souhaiterait upscaler notre application, d’après ce que j’en ai compris, il suffirait de multiplier les JVM et les machines avec un Event Bus partagé.

Autres aspects intéressants, en vrac:

TCP EventBus Bridge
Avec Vert.x on a également la possibilité d’utiliser un TCP EventBus Bridge, qui nous permettra de communiquer de façon asynchrone avec d’autres applications capables de créer des sockets TCP.

Worker verticles et WorkerThreadPool
Un Worker verticle est un verticle qui ne sera pas exécuté avec une Event Loop mais avec un thread provenant du worker thread pool. L’intérêt de ce mode de fonctionnement est de pouvoir appeler un tier bloquant (blocking I/O) sans risquer de bloquer une Event Loop et en préservant l’aspect asynchrone..

Le déploiement: l’ensemble de notre application et ses dépendances sera contenu dans un “fat-jar” qui n’aura donc besoin que de la JVM pour s’exécuter.

Fail over et haute disponibilité
On a la possibilité de lancer plusieurs instances d’un verticle avec l’option “-ha” (high availability) et le nom du groupe (“hagroup”). Ainsi, lorsqu’une instance sera en échec, une autre instance du même groupe prendra le relais. Nous en avons eu une démo “live” pendant la présentation.

Reactive Streams
Vert.x embarque une implémentation des reactive streams. Ceci permettra donc de gérer de façon asynchrone les streams et de gérer de façon non bloquante les effets de back pressure sur la JVM.

RxJava
Dans la mesure où l’on souhaiterait gérer plusieurs événements avec un point d’entrée, nous avons la possibilité d’utiliser RxJava via une “Rxified” API, io.vertx.rxjava.

Hazelcast : in-memory data grid
Vert.x s’appuie sur Hazelcast afin de permettre le partage de datas entre différentes instances de l’application.

Mon sentiment concernant Vertx et la conférence

Je me rends bien compte d’avoir à peine gratté la surface ici. Il y a encore beaucoup de questions auxquelles j’aimerais répondre et notamment me faire une idée plus précise des cas d’usages où Vert.x serait le plus pertinent. La présentation qui en a été faite lors du Devoxx 2017 était très intéressante et vraiment bien animée, et cela m’a vraiment donné envie d’approfondir un peu plus l’exploration du framework et de m’amuser à en tester les possibilités. Enfin, il me semble que les cas d’usage les plus évidents de Vert.x sont plutôt tournés vers les besoins de hautes performances, de concurrences et de scalabilité. Le framework devrait a priori exceller pour faire de l’IoT, des applications de streaming ou des applications mobiles sollicitant fortement le backend. D’ailleurs, il serait intéressant de faire une comparaison point-à-point entre des solutions comme Akka, Vertx, Node.js etc.

Pour finir

Un bon point d’entrée pour s’amuser un peu à faire sa première application Vert.x est sur le site qui lui est consacré:
http://vertx.io/blog/my-first-vert-x-3-application/.

Et pour aller plus loin:

http://www.cubrid.org/blog/dev-platform/understanding-vertx-architecture-part-2/

https://medium.com/inmoodforlife/vert-x-the-perfect-reactor-for-iot-devices-5d0b3cb36a98

http://vertx.io/docs/