Tag :CDI

Architecture stateful vs stateless

Le 22 novembre, le Lyon JUG propose une soirée autour des architectures Stateful et Stateless. Deux équipes vont donc s’affronter sur le ring du Lyon JUG. Du côté Stateful, Antoine Sabot-Durand nous fera une présentation intitulée “Stateful is Beautiful”, revenant aux sources de Java EE (CDI, EJB 3…), le tout articulé autour d’une démo! Et du côté Stateless, on retrouvera Philippe Charrière et Loïc Descotte, tous les deux co-auteurs de l’ebook Play.Rules qui nous parleront donc des concepts des architectures Stateless à travers une démo basée sur Play Framework!. Pour vous mettre l’eau à la bouche, voici un interview des speakers : les mêmes questions ont été posées à chaque équipe (à part la dernière), et elles n’ont évidemment pas eu accès aux réponses de l’équipe adverse avant la diffusion de cet interview.

@antoine_sdAntoine Sabot-Durand est consultant et architecte Java EE chez Ippon Technologies. Il intervient sur toute sorte de missions : conceptions d’architecture applicative, audits d’applications existantes, formations. Il est également en charge de la capitalisation des savoir faire au sein de la société. Il a acquis une expertise sur Java EE et plus particulièrement sur EJB 3.X et CDI. Il est l’auteur de quelques articles ayant alimenté le débat sur les standards et les choix technologiques sur les développements Java comme “Les rendez-vous manqués de Spring” ou plus récemment une suite d’article sur Java EE 6. Il est également membre de l’Expert Group CDI 1.1 et technical Leader sur le module Seam Social du projet Open Source Seam 3. Vous pouvez suivre Antoine sur Twitter ou Google+.

@antoine_sdPhilippe Charrière s’est présenté lui-même comme suit : “Je suis “avant-vendeur” à Lyon chez Steria. Avant d’être “ingénieur informaticien” j’ai commencé à coder sur une TI57 (beaucoup ne doivent pas savoir ce que c’est, normal j’ai 42 ans (ça c’est geek)) et depuis la passion du code ne m’a plus quitté. J’ai fait différents métiers en passant par technico-commercial, développeur cobol, responsable informatique, chef de projet, architecte .Net (désolé), directeur de projet, responsable technique, avant-vendeur… et ce n’est certainement pas fini. Mais je n’ai jamais lâché “le code”, plutôt multi-techno, ça m’aide à faire des propositions commerciales qui tiennent la route et à la livrer avec des prototypes quand je peux. @Home, c’est Javascript, Coffeescript, Play!Framework, et tout ce qui touche au mobile (grosse passion pour les jouets Apple, mais bidouille aussi Android)”. Vous pouvez consulter le blog de Philippe ou le suivre sur Twitter ou Google+.

Loïc DescotteLoïc Descotte s’est également présenté lui-même : “JUG Leader à Grenoble (Alpes JUG) et développeur chez Kelkoo. Ce que j’aime particulièrement dans le métier/hobby de développeur c’est l’évolution permanente des technologies qui permet de découvrir sans cesse de nouvelles choses. Dès que j’ai un peu de temps j’essaie de parler un peu des frameworks que je teste sur mon blog CoffeeBean. J’ai découvert Play début 2010 grâce à une présentation de Guillaume Bort. J’ai tout de suite été séduit par la puissance, la simplicité de ce framework, qui contrairement a pas mal de ses concurrents côté Java (Wicket, JSF…) ne cherche pas à masquer les principes et le fonctionnement du Web.” Vous pouvez également le suivre sur Twitter ou Google+.

Cet interview a été préparé conjointement par Agnès CREPET et Cédric EXBRAYAT, deux membres de la team du Lyon JUG. Merci également à Cyril Lacôte de l’équipe du podcast Cast-IT pour son aide sur la relecture de cet interview.

Agnès & Cédric : Pour introduire un peu les concepts d’une architecture avec ou sans état, comment définiriez-vous ce qu’est un état ?

