Téléchargez le PDF avec le bouton au-dessus du slideshow. J'ai utilisé Play 2.x pour déployer un service en Saas et j'ai bien aimé plusieurs nouveaux concepts, plus simples que les autres frameworks Java, car ne reposant pas sur la Servlet API. J'ai voulu le partager avec le Java User Group de Lyon. Durée 15 minutes. C'est tombé juste avant une présentation de Java EE 7 par David Delabassee, une belle occasion d'introduire le débat.

1. PLAY FRAMEWORK 2
JAVA
@aragot
mercredi 19 mars 14
- J’ai déployé une appli en SAAS pour Atlassian Confluence - Voir https://marketplace.atlassian.com/vendors/1210634
- Play remet en cause nos hypothèses et ça rafraîchit
- Donc j’ai voulu partager ça avec la communauté JUG

2. GUILLAUME BORT
& HABIB GUERGACHI
CTO & CEO chez Zengularity
http://soat.developpez.com/articles/weborientedarchitecture/
http://www.parleys.com/play/5148922a0364bc17fc56c738
http://www.parleys.com/play/517ae9a4e4b0736a5fa66a1f
mercredi 19 mars 14
Les auteurs valent le détour
Conférences de Habib Guergachi a Devoxx, je recommande
Habib aime bien jeter un paver dans la mare, moquer les habitudes des devs Java. Il nous incite à nous rebeller contre le modèle Entreprise.

3. GUILLAUME BORT
& HABIB GUERGACHI
Devoxx 2012
Devoxx 2013
CTO & CEO chez Zengularity
http://soat.developpez.com/articles/weborientedarchitecture/
http://www.parleys.com/play/5148922a0364bc17fc56c738
http://www.parleys.com/play/517ae9a4e4b0736a5fa66a1f
mercredi 19 mars 14
Les auteurs valent le détour
Conférences de Habib Guergachi a Devoxx, je recommande
Habib aime bien jeter un paver dans la mare, moquer les habitudes des devs Java. Il nous incite à nous rebeller contre le modèle Entreprise.

4. GUILLAUME BORT
& HABIB GUERGACHI
CTO & CEO chez Zengularity
JEE
mercredi 19 mars 14
- Problème = Modèle Entreprise = J2EE est une spec lourde, demande beaucoup de compétences, on n’est senior qu’après 7 ans. Cool, ça nous fait des hauts salaires.
- Ruby On Rails: A côté on a des jeunes qui font des services web utilisés par des milliers d'utilisateurs et qui ont 20 ans. Quel est le problème de productivité avec Java? Où est-ce qu'on s'est enlisés?
- Une partie de la réponse c'est la critique de la Servlet API
- Une autre, la remise en cause de nos modes de gestion de projet.

5. GUILLAUME BORT
& HABIB GUERGACHI
CTO & CEO chez Zengularity
“Mort du modèle Entreprise”
mercredi 19 mars 14
BDUF: Spécifier un projet sur 1 an, cahier des charges de 1000 pages = Approche “brute force” et plutôt naive.
Le BDUF, et le modèle de la DSI centralisée, c’est notre mort en tant qu’ingénieurs.
Habib promeut:
- Décentralisé,
- Petites équipes
- Typiquement, Agile,
- Web-Oriented Architecture => Applications REST, indépendantes, centrées sur leur métier (Stockage de fichiers, recherche plein texte), mash-ups
- Play est l'aboutissement de cette philosophie.

6. GUILLAUME BORT
& HABIB GUERGACHI
CTO & CEO chez Zengularity
“Web-Oriented Architecture”
mercredi 19 mars 14
BDUF: Spécifier un projet sur 1 an, cahier des charges de 1000 pages = Approche “brute force” et plutôt naive.
Le BDUF, et le modèle de la DSI centralisée, c’est notre mort en tant qu’ingénieurs.
Habib promeut:
- Décentralisé,
- Petites équipes
- Typiquement, Agile,
- Web-Oriented Architecture => Applications REST, indépendantes, centrées sur leur métier (Stockage de fichiers, recherche plein texte), mash-ups
- Play est l'aboutissement de cette philosophie.

