Devoxx Day 2 : Anvers et contre tout

Voici un petit compte rendu des sessions auxquelles j’ai assisté lors de ce deuxième Jour de Devoxx. Commençons donc par le commencement et la keynotye sur l’avenir de Java EE

Le futur de Java EE

Trois intervenants pour cette première conférence s’articulant autour des évolutions pressenties dans Java EE 7 : Jérome Dochez (architecte sur Glassfish) pour la big picture, Linda DeMichiel (sec leader de JPA 2.0) pour JPA et Paul sandoz pour JAX-RS dont il est le spec leader.

La Big Picture

L’objectif principal qui semble piloter java EE 7 est clair : Comment faire évoluer Java EE pour qu’il s’adapte au Cloud.

Dauchez parle plus d’une évolution qu’une révolution. selon lui les éléments principaux sont là pour assurer une standardisation de Java sur le Cloud. N’anmoins il reste des points à faire évoluer pour EE 7 et il évoque :

• une meilleure isolation entre les applications
• Des API standard pour l’accès aux données sur le cloud (NRDBMS)
• Des interfaces communes de monitoring et management
• Meilleure gestion des resources et de l’état applicatif

Il fait également un focus sur l’amélioration du packaging pour le cloud avec notamment

• Le versioning des applications
• Le versionning des structures de données et des données
• L’exposition de services par les apps

Pour ce faire, nous aurons besoin de créer des couches d’abstraction standard pour le cloud et notamment les couches :

• Virtualisation
• Gestion de l’état

Ces couches seront en dessous de des services java (persistance, Queueing, Webservices, etc…) qui supportera les applications Cloud. Après avoir de nouveau insisté sur l’importance de travailler sur l’isolation des applications, il se lance dans une démonstration assez bluffante.

Demo virtualisation à la dev/ops

La démonstration d’utilisation des outils “asadmin” de Glassfish pour créer et démarrer directement des VM contenant chacune une instance Glassfish, semble séduire pas mal l’ensemble de l’audience.

Il continue en créant d’autre VM toujours dans la ligne de commande Glassfish puis assemble les serveur ainsi instanciés en un cluster . Glassfish garde la main sur les VM et permet de les piloter et de sels monitoire : on est en plein Dev/Ops à Devoxx (pilotage de l’infrastructure par le code)

Modularité

Après cet intermède assez spectaculaire. Dauchez évoque la future modularité de Java EE. Malheureusement celle-ci devra attendre Java SE 8 qui ne sera pas dispo avant 2012. Ce sera donc pour Java EE 8

Pour EE 7 on peut espérer que les classloaders seront mieux spécifiés pour préaprer cette modularité et l’isolation des applications.

intégration du versioning

Les librairies fournies par le containers seront prioritaires et pourront être surchargées par des versions supérieures dans le packaging WAR ou EAR. On pourra ainsi fournir une version plus récente d’une librairie standard du serveur sans crainte de conflit et le jour où le serveur est mis à jour avec la même version de la lib ou une supérieur, c’est celle-ci qui est réutilisée par défaut.

JSF 2.1 et 2.2

On passe ensuite à JSF 2.1 qui ne devrait pas présenter de grandes révolutions à part une configuration simplifiée (optionnellement sans XML) et du cache pour les composants Facelets.

JSF 2.2 devrait supporter nativement HTML 5

JMS

La spécification en cours est vieille plus de 6 ans. Une nouvelle version devrait voir le jour avec EE 7, présentant moins de complexité et proposant la standardisation d’extensions communes à plusieurs vendeurs.

La couche Web

Au delà de JSF, EE 7 devrait faire la part belle aux nouveauté pour la partie Servlet avec le support des Web sockets, une API Json en standard, le support d’HTML 5 et l’adoption de NIO 2 permettant le long pooling entre autre.

JPA 2.1

Les nouveautés sont beaucoup moins spectaculaires ici. Il faut dire que beaucoup de travail a déjà été accompli pour JPA 2.0. Néanmoins les ajouts évoqués par DeMichiel sont les suivants :

