Blog ENI : Toute la veille numérique !
🐠 -25€ dès 75€ 
+ 7 jours d'accès à la Bibliothèque Numérique ENI. Cliquez ici
Accès illimité 24h/24 à tous nos livres & vidéos ! 
Découvrez la Bibliothèque Numérique ENI. Cliquez ici
  1. Livres et vidéos
  2. Java Spring
  3. Programmation réactive
Extrait - Java Spring Construisez vos applications réactives avec une architecture micro-services en environnement Jakarta EE (2e édition)
Extraits du livre
Java Spring Construisez vos applications réactives avec une architecture micro-services en environnement Jakarta EE (2e édition) Revenir à la page d'achat du livre

Programmation réactive

Introduction

L’histoire des applications réactives débute dans les années 1970, lorsque les premiers concepts de programmation fonctionnelle émergent. Cependant, ce n’est qu’à partir des années 1990 que l’idée de réactivité dans le contexte des applications informatiques commence à se développer. En 1997, la programmation réactive est introduite pour la première fois avec la publication du document "The Reactive Manifesto". Ce manifeste définit les principes fondamentaux de la programmation réactive, tels que la résilience, l’élasticité, l’extensibilité et la réactivité.

Au fil des années, de nombreux langages de programmation ont adopté des concepts de programmation fonctionnelle pour permettre le développement d’applications réactives. En 2004, Scala a été créé par Martin Odersky pour combiner les avantages de la programmation orientée objet et de la programmation fonctionnelle dans un seul langage. Ainsi, avec l’émergence des langages JVM plus puissants, tels que Groovy et Scala, dans les années 2000, les applications réactives ont trouvé un terrain propice pour se développer. En effet, ces langages offrent une facilité et une expressivité accrues pour...

Concepts clés de la programmation réactive

Les concepts-clés de la programmation réactive sont les suivants :

  • Réactivité : la réactivité est le principal concept de la programmation réactive. Cela signifie que le système est capable de répondre rapidement aux événements et aux requêtes, tout en maintenant une faible latence et en évitant les temps d’attente excessifs.

  • Résilience : la résilience se réfère à la capacité du système à rester stable et fonctionnel face à des conditions défavorables, telles que des erreurs, des pannes matérielles ou des pics de charge. Les applications réactives sont conçues pour gérer les erreurs de manière élégante et pour se rétablir rapidement en cas de défaillance.

  • Souplesse (elasticity) : la souplesse est la capacité d’un système à s’adapter dynamiquement à la demande en ajustant ses ressources en fonction de la charge de travail. Les applications réactives peuvent monter en puissance ou se réduire de manière transparente pour répondre aux fluctuations de la demande.

  • Orientés message (message-driven) : la programmation réactive repose sur le modèle de communication asynchrone basé...

Reactive Streams

1. Origines

ReactiveX (également connu sous le nom de Reactive Extensions) est une bibliothèque logicielle créée à l’origine par Microsoft, permettant aux langages de programmation impératifs de travailler sur des séquences de données de manière synchrone ou asynchrone. Elle offre un ensemble d’opérateurs de séquence qui agissent sur chaque élément de la séquence. Cette implémentation de la programmation réactive fournit un modèle pour créer des outils compatibles avec plusieurs langages de programmation. Autrement dit, ReactiveX est une API de programmation asynchrone basée sur des flux d’observations. Elle permet aux programmeurs d’appeler des fonctions et d’attendre leur exécution par le biais de rappels. Les flux d’observations sont similaires à des émetteurs d’événements, émettant des événements next, error et complete. Une fois qu’un flux émet un événement error ou complete, il cesse d’émettre des événements à moins d’être réabonné.

Les observateurs s’abonnent à des flux d’observations et reçoivent les éléments de manière asynchrone. ReactiveX combine les idées des motifs « observateur »...

Applications réactives sans Reactor

Il préexistait des solutions pour faire des applications Spring avant la sortie du framework Reactor avec des bibliothèques comme :

  • Akka/Akka Stream

  • RxJava version 1, 2 et 3 accompagné de Vert.x

1. Akka

Bien que ces écosystèmes soient utilisables avec Spring, ils ont leur écosystème propre et peuvent tout à fait être utilisés de façon autonome, sans Spring. C’est la même situation que les écosystèmes comme AWS et Quarkus. RxJava et Spring peuvent être utilisés ensemble, mais l’intégration est partielle. RxJava offre des fonctionnalités qui peuvent être utilisées dans Spring, mais l’intégration n’est pas complète. Reactor, quant à lui, offre une intégration complète avec Spring, de la couche d’exposition REST à la couche de stockage Akka.

Pour implémenter une application réactive qui fait, par exemple, de l’event sourcing, avec Akka, plusieurs briques et concepts peuvent être utilisés :

  • Acteurs (actors) : Akka repose sur le modèle d’acteurs, qui sont des entités concurrentes et autonomes. Chaque acteur traite les messages qui lui sont envoyés de manière séquentielle, ce qui permet de modéliser les événements de manière atomique.

  • Événements (events) : les événements sont les messages qui sont envoyés aux acteurs pour représenter les changements d’état dans le système. Dans le contexte de l’event sourcing, ces événements...

Fonctionnement de Reactor

Aujourd’hui, pour développer des applications réactives avec Spring, il est recommandé d’utiliser Reactor. Reactor est une bibliothèque de programmation fonctionnelle qui offre une intégration complète avec l’écosystème Spring.

Les sources sont consultables sur GitHub ici : https://github.com/reactor

1. En interne

En interne, Reactor Core utilise un moteur d’exécution fondé sur le modèle de machine à états finis pour gérer le flux de données et les opérations de transformation. Cela permet d’optimiser l’utilisation des ressources et d’assurer une exécution efficace des opérations asynchrones.

Son moteur d’exécution interne repose sur le modèle de machine à états finis (Finite State Machine, FSM) pour gérer le flux de données et les opérations de transformation de manière optimisée. Le flux de données est représenté comme une séquence d’états et les opérations de transformation sont représentées comme des transitions entre ces états. Chaque opération appliquée sur un Flux ou un Mono peut être considérée comme une transition d’un état à un autre.

En outre, grâce à ce modèle, les opérations asynchrones peuvent être exécutées de manière efficace et non bloquante. Le moteur d’exécution gère les transitions entre les états de manière asynchrone, permettant ainsi de traiter les flux de données de manière réactive, sans bloquer le fil d’exécution principal.

Reactor Core utilise une combinaison de listeners de messages et de schedulers en interne pour créer un environnement multitâche simulé grâce à une boucle de message. Lorsqu’une opération asynchrone est exécutée, elle émet un message qui est capté par un listener dédié. Ce listener traite le message...