7. PRINCIPES
• Productivité du développeur
• Prêt pour le Cloud[1]
• Asynchrone
[1] https://news.ycombinator.com/item?id=7172060
mercredi 19 mars 14
Principes
- Priorité à la productivité. Hypothèse qu’on va faire du web => on peut fournir un fw intégré. But: Livrer une app en quelques jours.
- Prêt pour le cloud. En phase avec la philosophie Décentralisé: Si l'appli a du succès, si arrive au coeur des services métiers, on peut la scaler. Sinon on peut lui donner 1/2 CPU. Comme vu a JUG de
Janvier sur Logback, ça a un impact sur le code: En Cloud, un serveur n’a pas d’importance, il peut être éteint et remplacé en quelques secondes, donc on doit faire plus de “stateless”. On va voir comment
toute cette philosophie est implémentée dans Play.
- Asynchrone. Principe que le framework doit être en avance sur les usages. Les usages évoluent: Long polling, chat, streaming, et surtout quand les back-ends ont beaucoup de latence (ex: dans le cas de
stocker dans Amazon S3, et dans le cas des DSI orientées WOA), on ne peut pas bloquer un thread en attendant une réponse. Car cela supposerait 1 thread par client, donc 10 000 clients, 10000 threads,
pas scalable.
Donc le NIO, et sortir de la Servlet API, c'est à la fois une question de scalabilité, une question de nouveaux usages, et une question d’architecture du web décentralisé puisqu’on repose sur des back-ends à
forte latence. cf JUG suivant par David Delabassee: Il va nous présenter les WebSockets et le NIO dans Java 7.

8. SESSIONS
Sessions façon J2EE:
• Cookie: JSessionID
• Sessions façon Play:
• Cookie (signé)
mercredi 19 mars 14
Prenons un exemple de choses fondamentales que Play remet en cause.
- Le sessions en Servlet API = envoie un cookie JSESSIONID pour identifier l'utilisateur, et les variables de session sont stockées en RAM.
- Du coup, toute une classe de pb.
- En cluster, le second noeud ne connaîtra pas la session. Seul le premier. => LB à affinité de session: Un client est toujours renvoyé au même noeud.
- Redémarrage => Sessions perdue => Utilisatuer déloggué => Inventer “Persistence des sessions” sur un disque.
- Après 6 mois et 1m visites, problématique de la purge de sesisons.
- Toute une classe de problèmes, parce que hypothèse de base incorrecte. On ne peut pas scaler quand le server stocke 1 session par client.
- Dans Play: Si vous avez une variable utilisateur à stocker => Cookie => Signé par clé privée. Pas d'info du côté du serveur.
STATELESS. Pas d'état côté server. Soit dans le cookie, soit dans la DB soit chez le client. Donc vous pouvez multiplier les serveurs web: vos 15 autres serveurs ont les mêmes infos pour traiter vos
requêtes.
- Ensuite, pour optimisation: Cache API. Pb de cache, pas de session.
- Je recommande la lecture des critiques de la Servlet API, pour remettre en perspective nos connaissances.

9. TEMPLATES
mercredi 19 mars 14
Passons au code.
Rassurant: HTML
- Injection de variable au milieu: @context.
- En réalité, c’est un template Scala => Compilé en .class => Appelé directement depuis Java. Le plus efficace!
=> Play = culture Scala, jouer avec le bytecode.

10. ROUTES
mercredi 19 mars 14
- Liste des URLs -> Méthodes associées.
- Technique à la mode: “Design d’API”
- Par oppositions aux urls *.do, *.action de Struts. Tous les fw Java redéfinissent le routing d’URL, c’est la preuve que l’expression des urls dans la Servlet API est trop limitée. Impact: Le developpeur doit
apprendre 2, 3, 4 fw pour router ses urls: Servlet API + Struts + Spring + ...
- Design d’urls = important quand on expose son API et qu’on veut faire du RESTful.
- Donc important dans un SI de type “WOA”, où beaucoup d’autres équipes consomment vos services,
- Et des urls expressives évitent d’avoir à documenter => Principe Agile: La meilleure doc est celle qu’on n’a pas besoin d’écrire.

