Ce soir le dieu de l’informatique, le pigeon magique du JUG, le Duke ultime golden-platinum qui refait venir l’être aimé étaient tous aux abonnés absents.
Panne de vidéo projecteur, panne de micro (c’est une contrepèterie) et donc bilan mitigé.
En première partie, Sacha Labourey le CTO de JBoss, une division de RedHat effectue une présentation sur JBoss AS 5.0. En deuxième partie, présentation de JBoss Seam par Malik Saheb. Le tout devant 200 personnes, la salle étant comble comme la fois précédente.
Sacha Labourey présente d’abord un petit historique de JBoss Application Server. A ses débuts en 2000 la volonté des développeurs est de proposer un serveur d’app plus léger, avec la possibilité de recharger à chaud une application sans relancer le serveur. Pour cela l’architecture du micro-kernel basée sur JMX permet de gérer le chargement des ressources d’une application. J’en ai parlé en 2006 lors de ma formation à JBoss à Berlin. 4 articles du touilleur vous donneront un petit aperçu du moteur de JBoss si vous souhaitez vous faire votre propre idée.
Sacha enchaîne ensuite avec une justification sur la prochaine version de JBoss, JBoss AS5. En ligne de mire, la certification EE5, une infrastructure plus souple et plus puissante pour le clustering, une offre de messaging qui ne sera plus basée sur JBoss MQ mais sur JBoss Messaging, une réécriture de la couche Web Services avec les dernières innovations de JEE 5.
L’un des objectifs de JBoss Application Server 5 est de s’affranchir du kernel basé sur JMX. Là où il y a quelques années, JMX était la solution pour connecter différents modules, aujourd’hui entre OSGI et l’injection de dépendances, Sacha explique que le nouveau moteur est basé sur des POJOs, accompagnés d’annotations. C’est donc un énorme travail de réécriture et de migration de code qui a entrainé le retard de la sortie de JBoss AS 5.
Quand sort JBoss AS 5 GA ?
Si l’on regarde JBoss 5, cela fait 3 ans que ce chantier a été lancé. La sortie est prévue dans les semaines qui viennent, vraisemblablement avant Noël. Le temps passé à écrire cette nouvelle version permet d’offrir une version plus mature de JBoss. Il faut se souvenir qu’il y a presque 3 ans, JBoss AS était l’un des premiers serveurs à offrir le support des EJB3 en l’état. La RC2 de JBoss AS 5 a été certifiée EE5 début septembre.
Parmi les nombreuses nouveautés que Sacha nous présente dans ces slides, j’ai noté une nouvelle API de configuration, un nouveau moteur d’injection, une gestion des aspects, et beaucoup d’autres fonctionnalités.
OSGI ?
Sacha explique qu’OSGI ne donne pas tout. Il n’y a pas de gestion de classe unique, ni de gestion des méta-données. Enfin même si OSGI permet le rechargement partiel d’une application, il n’y a pas la notion de graphe d’état :INITIALIZING, RUNNING, STAND-BY…
A la question « mais où est le marché pour ces besoins ? » la réponse est assez floue. Là où Spring dm Server nous promet de répondre à des soucis que nous n’avons pas encore, je pense que JBoss passe encore une étape supplémentaire vers le « on n’en n’a pas besoin mais c’est intéressant »…
J’ai ensuite bien aimé une partie de la présentation de Sacha, qui est un orateur très intéressant et qui a vraiment séduit le public du JUG. Il explique par des chiffres le fait suivant : les éditeurs de serveur d’application J2EE se réduisent de version en version.
– sur Java J2EE 1.2 : 18 serveurs d’application différents
– sur la version 1.3 : 22 serveurs d’app
– sur la version 1.4 : 17 serveurs d’app
– sur la version EE5: 10 serveurs d’app
– sur la future EE6 : 7 (IBM, Oracle, SUN, SAP, NEC, Kundlee et ITMakeSoft)
Vous notez comme moi l’absence de Spring. Va savoir pourquoi.
Comme Sacha l’explique, le marché des serveurs d’application est maintenant mature, d’où cette consolidation. La guerre est terminée. Quoique…
Il présente ensuite la démarche de RedHat. JBoss AS est, et restera open-source. La politique de licence n’a pas changée. Open-source et open-standard. La version Enterprise offre une version industrielle indispensable pour mettre en production une application. Il est utopique de penser qu’aujourd’hui un client final met en production une version sans prendre du support. Ceci non pas pour des raisons techniques, mais avant tout pour des raisons… légales. Thomson-Reuters où j’ai travaillé 5 ans 1/2 a signé un partenariat avec RedHat afin que les versions des produits basés sur JBoss comme KGR s’appuient sur le support de RedHat en cas de problèmes avec JBoss AS… afin d’assurer les clients finaux de la pérennité du socle technique.
La version enterprise est supportée pendant 3,5 ou 7 ans. Les versions sont testées de manière intensive, et le support basé à Neuchatel permet à RedHat d’offrir une qualité de service indispensable aux équipes de production. J’ai eu le plaisir de discuter avec Luc Texier que j’ai déjà rencontré en juin 2006, à propos du support et du travail de RedHat.
La version Enterprise Application Platform (EAP) est strictement identique à la version open-source de JBoss, JBoss Application Server.
EAP offre en plus d’autres outils pour les équipes de production comme JBoss ON, outil de supervision et de monitoring. Pour les esprits grincheux, il existe aussi JOPR, outil libre et open-source qui est l’ancien JBoss ON, fruit d’un travail commun avec Hyperic.
Sacha Labourey présente ensuite avec différents slides l’architecture de JBoss AS 5. C’est assez technique et trop long à raconter ici. Je retiens simplement l’ajout d’un Virtual FileSystem qui permet de créer virtuellement un EAR lors des tests par exemple.
Les questions de l’assemblée tournent autour d’OSGI, des synergies entre les équipes de RedHat et les équipes de JBoss. Quelqu’un demande pourquoi ne pas standardiser le micro-kernel de JBoss ? Sacha répond que si la demande de la communauté est là, ils y travailleront. Il rappelle qu’Hibernate est sorti avant JPA, que Seam est disponible depuis 2006 et une partie de Seam est maintenant une JSR, la JSR WebBeans. Donc la démarche est plutôt : utilisons la technologie puis ensuite regardons comment en faire un standard.
Contrairement à Spring, il dit clairement que pour lui les standards ont quelque chose de bien, ils évitent le syndrome « vendor-lock ». Je vous laisse apprécier son point de vue, que je partage en partie.
A une question sur « mais pourquoi autant de retard sur AS5 ? » il explique que la réorganisation du code source avec des équipes réparties dans le monde ne facilite pas ce travail. Imaginez que le noyau Linux décide de changer de la version 2.6.0.1.2.3.4.3402.beta1 à une version 3.0….
Enfin Sacha donne 2 informations intéressantes :
– regardez le blog de Bob McWhister’s http://oddthesis.org/ qui vous donne des nouvelles sur les discussions et les recherches de Bob
– mod_cluster est un connecteur http dont Sacha parle sur son blog. Je reprends ici la présentation de mod_cluster
mod_cluster is an httpd-based load balancer. Like mod_jk and mod_proxy, mod_cluster uses a communication channel to forward requests from httpd to one of a set of application server nodes. Unlike mod_jk and mod_proxy, mod_cluster leverages an additional connection between the application server nodes and httpd. The application server nodes use this connection to transmit server-side load balance factors and lifecycle events back to httpd via a custom set of HTTP methods, affectionately called the Mod-Cluster Management Protocol (MCMP). This additional feedback channel allows mod_cluster to offer a level of intelligence and granularity not found in other load balancing solutions.
Within httpd, mod_cluster is implemented as a set of modules for httpd with mod_proxy enabled. Much of the logic comes from mod_proxy, e.g. mod_proxy_ajp provides all the AJP logic needed by mod_cluster.
En conclusion, présentation sympa de la part de Sacha dans des conditions inhabituelles : problème de vidéo projecteur, d’ordinateur, d’écrans au fond ne fonctionnant pas… Chapeau pour avoir animé la présentation et réussi à faire passer le message : venez voir JBoss Application Server 5.0
JBoss Seam
Tout d’abord parlons du fond : présentation organisée par Malik SAHEB du framework léger d’assemblage, Seam. Malik est un senior solution architect qui vient du « back ». Il nous explique qu’il va présenter JBoss Seam d’un point de vue technique, en parlant de son expérience. Comme il le dit lui-même il vient du côté obscur, il a travaillé sur le moteur transactionnel de JBoss et sur les EJBs. Le monde du Web était donc pour lui un challenge.
Le constat est le suivant : JSF simplifie l’écriture d’application Web. Cependant il reste encore beaucoup de XML et de code technique pour accéder aux objets métiers et aux EJB3. Seam se propose dans un premier temps de simplifier le travail du développeur en apportant un moteur d’injection basé sur les annotations Java 5. Il évite d’ajouter des composants intermédiaires entre la vue et le modèle.
Ensuite Seam est un framework d’assemblage, qui offre et simplifie au développeur un socle technique assez impressionnant :
– AJAX, JSF, api RichFaces et IceFaces
– EJB3
– JPA
– BPM
Je vous donne l’adresse de la RefCard que Malik nous a présenté : Core Seam 2.1. La lecture de cette carte vous donnera une présentation complète et solide sur le coeur technique de Seam.
D’un point de vue fonctionnalité, Seam offre différents outils simples comme la génération de PDF, l’envoi d’email, l’internationalisation, la gestion du bouton back, de l’history, de REST, l’intégration de Wicket, de Spring, bref vous l’aurez compris : c’est un bus où tout le monde se trouve embarqué afin de faciliter l’écriture d’application.
Seam c’est ensuite des concepts novateurs comme l’introduction de deux scopes dans le domaine des applications Webs : le scope « Conversation » et le scope « Business ». J’en ai déjà parlé sur le touilleur, je vous redonne le lien afin de vous laisser lire cette partie tranquillement.
Seam c’est aussi un ensemble d’outils basés sur maven2 destiné à faciliter l’écriture et le démarrage d’une application. Tout comme Grails, Seam offre depuis 2 ans des outils pratiques pour créer une Entity avec ses pages CRUD, le tout en utilisant JSF+Ajax+une api comme RichFaces ou IceFaces. A noter que le support de GWT s’effectue aussi sans soucis, car Seam s’occupe de la partie serveur, là où GWT travaille sur votre poste.
Il y a aussi quelques fonctionnalités très bien intégrées comme la Validation (JSR-303) ou Hibernate Search, ce qui évite toujours de réinventer la roue.
Enfin Seam a aussi son moteur d’injection de dépendance et d’outjection… Un concept qui vous permet de replacer dans la session, dans la conversation ou dans le scope business un objet Seam. Si vous voulez, c’est un moyen très pratique pour gérer la persistance fine, au delà de la session HTTP qui reste assez pauvre. Dommage c’était très mal expliqué…
… et là mon cahier de note s’arrête …
Je suis sorti à la fin. Honnêtement, je vais me lâcher : présentation complètement ratée. Désolé Malik si tu lis cela, mais il y a plusieurs griefs que je vais justifier. Les gens qui lisent le touilleur savent très bien que je suis un fan de Seam, donc on est d’accord que je ne parle que de la forme et pas du fond de la présentation.
Sur la forme : pas de chance avec ce @#$ de vidéoprojecteur, il était impossible de lire correctement les exemples de code. Et là je parle de ma pomme, assis à côté de David qui filmait pour le JUG la session. Vraiment il faut peut-être revoir le template du Paris JUG et basculer sur un template avec un fond noir et du texte blanc, comme Devoxx. A tester au prochain JUG.
Ensuite Seam est un framework qui ne se démontre pas en listant ses fonctions, ce qu’il propose et s’il fait la pluie ou le beau temps. En tant que développeur j’aurai vraiment aimé avoir une présentation partant d’un cas concret, afin que pendant l’heure je puisse me faire ma propre idée de ce que je pourrai faire ensuite avec Seam. C’est un format plus adapté je pense pour faire passer le message.
Enfin carton rouge pour pas mal de points : je n’ai pas entendu le nom de la personne qui a initié le framework Seam. Dommage car je pense que l’assemblée aurait aimé entendre que Gavin King, monsieur Hibernate, est l’auteur de Seam. Mince c’est pas un truc que l’on oublie de dire.
J’aurai aimé aussi avoir une présentation de quelques minutes sur la différence entre Seam et la JSR-296, Web Beans, toujours initiée par le même Gavin King. Cela aurait mis en avant les éléments couverts par Seam, qui travaille sur un scope plus large que la spec JSR-296.
Bref très déçu, j’ai peur que l’assemblée présente n’ait plus/pas envie d’aller tester Seam.
Alors je pense qu’il faudra en remettre une couche, c’est pour cela que je suis motivé pour vous refaire une présentation sur le blog, à la mode de ce que j’ai envie de vous raconter.
Donc stay tuned.
Conclusion
Soirée au final sympa. Au Paris JUG nous croisons toujours pas mal de monde, c’est l’occasion de faire des rencontres et de voir ou revoir de nouvelles têtes. J’ai bien discuté avec Thomas Parle de Prima Solutions, nous avons aussi parlé beaucoup avec David Dewalle.
Enfin il est important que les sponsors continuent à apporter au Paris JUG toute l’énergie financière nécessaire afin que le JUG continue dans de bonnes conditions. David ne pensait pas qu’en 3 mois le JUG passerait de 30 à 200 personnes chaque mois…
Voilà pour mon compte-rendu, pas eu envie de vider mon sac hier soir tard et de me lancer sur l’écriture d’un long billet. Donc là vous avez la version courte… à peine 2240 mots. Une paille..
A la semaine prochaine à Devoxx !!!
Des articles plus ancien sur JBoss Seam du Touilleur :
– Convertissez vous à JBoss Seam mes frères
– JBoss Seam 2.0 premiers tests
– JBoss Seam : l’intérêt du scope CONVERSATION
– Installer JBoss Seam (article sans doute dépassé)
– Présentation de Luc Texier de JBoss au PJBUG
Effectivement, les dieux du JUG se sont retournés contre nous.
En tant que JUG Leader, la soirée d’hier a été mitigée :
* Déjà, ça commençait mal avec le vidéo projecteur. Ensuite, les télés qui ne fonctionnaient pas, puis une engueulade avec la sécurité pour qu’ils nous laisse 15 minutes de plus (quitter à 22h45 au lieu de 22h30)
* Une salle trop pleine. Ormis les pb de sécurité que commence à nous rappeler l’ISEP (la salle est taillée pour 180 personnes), ce n’est pas agréable de voir des gens debout ou mal assis.
* Pas assez de temps pour pauser les questions
* Pas le temps de distribuer nos goodies
* Tout ce stress nous a fait oublier de faire passer qques messages
* La salle buffet trop petite pour tout ce monde
…
Sinon, que du bonheur d’avoir un Sacha nous parler de JBoss et de papoter au Fastaff une bière à la main
Le JUG est-il victime de son succès ? 2009 nous le dira.
Salut Nicolas,
Ravi de t’avoir rencontré hier soir ! Ce fut bref, j’espère avoir l’occasion d’échanger à nouveau avec toi.
Ton CR de la soirée est excellent ! Je me permet de relever un point néanmoins 😉 OSGi a bien un lifecycle ! Celui des bundles:
– INSTALLED
– RESOLVED
– STARTING
– ACTIVE
– STOPPING
– UNINSTALLED
Sacha Labourey a surtout évoqué le fait qu’OSGi dans sa version actuelle, la 4, ne fourni pas de hooks permettant d’intercepter le fonctionnement du framework comme la recherche ou la publication d’un service.
Et bien, la prochaine version de la spec OSGi, la 4.2, qui en est aujourd’hui à son 2e draft traitera et incluera des SPI permettant non seulement d’écouter mais aussi d’influer sur le fonctionnement du framework. Il sera alors beaucoup plus simple de proxier des services ou encore d’intercepter les invocations des méthodes de services.
Aujourd’hui, un framework comme Newton par exemple, un framework OSGi distribué, est obligé de jongler pour pouvoir intercepter les invocations de services et les transformer en invocations distantes. Demain, il pourra simplement implémenter l’écouteur FindHook OSGi 4.2 pour renvoyer un proxy distant.
A la prochaine,
Cédric Vidal
http://www.linkedin.com/in/cedricvidal
PS: Le diagramme complet du lifecycle des bundles OSGi:
http://t-templier.developpez.com/tutoriel/java/osgi/osgi1/images/cycle-vie-bundle.png
Newton:
http://newton.codecauldron.org/
Pour ceux qui n’ont pas pu venir, malgré tout l’ambiance était sympa et Sacha a transformé sa présentation en un exercice cool et décontracté, c’était donc vraiment la malchance, mais pour le reste j’ai passé un bon moment.
Coté buffet j’ai mis au point une stratégie qui marche bien : derrière la grande table 🙂
Merci à Redhat pour le buffet.
Le débat est ouvert sinon : comment faire pour gérer 200 geeks passionnés en respectant les consignes de sécu ? et sans se faire jeter de l’ISEP ?
D’accord sur pas mal de points.
Quant à la présentation de code sur les slides, ou de démo « live » avec écriture et exécution de code :
– peut-être faudrait-il imposer un format pour le code Eclipse, qui permette de lire le code à la projection (taille des caractères notamment, mais aussi probablement limiter le nombre de colonnes sur lequel on écrit le code)
– il faudrait trouver le moyen, à côté des slides, de publier le code source présenté. C’est un peu frustrant de ne pas les avoir.
Sinon je regrette que Malik ait commencé sa présentation par « je viens de découvrir le truc mais vous allez voir c’est génial », ça tue un peu le reste, surtout si on fait une présentation très technique.
Enfin c’est vrai que le fait que Seam soit une invention de Gavin King est important. Ca veut dire que l’on va se faire insulter à chaque question posée sur le forum Seam. (ok c’était mon rant…)
Concernant la présentation JBoss Seam, pour les WebBeans, il y a une erreur. Il s’agit de la JSR-299 et non de la JSR-296.
Je ne suis pas complètement d’accord sur le retour fait sur la formation Seam donnée. La présentation de Malik était une présentation très courte. Il faut souligner qu’il a bien expliqué les principes d’unification apportées par Seam pour
l’intégration entre JSF et EJB. Couplé a la démonstration du concept de conversation, cela suffit pour comprendre l’intérêt de Seam. Ajouté avec la présentation de la possible intégration ave l’éventuel des composants de type Wicket, GWT, iText, …
ela suffit pour présenter Seam et se faire une idée de son fonctionnement.
De plus, si on est resté à la troisième mitant, on a eu l’occasion de discuter avec lui des différentes problématiques.
Et donc en conclusion, une très bonne soirée JBoss Seam pour ma part.
Je ne pense pas du tout que l’angle choisi par Malik ait été une erreur. J’ai trouvé cet angle (un framework vu par un « naïf » dans ce domaine, et non pas un expert auto proclamé) très original et qui aurait pu – ou dû – donner lieu à pas mal de choses intéressantes, vues par un oeil critique et qui s’étonne de tout.
Beau billet.
Une remarque néanmoins : je ne suis pas d’accord sur l’importance de créditer Gavin King de la paternité de Seam.
Même le créateur d’Hibernate peut se tromper, et un framework génrial peut être créé par un parfait inconnu.
Comme le disait Stephen King (qui a écrit autant d’excellents romans que de mauvais bouquins) : » ce qui compte c’est l’histoire, pas celui qui la raconte ».
Je vous laisse transposer la citation au monde informatique 😉
Bruno
Dommage, je n’ai pas pu assister a cette session…
J’aurais bien aime voir en quoi JBoss se differencie de Glassfish par exemple.
En tout cas merci pour le compte-rendu !
(et desole pour les accents, je suis sur un clavier qwerty la…)
Bonjour Nicolas,
Toujours un plaisir de te revoir au hasard des évènements Java middleware. Et merci pour montrer toujours autant d’enthousiasme pour nos produits et notre vision 🙂
Je voudrais juste préciser quelques points de ton article:
>>> »et le support basé à Neuchâtel »
En effet je suis base en Suisse mais on ne peut pas dire que l’infrastructure Support de RHT pour la division Middleware soit basée a Neuchâtel.
Les centres officiels de Support des trois divisions de RHT (Systems, Middleware, Infrastructure) qui consistent le backbone sont bases aux Etats-Unis, en Angleterre et en Australie. Ces centres possèdent une infrastructure téléphone et informatique haute disponibilité pour garantir un support en 24/7 toute l’année. Pour assurer des temps de réponse les plus courts et pour répondre a la demande de pays avec des besoins localises spécifiques, nous avons également développe un réseau de compétences depuis certains autres bureaux RHT comme Tokyo ou Beijing par exemple. L’ensemble offre un maillage mondial extrêmement puissant et agile.
>>> « Il est utopique de penser qu’aujourd’hui un client final met en production une version sans prendre du support. Ceci non pas pour des raisons techniques, mais avant tout pour des raisons… légales »
Absolument. La couverture légale est un des nombreux avantages de notre offre de support, au cote de la fourniture de corrections de bug en quelques heures en cas d’urgence, l’accès aux binaires officiels et bien sur des mises a jour régulières via les CPs (Cumulative Patches).
Je recommande la lecture de: http://www.redhat.fr/products/jboss/benefits/
>>> « La version Enterprise Application Platform (EAP) est strictement identique à la version open-source de JBoss, JBoss Application Server. »
Oui et non. Pour comprendre la valeur de nos produits et nos offres Enterprise, il faut rappeler qu’il y a une séparation tres nette entre les projets communautaires JBoss disponibles sur http://www.jboss.org et les Platforms et Frameworks Enterprise supportes et accessibles seulement aux clients RHT/JBoss. Autrement dit, comme son nom l’indique, Enterprise Application Platform est une plateforme de production et de developpement basée sur plusieurs projets JBoss dont AS, Hibernate, Seam, etc…
Pour illustrer mon propos je recommande de jeter un œil au diagramme « community-vs-enterprise » visible ici: http://www.jboss.org/projects/community-enterprise.html
Et voici d’autres pages qui donnent plus de détails sur nos offres Enterprise:
http://www.redhat.fr/products/jboss/platforms/
http://www.redhat.fr/products/jboss/frameworks/
Au plaisir,
Luc Texier
Manager JBoss Support