Loïc (Equipe Stateless): Dans une application il existe (presque) toujours un état. Lorsqu’on parle d’architecture sans état il s’agit souvent d’un raccourci pour dire qu’il n’y a pas d’état au niveau middleware (sur le serveur d’application par exemple). Dans ce contexte, l’état est un ensemble de données relatives à une session utilisateur à un instant t. Ces données peuvent comprendre les informations relatives à l’authentification et aux droits de l’utilisateur, un historique des actions effectuées durant cette session (sélection de paramètres d’affichage, sélection de produits sur un site marchand…)

Philippe (Equipe Stateless): Globalement, je dis “comme Loic”. plus spécifiquement, j’aurais tendance à “déshumaniser” le concept et à rattacher l’état à une page plutôt qu’à l’utilisateur, voire même de manière plus abstraite à une ressource (ex: client lourd à la place de la page). Et cet état existe côté client et côté serveur, pas forcément en même temps selon si l’on est en stateful ou en stateless :

  • en stateful : la page/client a un état, dont la représentation/(persistance ?) côté serveur est une session en mémoire quasiment au même moment
  • en stateless : la page/client a un état, dont la représentaion côté serveur est finalement très furtive puisqu’elle peut n’exister qu’au moment où l’on interroge le serveur.

Antoine (Equipe Stateful): Un état est une information temporaire gérée au sein d’une application pour un utilisateur donné ou l’application dans sa globalité. Cette information permet de conserver de manière transitoire des données concernant l’utilisation actuelle de l’application ou un statut d’avancement dans un processus donné de celle-ci.

Agnès & Cédric : Imaginez que vous atterrissiez sur une île déserte et que vous n’ayez la possibilité d’emmener avec vous qu’un seul framework Java de référence pour coder une application, lequel choisiriez-vous ?

Loïc (Equipe Stateless): Si on part du principe qu’il n’y a pas d’électricité sur une ile déserte, il va falloir faire le maximum de chose avec le temps de batterie qu’il nous restera sur notre laptop… Il nous faut donc un framework productif… ensuite je pense que vous vous doutez de la réponse ;)

Philippe (Equipe Stateless): perso, je préférerais partir avec un manuel de construction navale et une canne à pêche. Sinon je partirais avec SL4A sur android + moteur beanshell parce que j’aurais plus de batterie sur mon smartphone que Loic sur son netbook. (Bon, ok, je prendrais Play! aussi parce que je peux utiliser TextMate et que ça consomme moins de ressource)

Antoine (Equipe Stateful): Pour coder : Java EE 6, parce que c’est la solution permettant le plus de choix d’architecture : Stateful ou Stateless, webapp ou client lourd. Sinon la bibliographie Spring est plus volumineuse et avantageuse si on souhaite faire des feux de camp!

Agnès & Cédric : Selon votre approche préférée (stateful/stateless), comment “suivre” et contrôler l’activité d’un client sur mon site? En prenant le fameux exemple d’un client faisant une commande sur un site marchand: comment puis-je lier entre elles les requêtes HTTP d’un même client? Comment je persiste son panier?

Loïc (Equipe Stateless): Si on prend l’exemple de Play, pour lier les requêtes HTTP d’un même client on dispose d’un objet d’accès à la session d’un utilisateur dans les contrôleurs. Cet objet est initialisé à l’aide un cookie sur le navigateur. Ce cookie est signé et crypté pour des raisons de sécurité. Si on veut stocker le contenu d’un panier dans la session utilisateur, on a plusieurs possibilités. La solution la plus pratique et qui sera bientôt la solution la plus standard est d’utiliser les API de stockage côté navigateur fournies par HTML5.

Philippe (Equipe Stateless): Facile! Comme Loïc. Bon je détaille un peu. Pour lier et persister : localstorage (donc il faut faire du js) est une super solution, facile à mettre en oeuvre. Beaucoup l’associe à HTML5, mais en fait la notion de localstorage existait avant, et il existe différents types de localstorage : SQLite, local storage (key-value), DOM Storage, user-data (anciennes versions de navigateurs). Pour plus d’infos : voir cet article “5 Obscure Facts About HTML5 LocalStorage“. Pour les navigateurs plus vétustes, il y a aussi la possibilité d’utiliser les fonctionnalités de storage de flash, il est très facile de discuter en js avec actionscript (et inversement). Pour les inquiets du JS, il existe de très bonnes librairies qui encapsulent et abstraient tout ça, une des plus connues est lawnchair.js de Brian Leroux (de chez NitobiAdobe / Phonegap) et qui fournit tous les adapters nécessaires en fonction des navigateurs. Un des plug-ins lawnchair fait du clé-valeur avec la base SQLite embarquée qui est plus rapide que la version clé-valeur de base (ça s’utilise par contre de manière asynchrone avec des callbacks). C’est aussi intéressant de se coder la sienne au moins pour comprendre les concepts.

