quarta-feira, 22 de outubro de 2014

Java EE est-il réactif ?

Dans la présentation suivante, Reza Rahman nous expose les moyens pour le framework Java Entreprise de se conforter aux besoins de réactivité dans les applications websophistiquées destinées à une très forte audience pour un fonctionnement permanent:

1.   Applications réactive ?
Un certain nombres de qualités permettent de définir des applications de type réactif.
  • Responsivité (très faible temps de réponse; ne pas confondre avec son homonyme, responsivité, en tant qu’adaptabilité à tous les types de médias (tablettes, smarphones …))
  • Résilience (tolérance aux incidents d’infrastructure et autres erreurs)
  • Elasticité (réponse adaptée aux pics de fréquentation, digestion des montées en charge)
  • Orienté-Messages (ce choix d’architecture force le couplage faible, la séparation des responsabilités entre les composants)
Ils sont regroupé dans le Reactive Manisfesto: une déclaration d’acteurs du web, à la manière de l’Agile Manifesto, 12 ans après.

2.   Qui se cache derrière le Reactive Manifesto ?
La société Typesafe, comprenant:
Martin Odersky, professeur à l’EPFL, est le créateur du langage Scala (Langage objet et fonctionnel, statiquement typé). Il a écrit le compilateur Java officiel jusqu’à la version 5, ainsi que les génériques en Java.
> Jonas Boner, créateur du framework Akka (programmation conncurrente implémentant le Modèle d’acteurs)
Guillaume Bort, créateur du framework web Play! qui choisit de ne pas implémenter pas la spécification des Servlets (et donc, sortir du cadre de Java EE)
Les inspirateurs du texte initial sont mentionné dans ce post.
Vous pouvez visionner la liste des mises à jour du manifeste sur GitHub. On y trouve les personnalités suivantes:
Bruce Eckel, auteur du livre gratuit « Penser en Java »
Ed Burns, le créateur du framework JSF (le framework web de référence de Java EE)

3.   Comment concevoir des applications réactives dans Java EE ?
C’est le coeur du sujet de la présentation de Reza Rahman: il existe ça et là dans Java EE des mécanismes pour apporter de l’asynchronisme aux applications.
> JMS est l’api reine car purement asynchrone, reposant sur l’échange de messages
> Les EJB asynchrones, avec (Future) ou sans valeur de retour (fire-and-forget)
> Les Servlets asynchrones
> Les serveurs Java utilisants des threads non bloquants (implémentant l’API Java NIO)
> Les client d’appel asynchrones (REST, Managed ExecutorService, etc)
> Les Websockets

4.   Changement de manière de programmer
Bien que simplifiée, la programation usuelle d’aujourd’hui avec Java EE resteprocédurale.
Un besoin de réactivité pourrait bouleverser la manière de programmer. Nous programmerions alors plus de manière événementielle.
Cela ne se fera pas sans un changement de l’approche métier.
(ex: on ne peut pas exécuter consécutivement 2 écritures asynchrones et interdépendantes dans le même appel client: un nouveau service serveur effectuant les 2 écritures doit être ajouté.)
On verrait bien aussi l’ajout aux status métiers d’une entité de statuts techniquesintermédiaires de traitement ainsi que les mécanismes de reprise sur erreur.
(ex: dans le cas d’un redémarrage du serveur au milieu d’un traitement)
Les langages fonctionnels (Javascript, Scala) sont particulièrement bien adaptés à ce style de programmation car bien plus lisibles et moins verbeux que Java.
On comprend ainsi pourquoi Typesafe a élaboré une stack centrée sur ce type de programmation, avec le langage Scala, le framework Akka pour les process et le framework Play! pour la couche présentation.
Java essaye de rester à la page en introduisant les fonctions lambda dans sa version Java SE 8. Celui qui a développé le module des fonctions lambda est Brian Goetz, aidé de loin par Martin Odersky (le créateur de Scala)… la boucle est bouclée. Le code des applications Java va sûrement augmenter en complexité aussi.
Java EE devient donc un peu plus réactif, mais cela a un prix:
> Cela reste difficile à mettre en oeuvre (le code technique correspondant est encore réservé aux leaders techniques ainsi qu’aux architectes)
> Les développeurs Java, avec la multiplication des manières de programmer, auront àcomprendre et maintenir des applications de plus en plus complexes.