La première version a été écrite par Rod Johnson , qui a publié le framework avec son livre Expert One-on-One J2EE Design and Development en octobre 2002. Le framework a été initialement publié sous la licence Apache 2.0 en juin 2003. La première version de production, la 1.0, est sortie en mars 2004. Le framework Spring 1.2.6 a remporté un prix Jolt de productivité et un Groovy 2, certains aspects de Java EE 7 et WebSocket .
Spring Framework 4.2.0 a été publié le 31 juillet 2015 et a été immédiatement mis à niveau vers la version 4.2.1, publiée le 1er septembre 2015. Il est « compatible avec Java 6, 7 et 8, et met l'accent sur les améliorations du noyau et les fonctionnalités web modernes » .
Spring Framework 4.3 a été publié le 10 juin 2016 et a été pris en charge jusqu'en 2020. Il a été annoncé comme « la dernière génération répondant aux exigences système générales de Spring 4 (Java 6+, Servlet 2.5+), [...] » .
Spring 5 a été construit sur Reactor Core compatible avec Reactive Streams . APIjakarta Jakarta EE 10 récemment publiées telles que Servlet 6.0 et JPA 3.1.
Modules
Le framework Spring comprend plusieurs modules qui fournissent une gamme de services :
- Spring Core Container : il s’agit du module de base de Spring et il fournit les conteneurs Spring (
BeanFactoryetApplicationContext). Dans ce contexte,spring-coreest l’artefact présent dans le module principal et appartenant auorg.springframeworkgroupe. Cetspring-coreartefact comprend le conteneur IoC, ainsi que les classes utilitaires utilisées dans toute l’application. - Programmation orientée aspect : permet la mise en œuvre de préoccupations transversales . Il
spring-aops’agit d’un artefact du framework AOP. - Authentification et autorisation : processus de sécurité configurables prenant en charge un large éventail de normes, de protocoles, d’outils et de pratiques via le sous-projet Spring Security (anciennement Acegi Security System for Spring).
- Convention plutôt que configuration : le module Spring Roo propose une solution de développement rapide d’applications pour les applications d’entreprise basées sur Spring .
- Accès aux données : utilisation des systèmes de gestion de bases de données relationnelles sur la plateforme Java via Java Database Connectivity (JDBC) et les outils de mappage objet-relationnel, ainsi qu’avec les bases de données NoSQL . Il
spring-jdbcs’agit d’un artefact du module JDBC qui prend en charge l’accès JDBC en incluant des classes de configuration de source de données. - Conteneur d'inversion de contrôle : configuration des composants de l'application et gestion du cycle de vie des objets Java, principalement via l'injection de dépendances .
- Messagerie : enregistrement déclaratif d’objets d’écoute de messages pour une consommation transparente des messages provenant de files d’attente de messages via Java Message Service (JMS), amélioration de l’envoi de messages par rapport aux API JMS standard.
- Modèle-vue-contrôleur : un framework basé sur HTTP et les servlets fournissant des points d’extension et de personnalisation pour les applications Web et les services Web RESTful (transfert d’état représentationnel).
- Cadre d'accès à distance : sérialisation déclarative CORBA ( Common Object Broker Architecture protocoles basés sur HTTP y compris les services Web tels que SOAP (Simple Object Access Protocol) .
- Gestion des transactions : unifie plusieurs API de gestion des transactions et coordonne les transactions pour les objets Java.
- Gestion à distance : exposition et gestion déclaratives d’objets Java pour une configuration locale ou à distance via Java Management Extensions (JMX).
- Tests : classes de support pour l'écriture de tests unitaires et de tests d'intégration .
- Prise en charge de WebFlux : prise en charge de l’utilisation d’environnements d’exécution réactifs ou de serveurs Web tels que UnderTow et Netty .
- Prise en charge des WebSockets : prise en charge de la communication via le protocole WebSocket. L’artefact correspondant à ce module est
spring-websocket. - Prise en charge XML : prise en charge du mappage objet-XML. Les bibliothèques telles que Jakarta XML Binding (JAXB) et XStream sont prises en charge. L’artefact de ce module est
spring-oxm.
Les modules Spring sont conditionnés sous forme de fichiers JAR. Ces artefacts sont accessibles via le dépôt central Maven à l'aide de Maven ou de Gradle .
Inversion du conteneur de contrôle
Le conteneur d'inversion de contrôle (IoC) est le conteneur principal du framework Spring. Il fournit un moyen cohérent de configurer et de gérer les objets Java à l'aide de la réflexion . Le conteneur est responsable de la gestion du cycle de vie des objets : la création de ces objets, l'appel de leurs méthodes d'initialisation , et la configuration de ces objets en les reliant entre eux.
Dans de nombreux cas, l'utilisation du conteneur n'est pas nécessaire lorsqu'on utilise d'autres composants du framework Spring, bien qu'elle facilite généralement la configuration et la personnalisation de l'application. Le conteneur Spring offre un mécanisme cohérent pour la configuration des applications et s'intègre à la quasi-totalité des environnements Java, des applications de petite taille aux grandes applications d'entreprise.
Le programmeur ne crée pas directement l'objet, mais décrit comment il doit être créé en le définissant dans le fichier de configuration Spring. De même, les services et les composants ne sont pas appelés directement ; c'est le fichier de configuration Spring qui définit quels services et composants doivent être appelés. Ce mécanisme d'injection de dépendances (IoC) vise à simplifier la maintenance et les tests.
Création et gestion de beans
Les objets créés par le conteneur sont appelés objets gérés ou beans . Le conteneur peut être configuré en chargeant des fichiers XML (Extensible Markup Language) ou en détectant des annotations Java spécifiques sur les classes de configuration. Ces sources de données contiennent les définitions de beans qui fournissent les informations nécessaires à la création des beans.
Il constructeurs , des propriétés ou des méthodes de fabrique . Il existe plusieurs façons d’implémenter l’injection de dépendances : l’injection de dépendances par constructeur, l’injection de dépendances par setter et l’injection de dépendances par champ.
Recherche de dépendance
La recherche de dépendances est un modèle dans lequel un appelant demande à l'objet conteneur un objet ayant un nom spécifique ou un type spécifique.
Câblage automobile
Le framework Spring possède une fonctionnalité appelée autowiring, qui utilise le conteneur Spring pour satisfaire automatiquement les dépendances spécifiées dans les propriétés JavaBean aux objets du type approprié dans la fabrique actuelle. Cela n'est possible que s'il n'existe qu'un seul objet du type approprié.
Il existe plusieurs annotations qui peuvent être utilisées pour l'injection automatique de POJO, y compris l'annotation spécifique à Spring JSR 250 , ou Common Annotations for the Java Platform, et est utilisée pour l'injection automatique de références aux POJO par nom .
L' de programmation orientée aspect (AOP) qui modularise les problématiques transversales au sein d'aspects . La création d'un framework AOP distinct vise à fournir des fonctionnalités AOP de base sans complexifier excessivement la conception, l'implémentation ou la configuration. Le framework AOP de Spring tire pleinement parti du conteneur Spring.
Le framework Spring AOP est basé sur le modèle proxy . Il est configuré à l'exécution . Cela élimine le besoin d'une étape de compilation ou d'un tissage au chargement. En revanche, l'interception n'autorise l'exécution de méthodes publiques que sur les objets existants à un point de jonction .AspectJ , Spring AOP est moins puissant, mais aussi moins complexe. Spring 1.2 permet de configurer les aspects AspectJ dans le conteneur. Spring 2.0 a renforcé l'intégration avec AspectJ ; par exemple, le langage de pointcut est réutilisé et peut être combiné avec les aspects basés sur Spring AOP. De plus, Spring 2.0 a introduit la bibliothèque Spring Aspects, qui utilise AspectJ pour offrir des fonctionnalités Spring courantes telles que la gestion déclarative des transactions et l'injection de dépendances via le tissage AspectJ à la compilation ou au chargement . SpringSource utilise AspectJ AOP dans d'autres projets Spring comme Spring Roo et Spring Insight, tandis que Spring Security propose une bibliothèque d'aspects basée sur AspectJ.xmlns:mvc= "http://www.springframework.org/schema/mvc" xmlns:xsi= "http://www.w3.org/2001/XMLSchema-instance" xmlns:aop= "http://www.springframework.org/schema/aop" xmlns:context= "http://www.springframework.org/schema/context" xsi:schemaLocation= "http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd http://www.springframework.org/schema/context http://www.springframework.org/schema/context/spring-context.xsd http://www.springframework.org/schema/mvc http://www.springframework.org/schema/mvc/spring-mvc.xsd http://www.springframework.org/schema/aop http://www.springframework.org/schema/aop/spring-aop.xsd" >
L'équipe Spring a décidé de ne pas introduire de nouvelle terminologie liée à la programmation orientée aspect (AOP). Par conséquent, dans la documentation de référence et l'API de Spring, des termes tels que aspect , point de jonction, conseil , point de coupure, introduction, iBatis / MyBatis , Hibernate , Java Data Objects (JDO, abandonné depuis la version 5.x), Jakarta Persistence API (JPA), Oracle TopLink , Apache OJB et Apache Cayenne , entre autres.
Pour tous ces frameworks pris en charge, Spring fournit ces fonctionnalités
- Gestion des ressources – acquisition et libération automatiques des ressources de base de données
- Gestion des exceptions – traduction des exceptions liées à l’accès aux données en une hiérarchie d’accès aux données Spring
- Participation aux transactions – participation transparente aux transactions en cours
- Déballage des ressources – récupération des objets de base de données à partir des wrappers du pool de connexions
- Abstraction pour la gestion des objets binaires volumineux (BLOB) et des objets caractères volumineux (CLOB).
Toutes ces fonctionnalités sont disponibles grâce aux classes modèles fournies par Spring pour chaque framework pris en charge. Certains critiques estiment que ces classes modèles sont intrusives et n'offrent aucun avantage par rapport à l'utilisation directe de l'API Hibernate, par exemple. En réponse, les développeurs de Spring ont rendu possible l'utilisation directe des API Hibernate et JPA. Cependant, cette approche requiert une gestion transparente des transactions, car le code applicatif n'assume plus la responsabilité de l'acquisition et de la libération des ressources de la base de données, et ne prend pas en charge la traduction des exceptions. Datasourcecomme com.mchange.v2.c3p0.ComboPooledDataSourceou org.apache.commons.dbcp.BasicDataSource
SessionFactorylike org.springframework.orm.hibernate3.LocalSessionFactoryBeanavec un DataSourceattribut HibernateProperties J'aimeorg.springframework.beans.factory.config.PropertiesFactoryBeanTransactionManagerj'aime org.springframework.orm.hibernate3.HibernateTransactionManageravec un SessionFactoryattribut Les autres points de configuration comprennent :
- Configuration AOP des points de coupe.
- des transactions locales et globales (une transaction locale ne nécessite pas de serveur d'applications )
- travailler avec des transactions imbriquées
- travailler avec les points de sauvegarde
- fonctionnant dans presque tous les environnements de la plateforme Java
En comparaison, l'API de transactions Java (JTA) ne prend en charge que les transactions imbriquées et les transactions globales, et nécessite un serveur d'applications (et dans certains cas, le déploiement d'applications sur un serveur d'applications).
Le framework Spring fournit un PlatformTransactionManager pour un certain nombre de stratégies de gestion des transactions :
- Transactions gérées sur une connexion JDBC
- Transactions gérées sur des unités de travail de mappage objet-relationnel
- Transactions gérées via le JTA
JtaTransactionManageretUserTransaction - Les transactions sont gérées sur d'autres ressources, comme les bases de données d'objets.
Outre ce mécanisme d'abstraction, le framework propose deux manières d'ajouter la gestion des transactions aux applications :
- De manière procédurale, en utilisant Spring
TransactionTemplate - De manière déclarative, en utilisant des métadonnées telles que des annotations XML ou Java (
@Transactional, etc.)
Grâce au framework d'accès aux données de Spring , qui intègre le framework de gestion des transactions , il est possible de configurer un système transactionnel sans avoir recours à JTA ou EJB . Ce framework transactionnel s'intègre également aux moteurs de messagerie et de mise en cache .
Cadre Modèle-Vue-Contrôleur

Le framework Spring intègre son propre framework d'application web MVC ( Modèle-Vue-Contrôleur ) , ce qui n'était pas prévu initialement. Les développeurs de Spring ont décidé de créer leur propre framework web en réaction à ce qu'ils considéraient comme la conception médiocre du framework web Jakarta Struts , alors très populaire , ainsi qu'aux lacunes d'autres frameworks disponibles. Ils estimaient notamment que la séparation entre les couches de présentation et de gestion des requêtes était insuffisante, de même qu'entre la couche de gestion des requêtes et le modèle de stratégie pour toutes les responsabilités inhérentes à un framework moderne orienté requêtes. Chaque interface se veut simple et claire, permettant ainsi aux utilisateurs de Spring MVC d'implémenter facilement leurs propres solutions, s'ils le souhaitent. MVC favorise un code front-end plus propre. Toutes les interfaces sont étroitement liées à l' API Servlet . Certains considèrent cette forte dépendance à l'API Servlet comme un échec des développeurs Spring, qui n'ont pas su offrir un niveau d'abstraction suffisamment élevé pour les applications web . Cependant, cette dépendance garantit la disponibilité des fonctionnalités de l'API Servlet pour les développeurs, tout en offrant un framework d'abstraction élevé facilitant son utilisation.contrôleur frontal du framework et est responsable de la délégation du contrôle aux différentes interfaces pendant les phases d'exécution d'une requête HTTP .
Les interfaces les plus importantes définies par Spring MVC, ainsi que leurs responsabilités, sont listées ci-dessous :
Controller: intervient entreModeletViewpour gérer les requêtes entrantes et les rediriger vers la réponse appropriée.ControllerIl associe la requête HTTP aux méthodes correspondantes. Il agit comme une porte qui dirige les informations entrantes. Il bascule entre l'entréeModelou la sortieView.HandlerAdapter: responsable de l'exécution des objets qui traitent les requêtes entrantes.HandlerInterceptor: responsable de l'interception des requêtes entrantes. Comparable, mais non égal aux filtres Servlet (l'utilisation est facultative et n'est pas contrôlée parDispatcherServlet).HandlerMapping: responsable de la sélection des objets qui traitent les requêtes entrantes (gestionnaires) en fonction de tout attribut ou condition interne ou externe à ces requêtesLocaleResolver: responsable de la résolution et, éventuellement, de l'enregistrement des paramètres régionaux d'un utilisateur individuel.MultipartResolver: faciliter le traitement des téléchargements de fichiers en encapsulant les requêtes entrantes.View: responsable du renvoi d'une réponse au client. Cette fonctionViewne doit contenir aucune logique métier et doit uniquement présenter les données encapsulées par le composantModel. Certaines requêtes peuvent y accéder directementViewsans passer par laModelpartie correspondante ; d'autres peuvent passer par les trois.ViewResolver: responsable de la sélection d'unViewen fonction d'un nom logique pour leView(l'utilisation n'est pas strictement requise ).Model: responsable de l'encapsulation des données métier. L'objetModelest exposé à la vue par le contrôleur. (son utilisation n'est pas strictement requise).
Chaque interface de stratégie mentionnée ci-dessus joue un rôle important dans le cadre global. Les abstractions qu'elles offrent sont puissantes, permettant ainsi une grande variété d'implémentations. Spring MVC intègre des implémentations de toutes ces interfaces et propose un ensemble de fonctionnalités s'appuyant sur l'API Servlet. Cependant, les développeurs et les fournisseurs sont libres de créer leurs propres implémentations. Spring MVC utilise l' frontal Spring MVC. DispatcherServlet[ contrôleur est hautement personnalisable et flexible. Plus précisément, il est capable de gérer davantage de types de gestionnaires que n'importe quelle implémentation de classes annotées. [94] Il consulte un ou plusieurs mappages de gestionnaires. Il choisit un contrôleur approprié et lui transmet la requête. Le contrôleur frontal traite la requête et génère un résultat. Ce résultat est appelé « resultat ». être formatées en HTML ou avec une technologie front-end comme Jakarta Server Pages (JSP) ou Thymeleaf . Il s'agit du « resultat » de l'application. Toutes les informations sont stockées dans l' objet « resultat » et l'objet « resultat » . Lorsque le contrôleur n'est pas associé à une vue particulière, le contrôleur frontal trouve la vue correspondante (par exemple, une JSP) à l'aide de la méthode ` getResult` . DispatcherServletDispatcherServletorg. springframework.web.servlet.mvc.Controllerorg. springframework.stereotype.ControllerDispatcherServletControllerModelViewModelViewDispatcherServletViewViewResolver
Configuration du DispatcherServlet
À partir de la version 3.0 de la spécification Servlet, il existe plusieurs façons de configurer le DispatcherServlet :
- En le configurant
web.xmlcomme indiqué ci-dessous :
cadre d'accès à distance
Le framework d'accès distant de Spring est une abstraction permettant d'utiliser diverses technologies basées sur les RPC ( appels de procédure distante ) disponibles sur la plateforme Java, tant pour la connectivité client que pour la sérialisation d'objets sur les serveurs. Sa principale caractéristique est de simplifier au maximum la configuration et l'utilisation de ces technologies en combinant l'inversion de contrôle et la programmation orientée aspect (AOP).
Le framework assure la récupération en cas de panne (reconnexion automatique après une panne de connexion) et certaines optimisations pour l'utilisation côté client des beans de session sans état distants EJB .
Spring prend en charge ces protocoles et produits nativement.
- Protocoles basés sur HTTP
- Hessian : protocole de sérialisation binaire, , open source et maintenu par des protocoles basés sur CORBA . Hessian est maintenu par la société Caucho . Hessian convient aux besoins de communication à distance sans état, en particulier pour la communication Java-à-Java.
- Burlap : Protocole binaire basé sur XML , open source et maintenu par la société Caucho . Le seul avantage de Burlap par rapport à Hessian est sa compatibilité avec l’analyse XML et sa lisibilité par l’humain . Pour la communication Java-Java, Hessian est préféré car plus léger et plus efficace.
- RMI (1) : appels de méthode utilisant l'infrastructure RMI mais spécifique à Spring
- RMI (2) : appels de méthode utilisant des interfaces RMI conformes à l'utilisation RMI régulière
- RMI-IIOP ( CORBA ) : appels de méthodes utilisant RMI-IIOP/CORBA
- Intégration du client Enterprise JavaBean
- Connectivité locale aux beans de session sans état EJB : connexion aux beans de session sans état locaux
- Connectivité aux beans de session sans état EJB distants : connexion aux beans de session sans état distants
- SAVON
- Intégration avec le framework de services Web Apache Axis
Apache CXF assure l'intégration avec le framework Spring pour l'exportation d'objets côté serveur selon le style RPC.
La configuration du client et du serveur pour tous les protocoles et produits de type RPC pris en charge par le framework d'accès distant Spring (à l'exception de la prise en charge d'Apache Axis) est effectuée dans le conteneur Spring Core.
Il existe une implémentation open-source alternative (Cluster4Spring) d'un sous-système de communication à distance inclus dans le framework Spring, destiné à prendre en charge différents schémas de communication à distance (1-1, 1-plusieurs, découverte dynamique de services).L'extension Spring Boot est la solution de Spring basée sur les conventions plutôt que sur la configuration pour créer des applications Spring autonomes et prêtes pour la production . Elle est préconfigurée selon les recommandations de l'équipe Spring concernant la meilleure configuration et utilisation de la plateforme Spring et des bibliothèques tierces, ce qui vous permet de démarrer facilement. La plupart des applications Spring Boot nécessitent peu de configuration Spring
Caractéristiques principales :
- Créer des applications Spring autonomes
- Intégrez Tomcat ou Jetty directement (pas besoin de déployer de fichiers WAR )
- Fournissez des modèles d'objets de projet (POM) « démarrants » personnalisés pour simplifier votre configuration Maven / Gradle
- Configurer automatiquement Spring chaque fois que possible
- Fournir des fonctionnalités prêtes pour la production telles que des métriques , des contrôles de santé et une configuration externalisée
- Aucune génération de code et aucune exigence de configuration XML.
- Intégration fluide et prise en charge de tous les modèles d'intégration d'entreprise.
Roo printanier
- Extensibilité (via des modules complémentaires)
- Productivité de la plateforme Java (par opposition à d'autres langages)
- Éviter le blocage (Roo peut être retiré en quelques minutes de toute application)
- Éviter l'exécution (avec les avantages de déploiement associés)
- Facilité d'utilisation (notamment via les fonctionnalités de l'interface et les modèles d'utilisation)
Cadre de traitement par lots
- journalisation / traçage
- gestion des transactions
- statistiques de traitement des tâches
- redémarrage de la tâche
Il fournit des services et des fonctionnalités techniques plus avancés qui permettent des travaux par lots à très grand volume et à hautes performances grâce à des techniques d'optimisation et de partitionnement .
Spring Batch exécute une série de tâches ; une tâche se compose de plusieurs étapes et chaque étape comprend une opération de type « lecture-traitement-écriture » ou une sous-tâche. Une sous-tâche est également appelée sous-tâche. Elle consiste à effectuer une seule opération, comme le nettoyage des ressources avant ou après le début ou la fin d'une étape.
Le processus « LECTURE-TRAITEMENT-ÉCRITURE » comprend les étapes suivantes : « lire » des données à partir d’une ressource ( CSV, XML ou base de données), « traiter » ces données, puis les « écrire » dans d’autres ressources (CSV, XML ou base de données). Par exemple, une étape peut consister à lire des données à partir d’un fichier CSV, [ les traiter et à les écrire dans la base de données. Spring Batch fournit plusieurs classes pour lire et écrire des données CSV, XML et des données de bases de données.
Les étapes peuvent être enchaînées pour s'exécuter comme une tâche.
Cadre d'intégration
- routeurs – acheminent un message vers un canal de messages en fonction de conditions
- transformateurs – convertit/transforme/modifie la charge utile du message et crée un nouveau message avec une charge utile transformée
- adaptateurs – s'intègrent à d'autres technologies et systèmes (HTTP, AMQP (Advanced Message Queuing Protocol), JMS (Java Message Service), XMPP (Extensible Messaging and Presence Protocol), SMTP (Simple Mail Transfer Protocol), IMAP (Internet Message Access Protocol), FTP (File Transfer Protocol) ainsi que FTPS / SFTP , systèmes de fichiers, etc.)
- filtres – filtre un message en fonction de critères. Si les critères ne sont pas remplis, le message est supprimé.
- Les activateurs de service permettent d'invoquer une opération sur un objet de service. Spring prend en charge l'utilisation de l'annotation
@ServiceActivatorpour déclarer le composant qui requiert cette fonctionnalité. - gestion et audit
- Les passerelles exposent une interface au client pour les services demandés. Un middleware de messagerie est chargé de fournir cette interface. Celle-ci découple le middleware de messagerie du client en masquant les API JMS ou Spring Integration sous-jacentes. Les passerelles sont liées au modèle de conception Facade . La classe Integration de Spring
SimpleMessagingGatewayfournit un support essentiel pour les passerelles.SimpleMessagingGatewayElle permet à l'application Spring de spécifier le canal d'envoi des requêtes et celui de réception des réponses. Son rôle principalSimpleMessagingGatewayest de gérer les charges utiles, ce qui dispense le client des détails complexes des messages transmis et reçus.SimpleMessagingGatewayElle est utilisée conjointement avec les canaux pour permettre l'intégration avec les systèmes de fichiers, JMS, la messagerie électronique ou tout autre système nécessitant des charges utiles et des canaux. - Le séparateur divise une charge utile importante en charges utiles plus petites afin de prendre en charge différents flux de traitement. Dans Spring, le séparateur est implémenté à l'aide du composant `splitter`. Ce composant transmet généralement les messages à des classes dotées de fonctionnalités plus spécialisées. Spring prend en charge l'
@Splitterannotation `@Splitter` pour déclarer le composant qui requiert cette fonctionnalité. - Agrégateur - Utilisé pour combiner plusieurs messages en un seul résultat. En résumé, l’agrégateur est l’inverse du séparateur. L’agrégateur publie un seul message pour tous les composants en aval. Spring prend en charge l’
@Aggregatorannotation permettant de déclarer le composant qui requiert cette fonctionnalité.
Spring Integration prend en charge les architectures basées sur le modèle pipe-and-filter.
WebSocket Spring
Une règle essentielle pour gérer efficacement les flux de données est de ne jamais les bloquer. Le WebSocket constitue une solution viable à ce problème. Le protocole WebSocket est un protocole de transport de bas niveau qui permet des canaux de communication bidirectionnels (full-duplex) sur une connexion TCP . Le WebSocket se présente comme une alternative au protocole HTTP pour permettre une communication bidirectionnelle entre le client et le serveur. Le WebSocket est particulièrement utile pour les applications qui nécessitent des échanges fréquents et rapides de petits fragments de données, à haut débit et en grande quantité.
Spring prend en charge le protocole WebSocket en fournissant l'API WebSocket pour les applications réactives. L' @EnableWebSocketannotation `@WebSocketHandlers` active le traitement des requêtes WebSocket lorsqu'elle est placée dans une classe de configuration Spring. L'interface `WebSocketHandlers` est obligatoire et WebSocketConfigurerpermet d'accéder à l'API WebSocketConfigurer. L'URL WebSocket est ensuite associée aux gestionnaires appropriés via l'implémentation de la méthode `registerWebSocketHandlers(WebSocketHandlerRegistry)`.
WebFlux de printemps
Spring WebFlux est un framework suivant le paradigme de la programmation fonctionnelle, conçu pour la création d'applications Spring réactives. Ce framework utilise intensivement la programmation fonctionnelle et les flux réactifs. Un cas d'utilisation pertinent pour Spring WebFlux est celui des applications nécessitant l'envoi et la réception d'informations instantanées, comme une application web dotée de fonctionnalités de messagerie instantanée.
Bien que les applications utilisant la technologie Spring WebFlux soient généralement moins lisibles que leurs homologues MVC, elles sont plus robustes et plus simples à étendre. Spring WebFlux réduit la nécessité de gérer les complications liées à la synchronisation des accès aux threads.
Spring WebFlux prend en charge les événements envoyés par le serveur (SSE), une technologie de type « push » qui permet au client de recevoir des mises à jour automatiques d’un serveur via une connexion HTTP. Cette communication est unidirectionnelle et présente plusieurs similitudes avec le modèle de publication/abonnement de JMS.