Antoine (Equipe Stateful): [Pour lier les requêtes HTTP :] en les stockant dans un contexte session ou mieux conversation. Pas de persistance explicite. Le panier reste en mémoire, il sera sérialisé en cas de besoin (charge importante). Si j’attends une durée de vie plus importante, je peux mettre un listener à la fin de la session pour le stocker explicitement.

Agnès & Cédric : Comment je contrôle la conversation web de mon client : comment gérer par exemple le bouton back du navigateur?

Loïc (Equipe Stateless): Le problème du bouton back du navigateur se pose beaucoup moins avec un serveur stateless. Le principe d’architecture stateless est fortement lié à celui d’architecture RESTful : avec des URL bien définies, n’importe quelle étape de la navigation doit être bookmarkable. Si on revient sur une de ces étapes, le fait d’avoir un serveur stateless fera qu’on ne risque aucune incohérence d’état sur le serveur : la page s’affichera toujours correctement quel que soit le contexte. Si vous avez déjà utilisé des frameworks comme JSF vous savez que ce n’est pas toujours le cas quand vous devez tenir compte de l’état du serveur.

Philippe (Equipe Stateless): Pour le bouton back, cela peut se gérer côté client : toujours avec le localstorage, une solution peut être aussi de faire une application ‘monopage’ (webapp) et de jouer aussi avec les api de gestion de l’historique du navigateur , des hashtags (window.onhashchange), …

Antoine (Equipe Stateful): Plusieurs stratégies en fonction du contexte :

  • Stocker l’état des vues précédentes pour gérer le back
  • Demander à JSF de générer des URL Rest avec prettyface
  • interdire au navigateur de cacher une page pour forcer son rafraîchissement
  • gérer correctement les erreurs d’incohérence entre l’état serveur et l’état client
  • Faire mon rendu en ajax : le bouton back me fera sortir de l’application

Agnès & Cédric : Est-ce possible de gérer plusieurs espaces de travail pour le client, à savoir plusieurs conversations avec la même application dans différents onglets de son navigateur?

Loïc (Equipe Stateless) : Je ne suis pas du tout expert sur cette question, le cookie de session étant partagé entre les différents onglet (du moins sous Firefox et Chrome), en principe on ne peut pas avoir plusieurs sessions en même temps avec ce procédé. Après avec Play tout est possible, on peut très bien se contenter de créer une session côté client, encore une fois avec local storage, et associer une session à une instance de page à l’aide de JavaScript.

Philippe (Equipe Stateless): avec le module Secure de base de Play, ça va pas le faire (perso j’utilise différents navigateurs, ou mode incognito) pour les raisons expliquées par Loic. Quelles solutions ? -> faire sa propre solution d’authentification et passer des infos dans la requête (bof) -> faire avec -> quand tu es connecté sous google tu ne peux l’être qu’avec un seul user -> on perd en souplesse, on gagne en sécurité.

Loic (Equipe Stateless): En dernier recours il existe aussi des plugins pour les navigateurs qui permettent d’avoir des sessions distinctes dans différents onglets via une manipulation des cookies (voir exemple).

Philippe (Equipe Stateless): pour l’aspect “plusieurs espaces de travail” : le localstorage peut prendre plusieurs formes :

  • accessible par l’ensemble des onglets du navigateur (ou par plusieurs instances du navigateurs), bon ok dans le cas de 2 navigateurs de marques différentes, faudra faire plus classique (on parle de localstorage)
  • accessible uniquement sur la page en cours et uniquement pendant la session (on parle de sessionstorage)

Antoine (Equipe Stateful): Yep, CDI contient un scope conversation permettant de faire ça. Apache CODI l’étend en permettant de gérer des sous conversations (mise en pause d’une conversation, lancement d’une autre)

