Téléchargé parIppon
Stateful is beautiful
Le document aborde le concept de stateful dans Java EE, en le comparant avec les approches stateless et dry stateful, tout en soulignant les avantages et inconvénients de chacun. Il discute des idées reçues autour du stateful, notamment sa complexité et son utilisation avec Spring, ainsi que son potentiel en architectures modernes. Le texte conclut en affirmant que le stateful est souvent sous-estimé mais peut offrir des solutions efficaces lorsque correctement intégré.
Stateful is beautiful
- 1. Stateful is Beautiful Retour aux sources de Java EE
- 2. <ego>A propos de...</ego> Antoine Sabot-Durand Expert Java EE 16 ans d’expérience Leader sur Seam Social Membre de l’EG CDI 1.1 Twitter : @antoine_sd Hastag : #StatefulIsBeautiful
- 3. <pub>A propos de...</pub> IpponTechnologies Java EE Portail SOA RIA e-commerce Mobilité
- 4. De quoi sera-t’ilquestion ? Stateless / Stateful & cie EJB CDI JPA Pattern Stateful des trolls sur Spring
- 5. Stateless et Stateful sontsur un bateau
- 6. De quoi parle-t’on? La stack Java EE dispose de 3 approches possibles : StateLess Stateful Dry StateFul
- 7. StateLess Aucun état côtéserveur Tout est stocké côté client Le client gère la mise à jour La même requête donnera toujours le même résultat
- 8. Stateful Dry L’état est stocké côté serveur Il est «déshydraté» via une solution de cache ou dans une BDD Puis réhydraté à chaque requête pour récréer le contexte utilisateur A la fin de la requête l’état en mémoire est détruit
- 10. Stateful Le serveur stockel’état de session utilisateur Cet état est accessible en mémoire Le client se contente de transmettre un id
- 11. Stateful dry vsStateless ? Sont souvent confondus L’appli full Stateless ne créé pas d’état mémoire temporaire Le full Stateless est donc plus rare qu’on ne le pense
- 12. Statefuldry vs Stateful data Scope HTTP Requete Contexte Container EJB/CDI Scope HTTP Session Session
- 13. Pourquoi le Stateful est-il mal aimé ?
- 14. Les légendes urbaines LeStateful Lourd et Compliqué c’est... Non scalable Contre nature car http est stateless Ringard Cancérigène
- 15. Historique Java EE Spring 2.5.1 supporte les EJB3 11/01/2008 Spring 1.0 24/03/2004 Spring arrive sur Sourceforge Spring 2.0 Spring 2.5 Spring 3.0 20/02/2003 03/10/2006 supporte les 19/12/2009 annotations 17/11/2007 Java Professional J2EE 1.2 J2EE 1.3 J2EE 1.4 Java SE 5.0 Java EE 5 Java EE 6 Edition 12/12/1999 24/09/2001 11/11/2003 30/09/2004 11/05/2006 10/12/2009 Mai 1999 1998 1999 2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011
- 16. La réalité Plus dela moitié des développements Java utilisent Spring Spring supporte le Stateful à contre coeur et de manière très partielle Les problèmes de scalabilité du stateful sont solutionnables mais pas avec Spring Donc près de 3/4 des developpeurs Java jugent le stateful à travers un outil inadapté au stateful
- 17. Spring, le MarteauDoré « Un outil ou framework, pour lequel une équipe a acquis un niveau de compétence tel qu’il sera systématiquement mis en oeuvre pour toute nouvelle problématique quelque soit son niveau d’adéquation aux besoins réels » « Quand on détient un marteau doré, tous les problèmes ressemblent à un clou »
- 18. Le stateful avecJava EE
- 19. Les Acteurs duStateful Les scopes servlet et JSF CDI et ses scopes EJB 3.X et son @stateful JPA et le persistence context
- 20. Scopes servlet etJSF Scope Application La session Le Scope view : qui permet de stocker de l’information le temps d’une vue Le Scope Flash : qui survit d’une requête à l’autre Le scope requête : le scope du Stateful Dry
- 21. CDI 1/2 Solution d’injectionde dépendance couplage faible fortement typée Patterns mis en oeuvre Interceptor Decorator Observer Scope conversation : je contrôle enfin le cycle de vie de mon scope
- 22. CDI 2/2 Lesidées reçues CDI 1.0 n’est pas exploitable car trop jeune Héritage de Seam & Guice Nécessite de travailler avec les EJB Les deux se marient bien mais rien n’est obligé Ne fonctionne qu’avec Java EE 6 Tourne sur Tomcat 6 Ne fonctionne qu’avec JSF Extension pour JSF, Servlet, Gwt, Wicket Tourne aussi sur Java SE en standalone Pas d’interoperrabilité avec Spring Extension CDI-Spring bridge dans les deux sens
- 23. LES EJB 1/2 Transactionnelset distribuables Existent en plusieurs parfum : Stateless Stateful Gèrent la planification, le JMS Disposent d’un conteneur spécifique géré par le serveur Permettant de partager naturellement des services entre plusieurs applications Par défaut sont des Bean CDI
- 24. LES EJB 2/2idées reçues Lourd et compliqués @Stateful public class MonEjb { Pas testables public void MaMethode(){ Ne font que du stateful } ... Utilisable que dans des } développements Web
- 25. Le Persistence context Enprovenance de JPA Gère l’interaction avec la BDD Le Mapping avec les entités Le cache de niveau 1 : l’entity manager cache les entités qu’il manage Le cache de niveau 2 : JPA cache ses interactions avec la BDD Vaut mieux qu’un DAO Stateless
- 26. Ces outils sontvos amis Polyvalents Facile à prendre en mai Savent cohabiter avec votre marteau doré Permettent de créer des architectures nouvelles Arrêtez de tordre Spring quand Java EE est plus adapté
- 27. Pourquoi le Statefulest beautiful ?
- 28. Pourquoi a-t’on oublié... Lasérialisation des services ? Parce que les bean spring ne sont pas facilement serialisables (problèmes avec les proxys d’injection) Parce qu’elle n’est utile que dans le cadre d’une architecture Stateful La Passivation des services ? Parce qu’elle ne fonctionne que si la serialisation est possible Parce que le conteneur Spring ne l'intègre pas dans son cycle de vie
- 29. Mais il n’estpas trop tard Les EJB et les bean CDI sont vraiment serialisables Du coup la passivation est utilisable Pour les EJB c’est monnaie courant et facile à gérer avec @PrePassivate et @PostActivate Et peut servir à tranformer le StateFul en StateDry automatiquement : la sérialization devient un stockage lent pour les beans non sollicités depuis un temps donné
- 30. Le Stateful peutêtre restful Etre stateful n’empêche pas la résilience : Possibilité de récréer une session à partir d’une information envoyée par le client. Ainsi tout une partie de l’application peut rester restful et une autre peut n’être que stateful : Catalogue, puis tunnel de vente.
- 31.
- 32. Architectures possibles 1/2 Pourceux qui aiment les couches Il est toujours possible de faire ça On peut même en mettre plus qu’avec Spring
- 33. Architectures possibles 3/3 Unearchitecture beaucoup plus ramassée Mise en oeuvre du pattern Gateway Permet un développement rapide
- 34. Conclusion : Les outils du Stateful permettent de faire aussi du Stateless (sans être tordus).