Envoyé par
Sebajuste
L'application réactive est avant tout un paradigme (qui n'a rien de nouveau d'ailleurs), aussi il n'est pas spécialement lié à un framework.
Il est tout à fait possible de faire du réactif avec du Java "de base".
A mon sens, il a deux avantages :
- diminuer le nombre de thread (1 thread = 1 tâche est une manière de faire complètement obsolète)
- Obtenir des applications en temps réel relatif. C'est à dire qu'on ne peut pas assurer que la réponse sera obtenue en moins de x millisecondes, mais qu'elle sera traitée au plus tôt.
Pour la gestion des threads, je prendrais l'exemple des socket.
En java, les "Socket" sont bloquant. Créer un serveur avec des Socket de base nécessite de faire 1 thread par client connecté. Avec java.nio on peut passer par des Selector : un objet qui retourne uniquement les sockets ayant quelque chose à faire : un seul et unique thread estalors nécéssaire, quelque soit le nombre de client.
Avec JEE, les serveurs d'applications utilisent déjà ces outils. Le serveur dispose alors d'un pool de thread (un petit nombre, quelques dizaines grand maximum). Chaque nouvelle requète sera traité par un thread libre du pool.
Il faut donc voir les appels de nos EJB, Servlet... comme des évènements. Ce qui signifie aussi que ces évènements doivnet être très court : si tous les thread du pool sont utilisés, les autres "évènements" (les autres requètes HTTP) seront mise en attente.
L'idée est donc de découper un traitement de requête en plusieurs traitement, pouvant être parallélisé :
- soit les traitement peuvent d'exécuter en parallèle
- soit les traitements sont séquentiels; à ce moment chaque traitement bloquant (ex: utilisation de la base de données) sera traité par un nouveau thread. Le thread appelant pouvant alors être "libéré"; c'est à dire qu'il va pouvoir se terminer rapidement, afin de traiter une nouvelle requète.
Les dernières version de JEE gèrent les appel de bean dans d'autres thread par le biais de l'annotation @Asynchronous, et du retour de méthode avec l'objet Future<>. Ont peut également créer des pool de thread directement dans le serveur d'application (comme une connexion à une base de données) que l'on récupère dans notre programme avec JNDI, et les annotations de types @Resource
La véritable difficulté technique il me semble, et de créer un callback de retour d'information asynchrone sur le client. Si le client est une page web, utilisant javascript et Ajax, le callback de retour sera celui de la requète HTTP. Or, si le serveur traite la requète par plusieurs thread consécutif, le retour du premier appel sera certes très rapide (le serveur ne gardant pas la mail, et délègue le traitement), mais la réponse ne sera tout simplement pas prête !
Il faudrait donc faire des requêtes à interval régulière, pour savoir si la réponse est prête. En plus d'être peu performant, il est alors nécessaire de distinguer chaque couple requète/réponse par un système d'ID : si une réponse est prête, il faut se souvenir de quelle requête elle est issue.
Le moyen le plus performant à mon avis reste les websocket : les requètes / réponses sont envoyées et reçus immédiatement par un "flux", et non par des multitudes de requêtes.
De plus, les flux de données sont particulièrement adaptés aux applications réactives : si la réponse contient des centaines de résultats, sans liens spécifiques entre entre eux, on peut commencer à renvoyer les premiers résultats générés, alors que le traitement coté serveur n'est pas encore terminé.
Répondre avec citation
Partager