Agnès & Cédric : Puis-je définir facilement un workflow obligeant mon client à enchaîner plusieurs écrans pour une conversation donnée (le paiement par exemple)?

Loïc (Equipe Stateless): Pour gérer un workflow de navigation, il y a tout ce qu’il faut aujourd’hui dans les librairies côté client pour faire ça. On peut enregistrer les différentes étapes et y revenir avec l’history API HTML5 par exemple.

Antoine (Equipe Stateful): Concernant le worklfow, actuellement il existe à ma connaissance trois solutions stateful gérant ce besoin :

Si tout ça ne convient pas, on peut déjà faire deux ou trois trucs avec le fichier de navigation JSF, mais ce n’est pas vraiment une machine à état.

Agnès & Cédric : Comment sont classiquement démarquées vos transactions (base de données) au sein de vos applications? Quelle est dans la majeure partie des cas la durée de vie de la transaction ?

Loïc (Equipe Stateless): La durée de vie de la transaction est liée à celle du cycle de la requête HTTP : si une erreur survient lors du traitement d’une requête, tout ce qui s’est passé entre la demande du client et l’envoi de la réponse est annulé (rollback). C’est un moyen de rendre atomique chaque traitement lié à une requête. Il n’y a pas besoin d’utiliser un pattern du type open session in view, avec ce procédé on accède à nos objets (et mêmes aux éléments à charger en “lazy”) durant tout le traitement de la requête, quelle que soit la couche dans laquelle on se trouve.

Philippe (Equipe Stateless): ben je crois que Loïc a répondu à la question!

Antoine (Equipe Stateful): Par défaut la durée de vie d’une transaction est liée à la requête HTTP. L’utilisation de l’extended persistence context permet de retarder la transaction après plusieurs écrans (un wizard).

Agnès & Cédric : Comment une architecture (avec/sans) état, répond elle aux problématiques de scalabilité, et de reprise sur activité en cas de panne ?

Philippe (Equipe Stateless): Pas d’état conversationnel : le serveur ne conserve aucune information entre 2 requêtes différentes d’un même client, du coup la 1ère requête pourrait être traitée par un serveur A, la 2ème par un serveur B, etc. … Mon “identité” existe côté client uniquement, donc on pourrait même imaginer que le serveur soit coupé entre les 2 requêtes.
-> côté serveur : pas de mémoire utilisée pour les sessions -> pas de problème de synchronisation de sessions entre plusieurs serveurs.

Loïc (Equipe Stateless): Il est plus simple d’assurer la scalabilité avec une architecture sans état : rien n’est partagé entre les serveurs. Si on veut ajouter un serveur derrière notre loadbalancer pour monter en charge on évite ainsi tout le paramétrage lié aux sessions que l’on trouve avec les architectures stateful : mise en place d’un cache de session distribué, duplication de sessions ou encore affinité des utilisateurs à un seul serveur… Pour gérer les pannes c’est également plus simple, si on coupe un serveur, l’utilisateur pourra continuer sur un autre serveur sans qu’on ait à se demander comment il va récupérer l’état qu’il avait stocké sur le premier serveur.

Antoine (Equipe Stateful): En stateful, la scalabilité c’est le cluster, mais c’est un sujet très vaste et souvent regardé que du point de vue du serveur d’application et pas de la base de données. La tolérance de panne est également assurée par le cluster bien que l’architecture de l’application soit primordiale pour limiter la perte d’information lors du basculement. Le sujet de la résilience des applications est également vaste.

Agnès & Cédric pour l’équipe “Stateless” : commençons par une question naïve : Quelle est la bonne pratique pour gérer la sécurité de l’application ? Où est stocké l’état si nécessaire ? Purement en base de données, purement côté client ?

Philippe (Equipe Stateless): Différentes solutions, oauth (f… je ne sais pas le prononcer) openid, … Play est fourni avec une “basic authentication”, il suffit de passer en mode SSL pour “renforcer” la mécanique. On peut aussi utiliser une “digest authentication” dans ce cas là, il faut se faire sa propre mécanique ou utiliser openid.

Loïc (Equipe Stateless): L’état doit être stocké sur le client, cette information doit être de taille minimale (loggé ou pas + rôle de l’utilisateur). C’est ce qui se passe lorsque vous êtes loggés sur GMail par exemple. Ceci n’empêche pas le mécanisme d’authentification d’être robuste (ex : oAuth, https…). Pour rappel le cookie de session est signé et crypté.