Ajout pour O/R Mapping and modeling

• Convertisseurs de types de données
• Profiles de fetch (pour sortir du simple Lazy ou Eager)
• Ajout de meta données pour le mapping
• Ajout des entités en read only

Concernant les API

• Ajout de nouveaux listeners
• Meilleur contrôle de la synchronisation du Persistence Context
• Support d’une définition dynamique de la Persistence Unit
• Detection des entités dirty
• Ajout de fonctionalités d’unwrap (la requête par exemple)

Ajout pour les Requêtes

• Support des procédure stockées
• Invocation de fonctions propres à la base
• Ajout de l’Outer Join avec des conditions ON
• Mapping entre JPQL et Criteria (importer un requête JPQL en crisserai par exemple voire l’inverse)

JPA 2.1 sortira avec EE 7 et en aussi en standalone pour s’intégrer à Java SE.  La JSR devrait être soumise cette année et l’EC devrait démarrer en janvier 2011.

JAX-RS 2.0

Cette nouvelle version est assez avancée puisque le draft de la JSR soumis le 12 Novembre et que normalement la finale devrait être soumise au JCP en décembre.

Les ajouts majeurs de cette nouvelle mouture seront :

• La livraison d’une API Client
• Un pattern MVC basé sur JSP et Scalate
• Des Interactions asynchrone à base d’atmosphere le streaming HTTP (comet, web socket et long pooling)
• Mieux s’intègrer au seine Java EE (convention over configuration)
• Meilleur support de @Inject (aujourd’hui c’est @Context qui est utilisé)

La séance s’achève sans réelle conclusion, je reste sur ma faim concernant les évolutions EJB et une date de disponibilité de EE 7.

Matt Raible comparing different web framework on the JVM

Cette deuxième session était animée par un vrai show man : Matt Raible qui nous propose une méthode pour choisir le bon framework Web pour nos projets. Je passe sur les nombreux Trolls sur JSF, Play! framework et Struts ainsi que sur le règlement de compte en règle avec Craig Mc Clanahan père de Struts et sec leader de JSF 1 qui a quitté le monde Java pour Rails en expliquant que le développement Web était trop compliqué sous Java, pour envenir à la présentation que voilà :

The Future Of Web Frameworks

View more presentations from Matt Raible.Matt propose donc une Matrice de comparaison des frameworks basée sur des appréciations “objectives” . Cette matrice propose un scoring des différents frameworks basé sur les critères suivants :

• productivité
• perception du dev
• courbe d’apprentissage
• santé du projet du framework
• dispo des développeurs
• le volume de jobs sur le framework
• Possibilité de templating
• Possibilité de création de composants
• Support d’Ajax mais pas intégré
• Existence de Plugins et add-ons
• Scalabilité
• Testing
• Possibilité de i18n and l10n
• Système de validation des formulaires
• Support Multi-language (Groovy / Scala)
• Doc & tutoriels dispos
• Livres dispos
• Support de REST
• Mobile /iPhone suport
• Niveau de risque

Cette matrice donne donc le top five suivants :

• Spring MVC
• Rails
• GWT
• grails
• Struts 2

L’audience réagi de manière mitigée : beaucoup de framework ayant été évincés. Pour ma part, le fait de n’avoir pas évoqué Seam dans le scoring ou d’évincer Vaadin sur des critères où on sait pertinemment qu’il est bon me parait décrédibiliser un peu son approche. Matt rattrape le coup avec une pirouette en expliquant que le meilleur framework est sûrement celui qu’on utilise.

Conférence sympathique mais un peu délibérément polémique.

Designing java system to operate at cloud scale par George Reese@GeorgeReese

L’objectif de la présentation était claire : nous en apprendre plus sur la mise en place du Cloud dans nos applications Java et les bonnes pratiques, bons outils à utiliser.

Il revient d’abord sur les différentes notions de Public IaaS, Public PaaS, ou encore Private IaaS. Quelle transparence, quelle sécurité me fournit chaque approche ? Comment appréhender la latence de ses composants ?

Le cloud oblige manifestement à suivre les bonnes pratiques :