11. CONTRÔLEURS
mercredi 19 mars 14
- Première ligne lit une valeur dans le cookie de session. Second ligne va chercher une donnée en base de données. Ça aurait pu être une facture, un client. Dernière ligne: context_list.render(), c’est l’appel
au template vu précédemment, voyez comme le type-checking est pratique.
- Oh! La méthode est statique! Tout est statique!
- Oui, Play matérialise le côté stateless en rendant les méthodes statiques (certaines méthodes seulement - voir http://stackoverflow.com/a/5193721/965134 ) Du coup ça décourage le développeur, surtout
débutant, de stocker des variables d'état ou de cache.
=> On vous fournit direct de quoi rendre du HTML, manier vos URLs, etc. Plus facile que Servlet API + x frameworks. Beaucoup comparent Play à Ruby On Rails.

12. CONTRÔLEURS
mercredi 19 mars 14
- Première ligne lit une valeur dans le cookie de session. Second ligne va chercher une donnée en base de données. Ça aurait pu être une facture, un client. Dernière ligne: context_list.render(), c’est l’appel
au template vu précédemment, voyez comme le type-checking est pratique.
- Oh! La méthode est statique! Tout est statique!
- Oui, Play matérialise le côté stateless en rendant les méthodes statiques (certaines méthodes seulement - voir http://stackoverflow.com/a/5193721/965134 ) Du coup ça décourage le développeur, surtout
débutant, de stocker des variables d'état ou de cache.
=> On vous fournit direct de quoi rendre du HTML, manier vos URLs, etc. Plus facile que Servlet API + x frameworks. Beaucoup comparent Play à Ruby On Rails.

13. CONTRÔLEURS
mercredi 19 mars 14
- Première ligne lit une valeur dans le cookie de session. Second ligne va chercher une donnée en base de données. Ça aurait pu être une facture, un client. Dernière ligne: context_list.render(), c’est l’appel
au template vu précédemment, voyez comme le type-checking est pratique.
- Oh! La méthode est statique! Tout est statique!
- Oui, Play matérialise le côté stateless en rendant les méthodes statiques (certaines méthodes seulement - voir http://stackoverflow.com/a/5193721/965134 ) Du coup ça décourage le développeur, surtout
débutant, de stocker des variables d'état ou de cache.
=> On vous fournit direct de quoi rendre du HTML, manier vos URLs, etc. Plus facile que Servlet API + x frameworks. Beaucoup comparent Play à Ruby On Rails.

14. CONTRÔLEURS
mercredi 19 mars 14
- Première ligne lit une valeur dans le cookie de session. Second ligne va chercher une donnée en base de données. Ça aurait pu être une facture, un client. Dernière ligne: context_list.render(), c’est l’appel
au template vu précédemment, voyez comme le type-checking est pratique.
- Oh! La méthode est statique! Tout est statique!
- Oui, Play matérialise le côté stateless en rendant les méthodes statiques (certaines méthodes seulement - voir http://stackoverflow.com/a/5193721/965134 ) Du coup ça décourage le développeur, surtout
débutant, de stocker des variables d'état ou de cache.
=> On vous fournit direct de quoi rendre du HTML, manier vos URLs, etc. Plus facile que Servlet API + x frameworks. Beaucoup comparent Play à Ruby On Rails.

15. CONTRÔLEURS
mercredi 19 mars 14
- Première ligne lit une valeur dans le cookie de session. Second ligne va chercher une donnée en base de données. Ça aurait pu être une facture, un client. Dernière ligne: context_list.render(), c’est l’appel
au template vu précédemment, voyez comme le type-checking est pratique.
- Oh! La méthode est statique! Tout est statique!
- Oui, Play matérialise le côté stateless en rendant les méthodes statiques (certaines méthodes seulement - voir http://stackoverflow.com/a/5193721/965134 ) Du coup ça décourage le développeur, surtout
débutant, de stocker des variables d'état ou de cache.
=> On vous fournit direct de quoi rendre du HTML, manier vos URLs, etc. Plus facile que Servlet API + x frameworks. Beaucoup comparent Play à Ruby On Rails.

16. LANCEMENT
mercredi 19 mars 14
Démarrer
- Play => Lance la SBT
- L'outil de build est scala. Pas Maven.
- Inconvénient: Gérer les dépendances en sbt, il faut réapprendre
- Avantage: Recompilation à la volée, à chaque rechargement de page en mode dev (voir slide 21)
- Commande run => Lance Netty => Server d'appli qui supporte les websockets.
- Depuis 2-3 slides je présente des choix d'architectures qu'ils ont faits: Ils ont choisi qu'on fait du web, JPA - Hibernate, Netty, tempaltes HTML.
- Choix réversibles: Templates Soy ou Velocity.
- Principe: Proposer des choix par défaut pour que le développeur soit efficace et puisse livrer l'appli rapidement. Une application de qualité, qui soit scalable.

17. LANCEMENT
mercredi 19 mars 14
Démarrer
- Play => Lance la SBT
- L'outil de build est scala. Pas Maven.
- Inconvénient: Gérer les dépendances en sbt, il faut réapprendre
- Avantage: Recompilation à la volée, à chaque rechargement de page en mode dev (voir slide 21)
- Commande run => Lance Netty => Server d'appli qui supporte les websockets.
- Depuis 2-3 slides je présente des choix d'architectures qu'ils ont faits: Ils ont choisi qu'on fait du web, JPA - Hibernate, Netty, tempaltes HTML.
- Choix réversibles: Templates Soy ou Velocity.
- Principe: Proposer des choix par défaut pour que le développeur soit efficace et puisse livrer l'appli rapidement. Une application de qualité, qui soit scalable.

18. LANCEMENT
mercredi 19 mars 14
Démarrer
- Play => Lance la SBT
- L'outil de build est scala. Pas Maven.
- Inconvénient: Gérer les dépendances en sbt, il faut réapprendre
- Avantage: Recompilation à la volée, à chaque rechargement de page en mode dev (voir slide 21)
- Commande run => Lance Netty => Server d'appli qui supporte les websockets.
- Depuis 2-3 slides je présente des choix d'architectures qu'ils ont faits: Ils ont choisi qu'on fait du web, JPA - Hibernate, Netty, tempaltes HTML.
- Choix réversibles: Templates Soy ou Velocity.
- Principe: Proposer des choix par défaut pour que le développeur soit efficace et puisse livrer l'appli rapidement. Une application de qualité, qui soit scalable.

19. PRINCIPES
• Productivité
• Cloud
• Asynchrone
mercredi 19 mars 14
Revenons sur les principes:
- Productif: Play propose des choix par défaut qui sont “suitable” pour de la prod. But: Livrer une app en quelques jours au lieu de se quereller sur les fws.
- Prêt pour le cloud: On a vu comment le stateless étati exprimé, on a vu l’usage des sessions, et au JUG de Janvier on a vu Logback.
- Asynchrone: On n’a pas vu mais Play intègre par défaut des WebSockets + Comet
Choix sérieux. LinkedIn utilise Play sur plusieurs sous-parties du site.

20. PRINCIPES
• Productivité
• Cloud
• Asynchrone
• Choix d’architecture
• Stateless, Sessions
• WebSockets, Comet, Netty
IMPLEMENTATION
mercredi 19 mars 14
Revenons sur les principes:
- Productif: Play propose des choix par défaut qui sont “suitable” pour de la prod. But: Livrer une app en quelques jours au lieu de se quereller sur les fws.
- Prêt pour le cloud: On a vu comment le stateless étati exprimé, on a vu l’usage des sessions, et au JUG de Janvier on a vu Logback.
- Asynchrone: On n’a pas vu mais Play intègre par défaut des WebSockets + Comet
Choix sérieux. LinkedIn utilise Play sur plusieurs sous-parties du site.

21. CRITIQUES
• #1: Statics
• Librairies: /! NIO
• Support JUnit [1]
• SBT
• Compatibilité 1.x - 2.x
[1] http://lostechies.com/jamesgregory/2011/09/18/observations-on-the-play-framework/
mercredi 19 mars 14
Un mot sur les critiques
- L'usage des statics controversé - rend le code peu testable. Il y a plusieurs workarounds: PowerMock et l'usage de Guice ou Spring, mais globalement ça veut dire qu'on n'est pas assez poussé à faire du
test unitaire.
- Les libraries utilisées doivent être NIO
- Le support JUnit est désagréable: Il faut exécuter les tests dans le browser
- L'usage de la SBT: Un outil difficile à apprendre, j'espère que vous n'en aurez pas trop besoin.
- La perte de compatibilité entre la version 1 et 2. Beaucoup de plugins n'existent que pour la version 1. Mais LinkedIn utilise la version 2.

22. POURQUOI?
• Quick learning curve
• Technos incontournables en 2014
• Attirer des talents
mercredi 19 mars 14
Enfin, pourquoi? Dans SSII, sur votre projet...
- D'abord vous allez former vos recrues rapidement. Elles seront plus vite capables de mettre une appli en prod. Ça, c'est bon pour vous.
- Ce qui est aussi bon pour vous, c'est que vous allez apprendre ou entendre parler de plein de technos modernes. Même si vous ne les utilisez pas pour Play, ça va vous remettre à l'heure et vous rafraîchir.
- Et si vos membres apprennent des choses sur le projet, les jeunes vont vouloir venir travailler pour vous. Donc vous pourrez vous entourer de gens talentueux et motivés, et ça, ça vous permettra de
maintenir votre actualisation.
Donc au total, vous apprenez, vous êtes productifs, et vous attirez des gens motivés qui vont vous apprendre et qui vont maintenir votre actualisation.

23. Adrien Ragot - adrien@play-sql.com
@aragot
mercredi 19 mars 14

24. RESERVE
mercredi 19 mars 14

25. PLAY 2.X [1]
• Asynchronous programming
• Controllers return Promise<Result>
• Comet,WebSockets
• Event model,Akka
• Native support for Java and Scala
• Type Safety
• Compiled HTML templates (Scala)
• Compiled routes (Scala)
• SBT build file
[1] http://www.playframework.com/documentation/2.0/Philosophy
mercredi 19 mars 14

26. LA SERVLET API
• HTTP Denial
• Limited syntax for url routing
• Requires frameworks = 2x more config files
• Struts, Spring, JSP, JSF, JBoss Seam...
• NIO since Servlet API 3.1 (Java 7, May 2013)
[1] http://blog.lunatech.com/2011/12/08/wrong-with-servlet-api
mercredi 19 mars 14
HTTP Denial: Comme si on allait remplacer HTTP par un nouveau protocole l’an prochain
URL Routing: Pour preuve, la majorité des frameworks réimplémentent leur propre routing. Ex: Struts & urls en *.do
La Servlet API n’étant pas suffisante, on a besoin de frameworks, donc d’apprendre autant de frameworks. On éparpille nos compétences entre Struts, Spring Servlet, JSP, JSF, JBoss Seam etc.
JSF: Mais pourquoi??? http://global3.memecdn.com/why-meme_o_293612.jpg
Servlet API 3.1 arrive après que les usages soient devenus fréquents.

27. VOUS ENTENDREZ PARLER
DE...
• Backbone.js, Require.js, CoffeeScript
• FluentLenium / WebDriver / Page Objects
• Logback
• Heroku
• ...
mercredi 19 mars 14
=> Technos de 2014. Plutôt que de passer des heures à apprendre Spring et à m’ennuyer avec des specs J2EE dont la mailing liste est décédée, j’ai pu me concentrer sur des technos qui ont de la vraie
valeur ajoutée, j’ai retrouvé de la productivitié, de l’agilité, le plaisir de coder en java. J’ai rajeuni. Et ça reste prêt pour la scalabilité, et ça s’inscrit dans une vision plus moderne d’architecture du SI. cf Habib
Guergachi à Devoxx en 2012 et 2013.

28. JPA (PERSISTENCE)
Non anaemic domain model: http://www.playframework.com/documentation/1.0/model
mercredi 19 mars 14
- play.db.jpa.JPA => Pas le vrai javax.persistence.Persistence
- L’EntityManager (=en gros, la transaction) est dans le thread
- Notez que c’est un bean, mappé par JPA à une table de db.
- Notez les membres public: Après compilation ils sont privés avec des getters/setters, ce qui vous permet d’overrider les getters/setters. Encore un exemple de culture Scala.
- Remarquez le “DAO” directement sur le Bean.
=> Principe du modèle non-anémique. Les getters valident leurs données, les DAO sont sous forme de méthodes statiques, le bean est riche. Voir http://www.playframework.com/documentation/1.0/model
- Play! intègre des scripts d’évolution. On y pense rarement jusqu’au second déploiement en prod...

29. GESTION DES ERREURS
mercredi 19 mars 14
- Chaque rafraîchissement, recompilation si nécessaire (et classloader de Play)
- Principe: Accélérer le dev
- Bientôt on pourra corriger l’erreur directement depuis le web? bientôt un IDE web ;) ?

30. ACTIVITÉ
Play 1.0
October 2008
Oct2008
Nov2010
Apr2011
Fev2013
Play 1.1
JBoss Netty
Play 1.2
Apache Ivy
WebSockets
Play 2.1
JSON API
Filters
RequireJS
Play 2.2
Buffering
gzip
Hibernate or Ebean
Sep2013
Play 2.0
Async
Scala
Type Safety
Sbt
Mars2012
mercredi 19 mars 14