Agnès & Cédric pour l’équipe “Stateful” : Est-ce simple de tester une webapp stateful ?
Antoine (Equipe Stateful): Aujourd’hui oui grâce à JBoss Arquillian. J’en ferais une démo lors de ma prez

Merci Antoine, Loïc et Philippe!

Les inscriptions pour leur session au Lyon JUG le 22 novembre sont ouvertes! Rendez-vous sur le site du Lyon JUG.

Rejoignez nous à l’Avant Jug de Juin !

La prochaine soirée du ParisJUG aura lieu Mardi 14 juin à l’ISEP : Pete Muir (leader du développement de la spécification CDI 1.1) viendra nous présenter CDI (Contextual Dependency Injection) et les Managed Beans dans la plateform Java EE6. Peter nous montrera comment faire de l’injection de dépendance sans Spring en utilisant des annotations comme @Inject. Pour en savoir plus sur CDI n’hésitez pas à lire l’interview de Peter par les Duchess.

Comme les mois précédents, nous organisons l’AvantJUG, la rencontre précédant le ParisJUG, au Café Vavin (18, Rue Vavin, 75006 Paris) à partir de 18h30.

Nous vous rappelons que l’AvantJUG, comme tous les événements organisés par Duchess, n’est pas réservé uniquement aux filles. Nous vous attendons donc toutes et tous pour faire connaissance et discuter autour d’un verre.

Attention !
Pour des questions d’organisations, n’oubliez pas de nous prévenir de votre venue et si vous êtes accompagnés ou pas par mail à duchessfr(at)gmail(dot)com au plus tard le Mardi matin. Cela nous permettra de passer un bon moment en toute sérénité.

A la découverte de CDI : rencontre avec Pete Muir

@plmuirLe 14 juin prochain, le Paris JUG propose une soirée autour de CDI. Le speaker, Pete Muir, n’est autre que le leader du développement de la spécification CDI 1.1 (disponible sous GitHub, la classe!). Actuellement employé par Red Hat Inc. Pete travaille également sur Infinispan, un data grid open source écrit en Java. Auparavant, Pete gérait les projets JBoss Seam et Weld, il est également le fondateur du projet Arquillian. Pete a travaillé sur plusieurs spécifications dont JSF 2.0, AtInject (JSR 330) et CDI. Il est un speaker régulier des JUGs et conférences comme Devoxx, JAX, JSFDays et JBoss World.
Sa session au Paris JUG se déroulera en deux parties. La première sera dédiée à CDI (JSR 299) et aux Managed Beans, spécifications introduites dans Java EE 6 : quand et comment utiliser CDI et les EJBs dans le développement d’application? Pete abordera également la perspective de Java EE 7 et de CDI 1.1. La deuxième partie de sa session sera dédiée aux extensions CDI. Vous découvrirez ainsi comment il devient très facile d’écrire et d’ajouter des fonctionnalités s’exécutant dans n’importe quel conteneur supportant la JSR-299.

Cet interview a été préparé conjointement par Audrey NEVEU, Agnès CREPET et Antoine SABOT-DURAND

