Avec un record inégalé de plus de deux millions de downloads en 2002, JBoss est le serveur d'application le plus downloadé, et virtuellement le plus utilisé de l'industrie. JBoss est en passe de devenir la référence en matière de serveur d'application Java robuste, complet, sécurisé et économique.
Julien Viet est l'une de ces personnes que l'on connait sans connaître. L'un des privilégiés à travailler sur un projet aussi prestigieux que JBoss, un passionné. Ingénieur Télécom de formation, il travaille dans un grand institut de recherche américain lorsqu'il découvre JBoss. Immédiatement il l'adopte, participe à son développement, puis intègre la très sélective équipe. Pourtant, c'est avec la plus grande simplicité qu'il a accepté de répondre aux questions de www.developpez.com.

Bonjour Julien, pour nos lecteurs qui n'en sont pas familiers, comment présenterais-tu JBoss?

JBoss est avant tout une implémentation open-source LGPL de la spécification J2EE. JBoss a toujours été le pionnier offrant une technologie de pointe et une richesse inégalée aux développeurs. JBoss, c'est aussi un serveur utilisé en production par de nombreuses entreprises.

La version 4.0 de JBoss est en cours de développement. Y a-t-il une date prévue et quelles seront les améliorations majeures par rapport aux versions 3.xx?

Ce qui va marquer JBoss 4.0, c'est l'AOP (Aspect Oriented Programming). C'est une généralisation du concept d'interception qui a été la technologie au coeur de JBoss depuis la version 2.0 jusqu'aux versions 3.xx.
L'AOP permet d'ajouter et de gérer de manière efficace et transparente les services offerts par les EJB. Par exemple, la sécurité est prise en charge par le SecurityInterceptor. Il en est de même pour d'autres facettes : Persistance, Transactionnel et Clustering sont tous implémentés de cette façon.
Jusqu'ici dans JBoss, ceci était fait grâce aux Dynamic Proxy. C'est à dire qu'une interface était implémentée à la volée dans la machine virtuelle et permettait de déléguer tous les appels faits à cette interface à un seul et même objet.
Bill Burke dirige le développement du framework AOP, qui permet conceptuellement de faire la même chose mais va beaucoup plus loin. En effet, non seulement les appels de méthodes peuvent être interceptés mais aussi les attributs des classes. Bien-sur ceci s'applique aussi bien aux classes qu'aux interfaces et surtout tout ceci est fait de manière totalement transparente pendant l'exécution: Lors du chargement de la classe, JBoss va par le biais d'un descripteur de déploiement instrumenter la classe en interceptant son bytecode et en le modifiant de manière à modifier le comportement de la classe selon les besoins définis par le développeur.
Au final, dans JBoss 4.0, les EJB ne sont qu'un cas particulier de l'application de l'AOP et les développeurs pourront en plus utiliser le framework AOP pour leurs propres besoins, simplifiant le développement d'applications complexes.
Le terme POJO, également très à la mode en ce moment, signifie "Plain Old Java Object", par opposition aux EJB qui sont plus complexes. En résumé, ca veut dire un bon vieil objet comme on en a l'habitude. JBoss 4.0 amène toute la richesse des EJB aux POJO.
En conclusion, JBoss 4.0 reste bien sur un serveur J2EE mais apporte le concept d'AOP.

Le marché français de l'EJB démarre lentement, quel point de vue as tu sur ce retard ?

En fait, ayant travaillé un an aux USA, je n'ai pas suivi le marché de l'EJB en France. À mon départ, j'ai constaté que la technologie était peu utilisée, ce qui est bien dommage. De prime abord, les EJB paraissent difficiles à implémenter et peuvent effrayer les chefs de projets ou décideurs. Je pense que c'est une erreur dûe à un manque de connaissances.
Par exemple, la technologie CMP 2.0 est très performante et vraiment mûre. En fait depuis le CMP 2.0, je n'ai plus écrit aucune ligne de SQL à la main, c'est tellement plus facile de laisser le travail à la couche de persistance.
De bons outils permettent de gérer efficacement un projet EJB, je pense particulièrement à Ant et Xdoclet qui rendent trivial le développement d'EJB. J'espère que le marché français va se rendre compte de la valeur ajoutée d'un conteneur EJB, surtout si celui-ci est open source et permet le déploiement d'applications J2EE à un coût zéro par CPU/machine.

Comment devient on développeur dans l'open source chez un éditeur aussi prestigieux ?

Je voudrais d'abord dire que JBoss Group n'est pas un éditeur de logiciel. Il faut distinguer JBoss de JBoss Group. JBoss est le projet open source et JBoss Group est une entreprise qui offre des services de consulting de très grande qualité que ce soit au niveau du conteneur J2EE ou dans le logiciel de serveur d'application. JBoss c'est 78 personnes incrites sur sourceforge et qui contribuent au développement du serveur. JBoss Group c'est une trentaine de personnes dont bon nombre sont des développeurs de JBoss.
Tout a commencé il y a un an exactement, je venais d'arriver au NIST (National Institute of Standards and Technology) et ma mission était d'assurer la persistance de documents XML au sein d'une base de données relationnelle. A partir des modules W3C Schemas il fallait construire le modèle relationnel et ensuite pouvoir y stocker des documents XML.
Pensant qu'aucune solution n'existait déjà, je me suis mis à développer un serveur « from scratch ». À cette époque j'ai commencé à farfouiller dans le code source de JBoss et me suis rendu compte que 80% de ce que je voulais faire existait déjà. Mon idée était d'utiliser les EJB comme couche de persistance et d'utiliser les Deployer comme système de déploiement des W3C Schemas XML. J'ai pu développer un tel serveur en 3 mois, en m'appuyant sur l'infrastructure déjà présente.
Au cours de ce développement je suis tombé sur des bugs que j'ai corrigés et j'ai demandé à Scott Stark un accès au CVS pour pouvoir contribuer.
Au cours du mois de septembre un nouveau projet naquit: développer des forums utilisant la technologie EJB et JBoss. Je me suis dit que c'était ma chance de participer plus concrètement et me suis lancé dedans. Finalement le projet n'a pas eu le succès escompté et surtout ne répondait plus aux besoins de la communauté. En effet, nous avions besoin d'une infrastructure beaucoup plus transversale que celle offerte par les forums. Le CMS Postnuke répondait à ces besoins. A la fin de l'année, une version refondue du site web sous Postnuke a vu le jour, malheureusement la projet a du être abandonné pour deux raisons : utiliser du PHP pour vendre du J2EE n'est pas une très bonne idée et les performances de Postnuke étaient très médiocres. Attention, je ne critique pas Postnuke lui-même qui est un fantastique logiciel web mais plutôt le langage qui ne permet pas le développement d'applications scalables.
Je me suis alors vu confier la Projet "Nukes on JBoss" qui est le portage de Postnuke sur J2EE. En 9 semaines j'ai pu développer une version utilisable pour notre site web et qui tient très bien la charge (le cpu ne dépasse pas 5% d'utilisation). Aujourd'hui le core de Nukes est développé et nous avons commencé le portage des modules importants de Postnuke, en effet la richesse de Postnuke, ce sont ses modules. Nous cherchons activement de nouveaux contributeurs pour porter les modules.

Merci Julien.