• Pas de config en dur
• Pas d’état sur l’AppServ
• Utilisation éfficace des caches en front de la base de données.

RDBMS : ils proposent de bonnes solutions ! Intégritée des données, Migration de modèle de données, ACID. Elles peuvent monter en charge, tout dépend du design. NoSQL : pas un concept simple mais de multiples approches. Il faut faire le choix suivant chaque type de données, chaque type d’application, etc…

Chaque composant doit être capable de fonctionner avec plusieurs copies :

• Séparer la lecture de l’écriture ?
• Sharding doit être pensé avant l’implémentation
• Presistance des données le plus possible de façon distribuée

Reese rappel qu’il est nécessaire d’uutiliser d’une topologie réseau simpliste : le cloud ne support pas bien le broadcast et autres solutions habituelles de clustering des EJB par exemples. C’est cependant un domaine dans lequel on attend de bonnes avancées en 2011.  En clair faire une architecture simple et si ce n’est pas possible bine comprendre l’architecture du cloud dans lequel on publie.

Il faut également prêter attention au packaging

• séparer les binaires et les données
• minimiser le nombre de templates et d’images
• se plonger dans l’approche Dev/ops (infrastructure as code)

Il est également important de ne pas négliger les I/O réseau et disque qui pourraient avoir un impact sur les performances à l’avenir. Pour adresser ce problème on peut adopter une approche Hybride : les composants IO intensifs peuvent être sur une VM dans un cloud privé, et les IHM publiques peuvent plus facilement se positionner sur un cloud Public.

Reese nous rappelle ensuite que le Cloud est un monde hostile et il recommande les pratiques suivantes :

• Pas de mots de passes par défaut,
• utilisation de liaison et de filesystem chiffrés,
• limiter les relations de confiance implicites entre machines et utiliser un IDS (intrusion Detection System).
• Il faut partir du postulat que l’ensemble des composants externes de l’application sont compromis !

La platform cloud doit adopter le “Design For Failure”. en clair les composants doivent être pensés pour les planages :

• Redondance
• Automatiser le découverte et la reprise après plantage
• Tester son disaster recovery régulièrement
• Ne pas s’attacher à un seul vendeur de cloud.

Concernant Java et le cloud Reese donne les tips suivants :

• La mémoire se scale mal automatiquement
• utilisation de message queue pour communiquer entre les modules
• proscrire SAOP, RMI et EJB
• préférer le multi-threading au multi process

Voilà une présentation plus en forme d’introduction qu’un vrai retour d’expérience. Je ne me sens toujours par prête à partir à l’aventure sue EC2 ou Rackspace à la fin de la conférence.

Emergent Design par Neal ford

Le concept de base de l’emergent Design est qu’il existe des choses que nous ne pouvons pas connaître à l’avance et surtout des choses dont nous ne savons même pas que nous les ignorons. Il est donc important de concevoir le design le plus tard possible (mais pas trop) pour répondre au mieux au besoin. On est, vous l’aurez compris dans la mouvance agile mais avec une perspective un peu différente de celle que l’on nous présente habituellement.

Je ne reviendrais pas sur cette présentation que j’ai beaucoup appréciée mais qui me semble difficile de résumer par écrit. Vous trouverez la présentation ci-dessous

Neal Ford Emergent Design And Evolutionary Architecture

View more presentations from ThoughtWorks Australia.Les idées que j’ai appréciée dans cette présentation sont liées à la dette technique et au fait que si elle n’est pas forcément mauvaise, elle doit être connue et son remboursement pris en compte dès le début. Pour rendre cette dette palpable, Neal propose de créer une série de graphe sur l’évolution de la complexité cyclomatique par ligne de code.

Neal finit sa conférence en expliquant comment analyser la dette technique d’un projet inconnu avec le ratio de complexité cyclomatique et l’afférente des classes (nombre de classes utilisant une classe). Par cette méthode, il explique comment il a trouvé des défauts de conception dans Struts 2.

Ainsi se termine cette journée riche en acronymes et en concepts complexes.