Audrey, Agnès & Antoine: CDI 1.0 est en grande partie la standardisation de Seam 2. Quand et comment avez vous décidé d’en faire une JSR et quel fut le travail nécessaire pour réaliser cette spécification ?
Pete: Pour moi CDI n’est pas “en grande partie la standardisation de Seam 2”. Je pense qu’il a reçu les influences de Seam 2 (contextes, événements) et de Guice (injections de dépendances type-safe, cycle de vie des événements) à parts égales, de même que d’autres frameworks comme Spring.
Nous avons décidé de déposer la JSR car à JBoss / RedHat nous croyons fermement au fait de retirer les verrous commerciaux et au fait de fournir la portabilité des applications . Cette influence se retrouve dans plusieurs domaines comme le prouve notre engagement dans le JCP (CDI, Bean Validation), OSGI et le cloud. Quand nous avons développé Seam, nous trouvions qu’il manquait à Java EE un modèle de programmation puissant, moderne, qui viendrait en complément des services fournis par les EJB et que cela réduisait la portabilité des applications, et nous avons décidé d’y remédier.
Nous sommes vraiment heureux du succès rencontré par CDI et enthousiastes de prendre part à la réalisation de Java EE 7. C’est agréable pour nous de voir que CDI est perçu comme puissant et moderne par la communauté.
La JSR a été déposée il y a 5 ans environ et c’est déjà beaucoup de travail investi dedans. Gavin King, spec lead pour CDI 1.0, a travaillé sur CDI environ 18 mois à temps complet. Red Hat a aussi produit une implémentation de référence (Weld) et un Technology Compatibility Kit sur lequel j’ai travaillé 18 mois environ avec une équipe à temps partiel qui de son côté, a aussi travaillé 18 mois en tout. Depuis que j’ai repris le rôle de spec lead pour CDI 1.1, Ales Justin a pris le lead sur Weld et sera responsable de son implémentation dans CDI 1.1.

Audrey, Agnès & Antoine: D’après vous, quels sont, s’il y en a, les obstacles majeurs à l’adoption de CDI ?
Pete: Je pense que, comme avec toutes les nouvelles technologies, l’une des premières difficultés pour l’adoption de CDI a été la documentation, les tutoriels et les guides. C’est pourquoi je suis heureux de voir l’apparition d’initiatives telles que CDISource. Une autre barrière a été la disponibilité de serveurs d’applications certifiés Java EE mais là encore, les obstacles ont été réduits depuis l’année dernière, avec par exemple la sortie de JBoss AS 6 à Noël. JBoss AS7 qui est annoncé pour le mois prochain sera particulièrement attractif pour les développeurs avec un temps de démarrage de 3s.

Audrey, Agnès & Antoine: Il y a plusieurs points d’entrée pour l’injection en CDI : champs, constructeur, setters. Avez vous des recommandations pour chacun d’entre eux ? L’introduction de logique métier est possible avec les constructeur et setters, mais pas avec l’injection par champs, est-ce la seule différence ?
Pete: Mon préféré est l’injection par construction car il permet de créer un objet immutable, ce qui est une des clés techniques pour la programmation concurentielle, qui est quelque chose qui devient de plus en plus important aujourd’hui.
L’injection par champs est préférée par certain car elle est un peu plus propre (pas besoin d’injecter manuellement le constructeur) et qu’elle produit elle aussi un objet immutable, du moins tant que le développeur est discipliné et qu’il ne modifie pas la valeur de l’attribut dans son code.
L’injection par setter peut être utile pour ajouter CDI à du code legacy où ce design pattern a déjà été utilisé, mais je le n’utiliserai en aucun cas dans un nouveau projet.
Enfin, comme vous le disiez, l’injection par constructeur et par setter offre également la possibilité d’insérer de la logique métier lors de l’injection.

Audrey, Agnès & Antoine: Pouvez vous nous expliquer comment vous avez amélioré Weld, l’implémentation de référence pour CDI, au sujet de l’usage de la mémoire, du temps de démarrage et des performances au runtime ?
Pete: Nous avons apporté d’importantes améliorations à Weld et nous constatons maintenant que les performances au runtime sont aussi bonnes que celles d’autres implémentations de CDI ou que d’autres frameworks d’injection de dépendances. Pour ce qui est de l’usage de la mémoire et de l’optimisation du temps de démarrage, nous y avons également consacré du temps mais nous n’avons pas fini pour le moment : nous pensons pouvoir réduire encore l’usage de la mémoire par dix.

Audrey, Agnès & Antoine: Comment avez vous prévu de travailler avec les autres implémentations de CDI : Candi et Open Webbeans ?
Pete: Nous sommes assez proches des membres de ces équipes : les deux participent activement au groupe d’experts de CDI 1.1. Comme nous venons tous du monde de l’opensource, nous sommes habitués à partager notre travail et à nous engager dans la communauté. En pratique, trois équipes d’implémentation collaborent pour améliorer le Technicology Compatibility Kit et discutent au sujet de la spécification. Nous collaborons aussi pour promouvoir CDI de temps en temps : nous avons d’ailleurs proposé quelques sessions en commun à JavaOne cette année.

Audrey, Agnès & Antoine: Vous êtes le leader de la spécification CDI 1.1 qui semble résoudre certains des problèmes rencontrés par CDI 1.0 et standardiser quelques unes des extensions les plus populaires de CDI amenées par la communauté. Pouvez vous nous donner des exemples de ceux-ci ?
Pete: Nous avons identifié trois types de problèmes : des bugs dans la spécification (des erreurs de conception), des besoins de clarification nécessaires (des contradictions dans la spécification ou des implémentations qui ont pris différents chemins) et des nouvelles fonctionnalités, qui sont le plus gros du travail, la majeure partie des bugs et des clarifications ayant déjà été traités. Quelques uns des plus gros problèmes que l’on nous remonte est de revoir l’activation et l’ordre des interceptors, decorators et alternatives, qui contrôlent quelles classes sont scannées.
Nous sommes également en train de nous intéresser à la standardisation de quelques extensions inspirées par les projets de la communauté tels que Seam Solder et MyFaces CODI comme handlers de service.

Audrey, Agnès & Antoine: Le JCP a annoncé à la fin d’avril que la spécification de CDI 1.1 avait reçue une approbation quasi unanime : tout le monde ayant voté oui, excepté VMWare qui n’a pas voté. Quelles sont vos relations de travail avec les gens de VMWare ? Quelle est votre analyse sur le long commentaire fait par IBM sur ce vote ?
Pete: Je ne peux pas vraiment m’exprimer sur l’inactivité de VMWare dans le JCP, nous essayons plutôt de travailler avec IBM sur CDI, car ils nous avaient déjà apporté leur aide sur la version 1.0. Ils avaient quant à eux déclaré que la proposition pour CDI 1.1 inclue un nombre d’améliorations qui sont souhaitables mais dont certaines nécessiteraient un traitement externe à CDI. Les intercepteurs par exemple ne sont pas spécifiques à CDI, ils devraient être considérés comme un problème relatif à la plateforme dans son ensemble ou bien comme une mise à jour à rajouter à leur propre spécification. Pour IBM, faire fonctionner des fonctionnalités déjà implémentées est plus important qu’en ajouter de nouvelles et c’est pourquoi ils auraient été contraints de voter non si ces remarques n’avaient pas été prises en compte.
Red Hat a approuvé cette déclaration et inclu ces éléments dans la proposition pour CDI 1.1 sous un avertissement des spec lead Java EE précisant que nous devrions relever les problèmes qui concernent également d’autres technologies Java EE. Nous pourrons ainsi les affecter correctement au fur à et mesure des progrès de la spécifications de Java EE 7. Nous sommes également d’accord avec IBM que l’alignement avec d’autres JSR est important (la proposition inclue un certain nombre d’éléments avec lesquels s’aligner) et attendonc avec impatience de travailler avec IBM à résoudre les problèmes qu’ils pourraient nous faire remonter.

Audrey, Agnès & Antoine: Avez vous ressenti des changements dans le JCP depuis qu’Oracle a racheté Sun ?
Pete: Pas pour le moment, mais je ne suis pas impliqué dans les activités du Comité Executif du JCP.

Audrey, Agnès & Antoine: Y a t’il quelque chose de prévu pour fédérer tous les contributeurs de l’écosystème autour de CDI (Seam 3, Codi, CDI Source par ex.) afin d’assurer l’intéropérabilité et éviter le développement en double d’extension ?
Pete: Nous n’avons pas de projet de la sorte et nous sommes persuadés que la compétition dans l’écosystéme reste une bonne chose pour amener de l’innovation. Cependant, nous voulons garantir l’intéropérabilité et la meilleure façon de le faire, c’est de s’assurer que CDI offre les facilités nécessaires pour développer des extensions qui intéragissent au dessus de lui et pas à travers ses propres interfaces. Nous encourageons d’ailleurs toute personne qui rencontre des problèmes de la sorte à les faire remonter, de façon à ce que nous puissions les prendre en compte pour CDI 1.1.
Il y a aussi des rumeurs à propos de JSRs qui auraient été proposées pour standardiser des fonctionnalités qui viendraient au dessus de CDI (pour la sécurité par exemple).

Audrey, Agnès & Antoine: Est il prévu d’intégrer des modules CDI (Seam Solder ou Seam configuration par ex.) dans la spécification, et si oui, lesquels ?
Pete: Nous réfléchissons à standardiser certaines fonctionnalités développées dans Solder, cependant de manière générale nous pensons que si une extension peut être développée facilement, il n’y a pas de réel besoin pour la spécification de se s’en mêler car cela risquerait d’étouffer l’innovation.
Il faut se souvenir que le but premier pour la standardisation de CDI était de produire des applications portables, et les extensions n’empêchent pas ça !

Audrey, Agnès & Antoine: L’instantiation de Bean étant déjà possible au runtime, pensez vous qu’il soit possible que CDI évolue de façon à permettre aussi l’enregistrement de Bean au runtime ? Avec cette possibilité, nous serions capable par exemple de créer un bean avec Groovy, comme nous le faisions avec Seam 2.x.
Pete: Les langages dynamiques deviennent de plus en plus populaires et il est important que CDI soit compatible avec eux. Seam 2 offrait la possibilité de “redémarrer partiellement” le container pour les classes Java et Groovy, une partie seulement des beans étaient redéployés. CDI a une validation du graphe de dépendances beaucoup plus stricte, ce qui autoriserait une solution plus complète : CDI pourrait ainsi voir quels beans sont affectés par des changements et ne redéployer que ceux là. L’expérience montre que les gens ont tendance à construire des modèles fortement interconnectés (il est très difficile de parvenir à construire des modèles efficaces et utiles sans qu’ils aient de nombreuses interconnexions) ce qui ferait qu’un tel redémarrage causerait le redéploiement de la quasi totalité de l’application. Bien sûr vous pouvez continuer à utiliser des classes Groovy avec CDI, vous ne pourrez juste pas changer les classes au déploiement.
Nous n’avons pas prévu d’ajouter quoi que ce soit là dessus à la spécification pour le moment et je pense personnellement qu’il est préférable de le laisser pour l’instant comme une implémentation à rajouter. Nous avons prévu d’expérimenter une fonctionnalité comme celle ci dans Weld (notez au passage que c’est un outil orienté SPI (Service Provider Interface), et non un utilisateur orienté SPI !) Il y a aussi quelques alternatives : l’excellente équipe de Serli travaille avec nous et les équipes d’experts OSGi de JBoss pour tenter de définir comment CDI et les services OSGi pourraient interagir, ces derniers permettant le redémarrage partiel de votre application. JRebel travaille déjà avec Weld et si nous fournissons une API de redémarrage partiel, il n’y a qu’eux que ça pourrait aider. JBoss AS 7 quant à lui a un temps de démarrage vraiment minime (2.3s) ce qui réduit le besoin de redémarrage partiel.
En conclusion, il est important de signaler que TorqueBox, le projet de JBoss, qui propose Ruby on Rails avec la puissance de JBoss AS, supporte CDI, ce qui offre la possibilité d’injecter vos services CDI écrit en Java dans Ruby, pour ceux qui veulent tester ce langage.

Audrey, Agnès & Antoine: Avec tous les progrès de CDI 1.1, est il plausible d’imaginer que de nombreuses personnes vont délaisser le container d’ejb dans le futur ?
Pete:EJB offre un set de “entreprise services” essentiels tels que la déclaration des transactions donc je ne vois pas le besoin de s’en débarrasser. Cependant ce que je vois, c’est un mouvement vers cette idée que les services EJB peuvent être appliqués à chaque bean managé, et pas seulement les EJB; les EJB et CDI seront ainsi dans la continuité l’un de l’autre. Red Hat encouragera certainement cette décision et je suis impatient de voir cela avoir lieu pendant le développement de Java EE7.

Merci Pete!

Les inscriptions seront ouvertes à partir du jeudi 9 juin 7H00! Rendez-vous sur le site du Paris JUG

En continuant à utiliser le site, vous acceptez l’utilisation des cookies. Plus d’informations

Les paramètres des cookies sur ce site sont définis sur « accepter les cookies » pour vous offrir la meilleure expérience de navigation possible. Si vous continuez à utiliser ce site sans changer vos paramètres de cookies ou si vous cliquez sur "Accepter" ci-dessous, vous consentez à cela.

Fermer