Duchess France
A Duchess Community Blog for France

Le 21 juillet prochain, le Lyon JUG propose une soirée spéciale à l’occasion de la sortie de Java 7. Partout dans le monde d’autres événements de ce type auront lieu au mois de juillet. Vous pouvez récupérer les slides Oracle et des exemples de code présentant les nouveautés de Java 7 et également visionner le webcast officiel “MOVING JAVA FORWARD” proposé par Oracle pour la sortie de Java 7. Le Lyon JUG a donc choisi pour l’événement d’accueillir un de ses fidèles, Julien Ponge, mais également Alexis Moussine-Pouchkine.

Alexis Moussine-Pouchkine était ambassadeur, chez Sun Microsystems du projet Iibre, GlassFish. Il continue actuellement à travailler sur ce serveur d’application Java EE de nouvelle génération en tant que GlassFish community manager chez Oracle. Ceci lui permet de rencontrer lors de réunions ou de conférences de nombreux développeurs Java et autres utilisateurs de technologies libres. Il anime depuis peu une conférence intitulée “Oracle ange ou démon?”, vous pourrez notamment assister à cette session au JUG Summer Camp à la rentrée. Il blogue régulièrement sur Bistro! ou TheAquarium et participe à plusieurs communautés open source. Il traduit également en français des ouvrages techniques autour de Java ou XML. Vous pouvez suivre Alexis sur Twitter ou l’écouter sur le podcast Java Spotlight auquel il participe régulièrement.

Julien Ponge est un artisan de longue date de l’opensource. Il a créé le framework IzPack et a participé à plusieurs autres projets, notamment à GlassFish en collaboration avec Sun Microsystems. Titulaire d’un doctorat en informatique, il est actuellement professeur agrégé en informatique à l’INSA de Lyon, et un chercheur dans le cadre de l’INRIA Amazones / équipe CITI. Ses centres d’intérêts de recherche concernent une approche combinée des langages de programmation, les machines virtuelles et des middlewares. Parlant à la fois le langage industriel et le langage académique, il œuvre pour développer des synergies entre ces mondes. Vous pouvez suivre Julien sur Twitter.

Puisque la team du Lyon JUG est généreuse, vous avez le droit pour l’occasion à un interview des speakers mais également à un nouvel opus de son podcast Cast-IT qui sortira peu après le 21 juillet (le temps du montage!). Si vous ne connaissez pas Cast-IT, allez vite écouter les premiers épisodes de ce nouveau podcast participatif sur l’écosystème Java, certes, mais ouvert également à des sujets comme l’Agilité ou d’autres langages. Et pour vous donner tout de suite un avant-goût de la soirée, allons à la rencontre des speakers de la soirée (Bon, on a donné des jokers à Julien : il ne s’est pas exprimé sur les questions touchant directement à Oracle!). Puisque la team du Lyon JUG est également joueuse, sachez que chacun d’entre eux n’a pas eu accès aux réponses de l’autre interviewé avant la sortie de l’interview! Que la partie commence…

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 à Thierry Chantier et Anne-Laure Rigaudon pour leur aide sur la préparation de cet interview.

Agnès & Cédric: Quelles sont, selon toi, les nouveautés syntaxiques les plus intéressantes apportées par Java 7 ? Penses-tu que certaines nouveautés peuvent bénéficier à GlassFish ?
Alexis: Je trouve que Project Coin propose des améliorations du langage Java qui me font penser à la “nouvelle” boucle for apparue dans le JDK 5 et qu’elles forment un tout très cohérent mais j’aime particulièrement le bloc ARM (Automatic Resource Management, aussi parfois appelé try-with-resources).
Quant à l’intérêt de Java 7 pour GlassFish, je pense que les chaînes de caractères dans les switch, les blocs ARM (notamment avec JDBC 4.1), le multi-catch (SQL, gestion de fluxs, …) et la notation diamond sont tous applicables dans un contexte Java EE, mais c’est des développeurs GlassFish que j’attends le plus et en particulier de leur utilisation de nio 2 et peut-être même de fork/join. Nul doute que les APIs de Java EE 7 tireront partie de Java SE 7 qui sera un pré-requis. Enfin, on peut noter que GlassFish 3.1.1 sera certifié sur Java 7 d’ici quelques semaines ce qui proposera les améliorations de performances inhérentes à toute nouvelle version du JDK.
Julien: Les chaînes de caractères dans les switch ou les underscores dans les littéraux numériques sont des évolutions mineures mais néanmoins utiles. Le multi-catch apporte une concision salutaire lorsqu’on manipule des APIs déclarant beaucoup d’exceptions tandis que le traitement de celles-ci reste commun à de nombreux cas. Classiquement on utilisait un type d’exception très générique (Exception, Throwable, …), ce qui n’est pas toujours une bonne idée. Le multi-catch est un compromis idéal entre concision et expression de types complète.
L’inférence de types paramétrés avec le diamond ainsi que le try-with-resources sont pour moi les 2 vraies nouveautés majeures et notables de Java 7. J’adore en particulier le dernier. Tout le monde se plante en écrivant du code qui manipule des ressources, souvent sans en avoir conscience. Sur des applications serveur cela peut nécessiter des redémarrages fréquents. Traiter tous les cas d’erreurs possibles est complexe, aussi déléguer la génération d’un code correct au compilateur est salvateur. Cf http://www.oracle.com/technetwork/articles/java/trywithresources-401775.html

Agnès & Cédric: Peux-tu nous en dire un peu plus sur le projet OpenJDK?
Alexis: Depuis qu’Oracle a réaffirmé l’aspect stratégique d’OpenJDK (et depuis que cela devenait l’implémentation de référence de Java SE), on a vu IBM et Apple rejoindre le projet (RedHat l’avait fait à l’époque de Sun) ce qui lui assure des ressources importantes et de qualité et donc un avenir à long terme. Il reste encore beaucoup à faire et j’attends en particulier avec impatience les contributions issues de JRockit (annoncées par Oracle).
Enfin, à défaut d’avoir toute la transparence espérée dans JCP (les progrès sont en cours), OpenJDK est une communauté ouverte qui permet de suivre de très près l’évolution de la principale implémentation JavaSE et de permettre aux utilisateurs Mac OS X d’avoir des binaires fournis par la communauté (Henri Gomez) en attendant une version officielle d’Oracle.
Julien: C’est l’implémentation de référence de Java SE 7 qui est sous licence GPLv2 + classpath exception.
A titre personnel je suis ce qui se passe sur certaines listes de diffusion et en particulier le port macosx. On y voit des ingénieurs Oracle, IBM ou Apple y discuter ouvertement, avec des extérieurs qui se greffent aisément aux conversations. A titre d’exemple Henri Gomez qui s’occupe d’un packaging non-officiel du port macosx est très actif (http://code.google.com/p/openjdk-osx-build).
OpenJDK c’est “le vrai Java”, et vous pouvez facilement récupérer le code source, l’étudier, et le compiler… et le modifier. Il n’y a pas de barrière particulière à l’entrée.

Agnès & Cédric: Est-ce que tu penses que Java est attractif pour les jeunes développeurs? Vois-tu Oracle encore innovateur pour Java et son écosystème? Penses-tu qu’il soit nécessaire de ressusciter l’intérêt de la communauté? Si oui, comment?
Alexis: Il y a beaucoup de manière d’innover. Comparé à d’autres langages qui ont moins d’historique (moins d’utilisateurs) et d’autres approches (typage dynamique par exemple), Java peut apparaître comme en retard. Ceci dit on peut être très productif en Java de nos jours avec des versions récentes d’API (Java EE 6 coté serveur par exemple) et le rôle langage devient alors moins important. En fait son typage statique et son expressivité deviennent même une garantie de survie dans le temps, Java est un langage ou la (re)lecture est plus importante que l’écriture. C’est donc un excellent candidat pour l’apprentissage de l’informatique – pragmatique et *très* utilisé en entreprise, il n’en est pas moins indépendant de toute solution technique ou produit. On notera d’ailleurs que toutes les solutions de cloud que l’on voit apparaître sont basées sur Java.
Ceci dit, Java 7 n’est qu’une étape et Project Coin (comme le jeu de mots sur le nom du projet l’indique) ne propose que de relativement “petites” évolutions du langage. Java 8 (attendu dans environ 18 mois) sera plus ambitieux avec les expressions lambda (closures), et surtout à mon sens la modularisation tant attendue.
Le nouveau bytecode “invokedynamic” est une innovation qui passe un peu inaperçue. Elle devrait permettre à de nombreux langages s’exécutant sur la JVM d’améliorer leur performance et de simplifier leur implémentation. En fait ce bytecode sera même utilisé dans Java 8 pour l’implémentation des expressions lambda. Une place de choix est donc faite aux amateurs d’autres langages, même si je ne crois pas un instant Scala ou Groovy puissent détrôner Java tant son spectre et son utilisation sont larges.
D’autre innovations coté Oracle viendront sur les aspects monitoring et management avec en particulier le portage de JRockit Mission Control sur HotSpot ou la suppression pure et simple de la PermGen dans un update de Java 7.
Il reste beaucoup de chose à faire: simplifier JNI, meilleure interop entre langages s’exécutant sur la JVM, isolats (multi-tenancy), meilleure intégration aux systèmes de persistance, etc.
Mes première impressions suite au lancement de Java 7 sont que l’arrivée même d’une version majeure de Java est une source importante de motivation dans la communauté. J’espère qu’une cadence régulière d’innovations (toutes ne viendront pas d’Oracle heureusement) va donner un nouveau souffle à Java. En fait je trouve incroyable que la communauté ait continué à s’étendre pendant cette période de troubles. L’avenir ne peut apporter que de bonnes surprises.
Julien: Plusieurs questions en une
Oui Java est attractif pour les jeunes développeurs. Le langage en lui même reste simple mais pas simpliste. Mais c’est avant tout l’écosystème Java qui est attractif : une machine virtuelle de premier choix, des bibliothèques et frameworks à foison, des langages qui fleurtent avec des paradigmes différents de Java… sans oublier une communauté large et active. Le succès des JUGs et des conférences du monde Java en sont la preuve flagrante. Enfin il faut noter que l’univers Java n’a jamais été hermétique aux autres communautés (Ruby, Python, etc).
Clairement Oracle n’a pas la même culture que feu Sun Microsystems. Les débuts ont été difficiles en terme de communication, mais force est de constater qu’Oracle fait de gros efforts pour comprendre comment dialoguer positivement avec la communauté Java au sens large. Ils investissent massivement dans la technologie et ont réussi le coup de force de fédérer IBM, Apple et maintenant SAP autour de OpenJDK.
Certains ont un bénéfice stratégique à mettre de l’huile sur le feu et à guetter le moindre faux-pas d’Oracle. Jugeons plutôt cette entreprise sur les faits que sur les titres d’articles sulfureux qui fleurissent ci et là. De mon point de vue la tendance est bonne. Java possède un steward principal qui a les reins solides et la sortie de Java 7 marque la fin des errements de calendrier. Reste pour Oracle à poursuivre ses efforts.
Enfin je ne pense pas qu’il y ait besoin de “ressusciter l’intérêt de la communauté”. Les conférences sont sold-out en peu de temps, les JUGs tournent très bien… Java is not dying

Agnès & Cédric: Comment se déroule une de tes journées standards ? As tu le temps de faire de la veille, d’observer les produits concurrents ? As tu le temps de faire du Groovy, Scala ou Clojure ? Que penses tu de ces langages alternatifs sur la JVM ?
Alexis: Je passe en effet pas mal de temps à observer ce qui se passe dans la communauté (et je crois connaître assez bien la concurrence). Je passe aussi du temps à alimenter le blog No. 1 chez Oracle: TheAquarium et je voyage assez fréquemment pour participer à des conférences ou effectuer des visites aux JUGs.
Coté langages “alternatifs”, je suis vieux jeu! Je pense qu’ils ont des domaines d’application restreints: DSL encore peu utilisés, services en ligne massifs (combien d’architecture à la twitter?), et besoin de parallélisme bien traités par un Scala encore réservé à une élite. Coté informatique de gestion les avantages de ces langages ne sont pas évidents, sauf peut-être pour du développement rapide et jetable.
Julien: Je fais un métier qui n’a pas de journée type. Être chercheur suppose naturellement de regarder l’état de l’art, expérimenter, se positionner… donc une activité dite de veille est naturelle.
Je suis un fervent défenseur du “polyglot programming”, j’utilise donc des langages et combinaisons de langages en fonction des usages visés. Je ne rentrerai donc pas dans une guerre Groovy vs Scala vs Clojure vs Ruby vs Python vs JavaScript Il m’est même arrivé de programmer une application node.js !
La JVM est en passe de devenir le champ d’expérimentation #1 pour les nouveaux langages tant statiques que dynamiques (cf invokedynamic). Ce bouillonnement est une force, sauf pour les architectes frileux qui détestent avoir à effectuer des choix sur des critères purement techniques… [troll assumé]

Agnès & Cédric: Tu présentes une session en ce moment (à venir au JUG Summer Camp) intitulé “Oracle, ange ou démon?”… Quels sont les premiers retours de cette conférence?
Alexis: L’idée de cette présentation est partie de mon impression que si environ 50% de la communauté donnait le bénéfice du doute à Sun Microsystems (non, pas plus, beaucoup ont idéalisé Sun depuis le rachat), personne ou presque ne fait confiance aveuglément à Oracle. En particulier il est facile de donner le rôle du vilain à Oracle dès qu’il y a une polémique. Mon but est donc de retracer les événements, principalement dans le monde Java, depuis le rachat et de laisser l’audience se forger une opinion sur la base des actes d’Oracle. Clairement personne n’en ressort avec la conclusion qu’Oracle est un ange!

Agnès & Cédric: En quoi le rapprochement des équipes JRockit et HotSpot a été bénéfique pour JavaSE?
Alexis: Il y a presque deux fois plus d’ingénieurs travaillant maintenant sur la JVM par rapport aux dernières années chez Sun. C’est pour moi le principal avantage à court terme. A plus long terme, l’intégration des fonctionnalités unique de JRockit sur la base HotSpot sont très prometteuses, en particulier Flight Recorder et Real-Time.
Julien: D”un point de vue externe, ces deux équipes ayant produit des avancées significatives dans la conception de machines virtuelles, leur rapprochement ne peut qu’être bénéfique !

Agnès & Cédric: Comment se passe la collaboration avec les equipes de WebLogic ? Avez-vous mutualisé certains efforts ? Quel est l’intérêt pour Oracle à maintenir 2 serveurs Java EE ?
Alexis:
Les premières collaborations datent d’avant le rachat: WebLogic utilise Mojarra, l’implémentation JSF de GlassFish, Metro (stack Web Services) alors que GlassFish utilise depuis sa version 1.0 l’implémentation TopLink/EclipseLink développée par Oracle. Avec le rachat, les équipes GlassFish et WebLogic sont regroupées et les collaborations renforcées.
Ceci dit il est fondamental de ne pas perdre de vue l’objectif principal de WebLogic qui est de servir de socle pour le middleware Fusion, les Fusion Applications et les applications critiques développées par ses utilisateurs depuis des années. De la même manière il est fondamental de continuer à fournir avec GlassFish un produit open source de qualité (production-quality comme disent les américains) qui implémente la toute dernière spécification JavaEE sans oublier le clustering et une admin centralisée. Les rythmes de développement sont donc nécessairement différents.
En tout cas les efforts (et les ressources) consentis par Oracle sur GlassFish sont en soit une belle marque de succès pour l’équipe avec entre autre des embauches régulières et l’adoption de plusieurs fonctionnalités clés du produit dans les prochaines versions de WebLogic.

Merci Alexis et Julien!

Les inscriptions pour la session d’Alexis et Julien au Lyon JUG le 21 juillet sont ouvertes! Rendez-vous sur le site du Lyon JUG.

Le 22 et 23 juin prochains, deux soirées autour d’Hibernate sont proposées respectivement par l’Alpes JUG et le Lyon JUG. Le speaker n’est autre qu’Emmanuel Bernard, un membre de l’équipe Hibernate depuis 2003.
Emmanuel a plusieurs casquettes : il est tout d’abord architecte plate-forme données chez JBoss, membre de l’expert group JPA 2.0 et spec lead de Bean Validation. Emmanuel a dirigé l’implémentation JPA d’Hibernate. Il a fondé et dirige Hibernate Search, Hibernate Validator et le petit nouveau Hibernate OGM. Il intervient régulièrement dans diverses conférences et JUGs, dont JavaOne, JBoss World, Devoxx et est le co-auteur d‘Hibernate Search in Action publié par Manning. Il est aussi le fondateur et co-hôte de deux podcasts: Les Cast Codeurs (français) et JBoss Community Asylum (anglais).
Emmanuel présentera deux sessions aux JUGs. La première sera sur Hibernate OGM. PaaS (Plate-forme as a Service), Cloud, élasticité. Ces mots font le buzz ces temps-ci. Mais le vrai challenge c’est comment et où stocker vos données. Dans un data grid pour bénéficier de la scalabilité? Via une API propriétaire? Est-ce que l’on pourrait utiliser une API familière? L’objectif d’Hibernate OGM est d’explorer comment réutiliser Java Persistence et son API familière pour persister les entités dans une base de données non relationnelle.
Hibernate a bien évolué depuis ses débuts. Il n’est plus un simple ORM mais plutôt un ensemble de projets qui tournent autour du modèle métier. La deuxième session d’Emmanuel sera focalisée sur les différents projets Hibernate comme Hibernate Validator, Hibernate Search ou
Hibernate Envers.

Cet interview a été préparé conjointement par Agnès CREPET et Cédric EXBRAYAT, deux membres de la team du Lyon JUG.

Agnès & Cédric: Lors de la prochaine session du Lyon JUG, tu vas nous parler d’Hibernate OGM, qui permet de disposer d’une implémentation JPA (chouette on est pas perdus, on connait!!!) dans le monde des datagrids NoSQL. Sous quelles impulsions est né ce projet? Quelle est sa maturité à ce jour?
Emmanuel: Le besoin initial est venu d’Infinispan. Les utilisateurs d’Infinispan demandaient une API de plus haut niveau qui leur permettrait de manipuler des objets à la JPA. On a hésité entre la réécriture de zéro ou l’adaptation du moteur Hibernate Core. J’étais de l’avis qu’Hibernate Core ne pouvait pas être adapté pour fonctionner sur les modèles non relationnels. Et pour prouver que j’avais raison, j’ai commencé le prototypage de ce qui est maintenant Hibernate OGM. Évidemment, j’avais tort
En travaillant sur le projet et sur la déshydratation des grappes d’objets on a réalisé qu’Hibernate OGM pouvait en principe travailler sur d’autres moteurs NoSQL qu’Infinispan et on a décidé d’élargir le scope tout en gardant Infinispan en implémentation de référence.
Au même moment, nos travaux sur Hibernate Search, sur Lucene et le stockage de ses indexes dans Infinispan nous a convaincu que l’on pouvait écrire un moteur de recherche dont les indexes étaient stockés dans Infinispan.
Ces deux conditions ont permis de résoudre le problème de persistance des entités et le problème de requêtage d’entités.
Hibernate OGM est en release Alpha. Donc à ne pas utiliser pour stocker les comptes bancaires de vos clients.
Le moteur de persistance est, je pense, relativement stable mais l’on discute encore de la meilleure façon de stocker les données (lisibilité vs taille etc). Je pense que l’on va encore travailler sur ces points donc des évolutions seront à prévoir. Si vos données sont de type court terme (ie. à ne pas relire entre chaque montée de version d’Hibernate OGM), pas de soucis.
Pour ce qui est du moteur JP-QL, il n’est pas encore là. Cependant, si vous utilisez Hibernate Search et ses requêtes full-text, vous avez quelque chose de stable.

Agnès & Cédric: Puis-je utiliser Hibernate OGM avec d’autres solutions NoSQL que Infinispan?
Emmanuel: Pas encore. Mais cela fait partie de nos objectifs.
On a travaillé récemment sur l’abstraction du contrat entre Hibernate OGM et Infinispan. Tout n’est pas fini mais je pense que le contrat est en bonne voie et sera capable d’abstraire correctement l’interaction avec des NoSQL clef/valeur d’ici peu. Les gens d’EhCache ont travaillé sur un prototype ce qui nous a aidé à clarifier le contrat.
Les NoSQL de type Document sont les prochains en ligne de mire parce que leur structure est très similaire. Ensuite viendra les NoSQL Column et peut-être les NoSQL Graph.
La partie difficile est de bien gérer les différences entre les opérations primitives et les différences d’isolation transactionnelle (au sens large) entre les moteurs. C’est pour cela que l’on compte beaucoup sur les utilisateurs et la communauté de chaque produit NoSQL pour nous aider dans cette tâche. Idéalement, un expert Cassandra viendra contribuer sur le dialect Cassandra et ainsi de suite.

Agnès & Cédric: On parlait d’impedance mismatch lorsque l’on présentait la problématique du mapping objet/relationnel, pour faire référence aux problèmes rencontrés lorsque l’on voulait faire parler le monde objet de nos applications et le monde des bases de données relationnelles. Mais aujourd’hui comment requêter en JP-QL “au dessus d’une technologie qui ne supporte pas la notion de requête (clé/valeur)”?
Emmanuel: Bonne question. Il y a plusieurs réponses selon ce que la technologie sous-jacente offre. Notre approche (en tous cas initialement) est d’indexer les objets en utilisant Hibernate Search. A chaque fois qu’un objet est créé, modifié ou supprimé, Hibernate Search est au courant et met à jour l’index Lucene correspondant. Cette techno fonctionne et est éprouvée. D’autre part on sait stocker l’index Lucene dans Infinispan (ce qui offre une visibilité des changements immédiate et une distribution de l’index).

Donc la clé et ce sur quoi on travaille aujourd’hui est de convertir une requête JP-QL en requête Hibernate Search / Lucene.
Pour donner un exemple, voici deux requêtes JP-QL converties :
select a from Animal a where a.size > 20
animalQueryBuilder
.range().onField(“size”).above(20).excludeLimit()
.createQuery();

select u from Order o join o.user u where o.price > 100 and u.city = “Paris”
orderQB.bool()
.must(
orderQB.range().onField(“price”)
.above(100).excludeLimit().createQuery() )
.must(
orderQB.keyword(“user.city”).matching(“Paris”)
.createQuery() )
.createQuery();
(c’est l’API de requêtage d’Hibernate Search que l’on voit en action ici)

A noter que la requête n’est qu’un des mismatchs, on peut citer rapidement:
- comment stocker / (dés)hydrater les entités
- comment stocker la notion d’association
- comment éviter le trop grand nombre de lookups de clés (problème équivalent au fameux n+1 selects SQL)
- comment assurer la pérennité des données en cas de changement de structure des objets

Agnès & Cédric: Peut-on comparer Hibernate OGM et Spring Data?
Emmanuel: Il y en a qui ont essayé, ils ont eu des problèmes
Disclaimer: je ne connais pas Spring Data par coeur, j’ai autre chose à faire que d’analyser du matin au soir ce que font des concurrents potentiels. Donc si je dis des bêtises sur ce qu’est Spring Data ne m’en voulez pas.
Spring Data et Hibernate OGM tentent de simplifier l’utilisation des outils NoSQL. Mais je crois qu’à part ça, le niveau de comparaison n’est pas le bon.
Spring Data est un porte-feuille de technologies centrées autour de la donnée. Si on devait comparer, il faudrait regarder du côté de JBoss un bon paquet de projets. Pour en citer quelques uns:
- Hibernate Core
- Hibernate Envers
- Hibernate Search
- Hibernate OGM
- Seam Persistence
- Seam EntityHome framework
- Teiid (fédération de bases de données)
- JBoss Transaction
- Modeshape
- Infinispan
- JCloud (pas JBoss mais un projet intéressant)
- etc

C’est une bonne idée d’avoir regroupé ces technos sous un même portail. J’espère qu’on fera la même chose du côté JBoss: c’est beaucoup plus simple pour les utilisateurs de s’y retrouver.
Cela dit, certains objectifs de Spring Data se retrouvent dans Hibernate OGM notamment via les sous projets Spring Data-MongoDB, Spring Data-JPA, Spring Data key / value. La philosophie n’est pas la même par contre.
Les projets Spring Data encapsulent les APIs des différents datastore dans des template et autre abstractions pour simplifier un peu la vie. Donc vous devez apprendre leurs APIs. Dans l’ensemble je dirais que c’est un énorme helper framework, spécifique à chaque techno qui vous simplifie la vie sans nécessairement masquer la techno en dessous.
Hibernate OGM expose l’API et la sémantique JPA, c’est un moteur JPA dans le sens pur du terme. On pourrait en théorie passer le TCK avec. Du coup, on est plus dans un modèle de programmation proposé et connu qui est JPA et qui est appliqué au datastore que vous voulez utiliser. Hibernate OGM pense aux données sur une période longue, disons 10 ans avec dans l’idée que votre modèle métier va évoluer, voire que vous allez vouloir utiliser vos données sur d’autre plateformes (Ruby, .net etc). Spring Data ne m’a pas donné cette impression, il y a généralement un mapping 1-1 entre un objet et sa représentation en base (ou alors, on se tape le mapping à la main). Pareil, JPA est relativement expressif pour ce qui est relation entre objets y compris circulaire, je n’ai pas vu beaucoup d’options côté Spring Data.
Mais on va tous dans la même direction, simplifier l’utilisation des outils NoSQL et c’est une bonne chose. Il y a deux choses que j’aime particulièrement dans Spring Data:
- leur abstraction de requêtage pour les requêtes relativement simple est très sympa
- l’idée de pouvoir dénormaliser une entité entre plusieurs datastores disparates (je n’ai pas vu d’info dans la doc mais j’ai vu une présentation qui parlait de cette fonctionnalité): je ne suis pas encore 100% convaincu que cela soit utile en pratique mais l’idée est intéressante et c’est quelque chose qu’Hibernate OGM pourra implémenter je pense dans le futur.

Agnès & Cédric: Quel temps peux tu accorder au développement de projets comme Hibernate OGM ? As tu le temps de tester des produits équivalents ou de travailler avec des bases NoSQL ?
Emmanuel: Chez JBoss, on est maître de son temps (et esclave de son travail ). Chaque équipe est un peu une mini entreprise qui choisit ses priorités. Par exemple, je fais le choix d’aller à une conférence ou de répondre à une interview et c’est du temps en moins pour développer.
Selon les besoins du moment et les cycles de produits, j’ai du temps pour expérimenter et essayer de nouvelles idées. Par exemple, le premier commit d’Hibernate OGM date de juillet dernier et j’y ai travaillé à temps très partiel pendant la plupart de l’année avant de donner un coup de boost. Le vrai risque c’est de gérer trop de projets en parallèle et donc de ne pas assez les faire avancer individuellement.
Mais bon, il y a pire comme boulot

Agnès & Cédric: As tu participé au développement de Ceylon ? Utilises tu d’autres langages tournant sur la VM ? Scala, Groovy, Clojure ? Que penses tu que Ceylon puisses apporter à notre plateforme ?
Emmanuel:
Oui j’ai participé au design de Ceylon et au développement du type checker et de l’infrastructure du projet, là encore à temps partiel malheureusement. C’est assez fascinant de pouvoir partir de zéro et de faire peu de compromis. Personnellement je travaille principalement en Java même si j’ai bossé un peu en Groovy dans le passé. Je me tiens malgré tout au courant de ce qui se passe dans les autres langages (de la JVM ou pas).
Si j’avais à résumer, Ceylon a quatre avantages clés:
- lisibilité
- un système de type très expressif (l’API de réflexion est entièrement type-safe par exemple)
- capacité à décrire dans le langage lui-même des structures hiérarchiques comme des interfaces utilisateur ou des structures qui seraient décrites en XML (et ceci de manière fortement typé)
- de nouvelles API modernes
La règle d’or de Ceylon est que le langage doit être lisible et compréhensible. Quelqu’un qui ne connaît pas Ceylon devrait pouvoir comprendre ce que fait un bout de code. Pour réussir cela, on essaie de garder le langage extrêmement régulier (Ceylon est bien plus régulier que Java par exemple), de limiter les options et de retirer des fonctionnalités si cela rend le langage trop complexe. C’est très frustrant! Récemment, Gavin a supprimé ce qui était probablement ma fonctionnalité préférée: elle pouvait être dangereuse dans certaines situations et 95% des cas d’utilisation sont supportés autrement (moyennant des aménagements dans d’autres fonctionnalités).
Un kit de développement nouveau (API) est un gros défis mais si on se débrouille bien, je pense que ça sera un point clé du succès de Ceylon. Aucun langage n’a vraiment percé sans de bonnes APIs.

Merci Emmanuel!

Les inscriptions pour la session d’Emmanuel au Lyon JUG le 23 juin sont ouvertes! Rendez-vous sur le site du Lyon JUG.
Vous pouvez également assister à sa session à Grenoble, organisée le 22 juin par l’Alpes JUG

Le 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

D’ici deux semaines, les 26 et 27 mai aura lieu sur Paris What’s Next, conférence de deux jours autour de java, du Cloud, de NoSQL, de Clojure …

De speakers internationaux confirmés vont nous présenter des talks inédits orientés sur la question du futur des technologies. On y parlera par exemple de :

• ElasticSearch par son fondateur Shay Bannon, moteur de recherche open source, distribué et RESTful.
• Akka par Jonas Bonér, framework permettant d’écrire de gérer les applications concurrentes en utilisant entre autre les acteurs qui permet une vrai scalabilité, une tolérance aux fautes …
• Le class loading par Jevgeni Kabanov, fondateur de ZeroTurnaround qui édite JRebel, un outil qui permet un rechargement à chaud des classes et qui se révèle d’un grand gain de temps de compilation. J’avais déjà eu une de ses présentations à Devoxx, très appréciée, désormais visible sur Parleys sur le fonctionnement des class loaders.

Le détail des sessions.

Nous vous y retrouverons nombreuses les 26 et 27 mai au grand Rex. Et cerise sur le gâteau, nous proposons à toutes les duchess une réduction de 25%, nous contacter pour plus d’infos !

Plus d’infos sur le site officiel

Une nouvelle rencontre avec un des speakers de MIX-IT. Vous avez déjà pu lire sur le blog des JDuchess l’interview des speakers Christophe Grand et Laurent Petit sur Clojure, ou encore celle de Nicolas Martignole, keynote speaker de la conférence. Aujourd’hui, c’est au tour de Mauro Talevi qui nous fait également l’honneur d’être présent parmi les speakers de MIX-IT. Et quel honneur! Mauro est un des principaux contributeurs au développement de JBehave, un framework Java permettant de faire du Behavior Driven Development (BDD) dont nous allons découvrir les concepts lors de cet interview.

Mauro Talevi travaille pour la société Agilesque, à Londres, spécialisée dans le conseil, le coaching et les développements Agile. Il a accompagné les entreprises dans la réalisation de gros projets en introduisant les pratiques et les outils Agiles, convaincu que les meilleurs résultats peuvent être obtenus en réunissant les bonnes idées et les outils appropriés pour les implémenter. Il est actif dans de nombreux projets open-source, notamment JBehave.

Mauro Talevi

Agnès: Comment et quand a émergé l’approche du Behavior Driven Development (BDD), quels étaient les objectifs initiaux de cette méthode? Comment la situer vis-à-vis du Test Driven Development (TDD), du Domain Driven Design (DDD), et des tests d’acceptance ^*1 automatisés?

Mauro: Le terme de BDD a été inventé par Dan North lorsqu’il essayait d’améliorer la manière d’introduire TDD à des équipes qui découvraient les pratiques agiles. L’expérience de Dan en tant que coach agile a mis en exergue les aspects de TDD qui n’étaient pas facile à appréhender pour des néophytes et qui pouvaient ébranler les bénéfices de TDD pour les utilisateurs expérimentés. Ces aspects concernaient notamment la définition du scope de chaque test, le fait de déterminer quelle convention de nommage devrait être utilisée et quelle information devrait être remontée lors de l’échec d’un test. BDD – en substance, le fait que décrire le comportement attendu soit un meilleur moyen de tester – a été la réponse de Dan à ces écueils perçus de TDD. Dans cette optique, vous pouvez parfois entendre que «BDD est TDD bien fait», mais BDD, au fil du temps, a évolué pour devenir un paradigme à part entière du développement qui complète TDD plutôt que d’essayer de le remplacer.
L’objectif initial fixé sur le langage et la communication – qui a toujours été l’une des principales caractéristiques de la philosophie sous-jacente à BDD – a évolué pour englober plus largement l’ensemble de l’Analyse Agile. Décrire le comportement attendu (mais pas encore implémenté) devient alors l’objectif principal de la phase d’analyse. Comme en DDD, l’accent est mis sur le développement d’un langage universel (voir question suivante). De plus, le comportement analysé, décrit sous forme textuelle, constitue le critère d’acceptance pouvant être automatisé. En revanche, tous les tests d’acceptance automatisés n’expriment pas le comportement attendu sous une forme compréhensible par les StakeHolders ^*2.

Agnès: Quels sont les concepts fondamentaux sous-jacents à BDD? Eric Evans dans son livre célèbre “Domain-Driven Design” a décrit l’usage d’un langage universel (ubiquitous language) pour modéliser un système, basé sur un vocabulaire réellement métier. BDD reprend ce concept d’ubiquitous language. Comment BDD permet-il de faire « pénétrer » ce vocabulaire métier dans le code, et notamment dans l’écriture des tests?

Mauro: BDD place en priorité haute le fait d’axer la communication sur le comportement même du système. Pour arriver à cela, il tente de créer un langage universel, c’est-à-dire un langage qui peut être partagé entre les membres de l’équipe et les StakeHolders. Ce langage devrait être un Domain Specific Language (DSL), un langage dont la syntaxe est bien comprise par tous et possède une signification centrée sur le métier.

A travers les échanges entre les products owners et les équipes et sur la base de ce langage commun, des Stories puis des Scenarios vont être définies. Ces deux termes sont utilisés pour décrire le comportement d’une application. Une Story correspond à une définition très haut niveau d’une exigence métier. On parle aussi de User Story en Scrum. On peut même utiliser un template pour décrire la Story :

En tant que
Je veux
De sorte que

Nous allons utiliser l’exemple simple d’une personne voulant acheter une place de concert pour le groupe de rock Arcade Fire. L’une des Story pourrait ressembler à ceci:

Titre: la personne retire sa place à la billetterie du concert
En tant que fan du groupe de rock Arcade Fire,
Je veux retirer ma place de concert sur un site de billetterie en ligne,
De sorte que je n’ai pas à faire la queue le soir du concert et de sorte que je sois sûre d’avoir une place

Plusieurs Scenarios vont pouvoir alors s’appliquer à une Story : le nombre de place restante est suffisant, il ne reste plus de place pour le concert. Ces Scenarios peuvent eux-mêmes être décrits selon un modèle de syntaxe. Ils vont alors être définis en texte simple respectant une forme structurée composée d’Etapes, chacune correspondant elle-même à une phrase commençant par l’un de ces trois mots clés:

Etant donné que
Quand
Alors

En utilisant ce modèle de syntaxe des étapes, voici ce que pourrait être les scenarios de notre Story :

- Scénario 1: Le nombre de places pour le concert est suffisant
Étant donné que le nombre de places pour le concert est suffisant
Et que je dispose de la somme d’argent nécessaire
Lorsque je demande ma place
Alors assurez-vous que le nombre de place restante est décrémentée
Et s’assurer que la place de concert me soit attribuée

- Scénario 2: Le nombre de places pour le concert est insuffisant
Étant donné que le nombre de places pour le concert est insuffisant
Lorsque je demande ma place
Alors le site de billetterie en ligne m’indique que je ne pourrai assister au concert qu’en allant acheter ma place le soir même.

En substance, BDD crée un mapping entre les étapes textuelles (compréhensibles par les humains) et les méthodes exécutables (compréhensibles par les machines). Ce mapping peut également supporter la définition de paramètres qui permet alors la réutilisation de ce mapping, autrement dit un ensemble de modèle d’étapes définissant la syntaxe des étapes autorisées (Etant donné que, Quand, Alors). Il est crucial que cette syntaxe des étapes soit définie de manière cohérente et à un seul endroit. Par exemple, JBehave utilise les annotations java pour associer la syntaxe des étapes aux méthodes exécutables. Cette syntaxe des étapes peut être publiée et utilisée comme blocs de construction par ceux qui écrivent les Stories et les Scenarios définissant le critère d’acceptance.

Agnès: En quoi BDD est un moyen efficace d’améliorer la communication entre les l’équipe de développement et les StakeHolders, et de fait la définition des besoins métiers? Qu’est-ce qui fait de BDD un puissant levier pour déployer l’agilité sur un projet?

Mauro: Comme mentionné précédemment, BDD encourage la définition d’un DSL et d’une syntaxe d’étapes. Une fois que ces éléments ont été définis, les scenarios peuvent être écrits par n’importe quel membre de l’équipe et vérifiés par d’autres membres de l’équipe et par les StakeHolders. Ils peuvent même être écrits par les StakeHolders eux-mêmes, à condition qu’ils aient acquis une compréhension suffisante du langage. BDD permet la définition de tests d’acceptance automatisés, le fameux critère “Done” requis par Scrum et d’autres méthodes agiles (on parle aussi de Definition of Done, DoD, qui détermine si l’implémentation d’un élément de backlog de produit est bien terminée et satisfaisante d’un point de vue métier). Ces tests peuvent être écrits avant que la fonctionnalité soit développée, par conséquent on parle de “behaviour-driven”, piloté par le comportement voulu, à savoir par le métier. BDD devient aussi un paradigme pour l’analyse Agile puisque décrire le comportement conduit ainsi à une compréhension plus approfondie du système. BDD peut impulser ainsi une forte confiance, à la fois aux StakeHolders à qui on donne – itération après itération – une preuve tangible du comportement précis du système, et à l’équipe à qui on fournit des critères d’acceptance à satisfaire en béton.

Agnès: Te concernant, comment et quand t’es tu intéressé à cette approche? L’as-tu déployé sur d’importants projets? Quelles difficultés as-tu pu rencontrer? Quel bilan peux-tu faire des projets ayant déployés les pratiques BDD?

Mauro: Je me suis impliqué dans BDD à la fin de l’année 2006. A cette époque, j’utilisais Fit comme un outil pour les tests d’acceptance automatisés. Il avait des fonctionnalités intéressantes comme la possibilité de créer un DSL (avec pour convention le nom de méthode), mais il devenait de plus en plus limitée par sa nature tabulaire. Lors d’une conférence à Londres, Dan m’a fait connaitre BDD et JBehave et j’ai immédiatement trouvé que cet outil adressait les problèmes auxquels je me heurtais avec Fit. J’ai commencé à utilisé JBehave dans un projet commercial en 2008. Nous avons eu la chance d’avoir ce projet entièrement nouveau à faire croitre en interne, permettant l’introduction des concepts BDD auprès de l’équipe et des StakeHolders. Mais cela ne nous a pas empêché de faire des erreurs et de tomber dans des pièges, notamment sur le fait de savoir comment présenter et comment communiquer de larges ensembles de données. Nous avons attaqué avec de gros fichiers en format XML, ce qui était facile à dupliquer mais très difficile à maintenir et refactorer. Nous avons tiré bénéfice de ces erreurs et avons migré beaucoup de ces données dans des structures tabulaires – plus lisibles au format texte et plus facilement refactorables.
Aujourd’hui, BDD est beaucoup plus largement utilisé. Tous les projets pour lesquels j’ai promu l’adoption de BDD ont jugé que cette méthode était utile, que ces projets utilisent l’approche agile ou non. De manière commune avec l’Agilité, BDD n’évite pas les difficultés au projet, il les rend simplement plus visibles.

Agnès: Tu es l’un des responsables et fondateurs du projet JBehave, aux côtés de Dan North, la première personne a avoir introduit cette notion de BDD . Peux-tu présenter JBehave, les domaines qu’il adresse? Comment et pourquoi vous est venue l’idée de vous lancer dans le développement de ce framework?

Mauro: JBehave a été le premier projet à mettre en œuvre en Java les idées sous-jacentes à BDD. Il s’est concentré sur l’entrée textuelle, considéré comme le Golden Master, exprimant le comportement attendu en utilisant un langage universel automatisable. Les User Stories en entrées sont analysées et ventilées dans des Scénarios et des étapes, qui sont tour à tour mappés aux méthodes Java en utilisant les annotations et aux patterns d’étape. JBehave prend en charge toutes les notions de BDD et est parfaitement piloté par la demande des utilisateurs. Nous nous sommes efforcés d’aborder le développement de telle manière à vraiment livrer la fonctionnalité attendue et le comportement qui était nécessaire et utile pour les utilisateurs. Toute l’équipe voulant tester un système qui peut être accessible via une API en Java peut utiliser et bénéficier de JBehave. Il est à noter que le système sous-jacent aux tests ne doit pas être lui-même forcément écrit en Java.
Par exemple, nous pouvons tester n’importe quelle application Web avec un framework comme Selenium, qui propose (comme d’autres) une API Java, pour piloter l’interaction avec les pages web.

Cette interview a été réalisée en anglais. Voici mes notes de traduction:

^*1 : en français on devrait parler de tests d’acceptation, mais permettez-moi cet anglicisme ! L’approche ATDD (Acceptance Test Driven Development) est une approche qui place les tests métiers au cœur du projet : le Product Owner préférera alors spécifier sa demande via ces tests d’acceptance, indiquer comment vérifier que sa fonctionnalité désirée est correctement implémentée, plutôt que de se contenter de la décrire dans un document de spécification. De la même manière j’ai laissé le terme de critère d’acceptance plutôt que de parler de critères d’acceptation.
^*2 : Littéralement “partie prenante”, mais je n’ai volontairement pas traduit le mot “StakeHolders”. J’aurais pu peut-être utiliser le terme se rapprochant, emprunté à Scrum, de “Product Owners”. Mais les “Stakeholders” sont souvent plus que les “Product Owners”. Ils représentent toutes les personnes qui ont un intérêt (“Stake”) dans le projet, mais ils ne portent pas nécessairement toute la responsabilité des “Product Owners”.

Merci Mauro! Et rendez-vous le 5 avril à Mix-IT

Les inscriptions à Mix-IT sont ouvertes!

Nous vous avons déjà parlé à plusieurs reprises de l’événement IT lyonnais de l’année, à savoir MIX-IT. Vous avez eu la chance de vous frotter au monde Clojure grâce à notre interview des speakers MIX-IT Christophe Grand et Laurent Petit. Aujourd’hui, nous avons le plaisir de vous amener sur le plateau Nicolas Martignole, qui nous fera l’honneur de faire la keynote d’ouverture de MIX-IT. Cette fois Agnès a préparé l’interview avec Cédric, un autre membre de l’équipe organisatrice de MIX-IT.

On ne vous présente pas Nicolas hein… Et bien si après tout (“No more heroes any more” pour reprendre les Stranglers!). Nicolas Martignole est indépendant depuis 2008, auteur du blog le Touilleur Express et membre de l’équipe du Paris JUG depuis 2 ans. Il travaille plutôt dans la Finance, en tant que technical team leader. Un peu d’Agilité, pas mal de développements et de bonnes pratiques et surtout, du fun. En quelques mots, son parcours : 5 ans dans une agence Web puis une Startup Java 6 ans chez Thomson-Reuters dans la Finance, développeur senior puis technical team leader, et depuis 2008 consultant indépendant.

@nmartignole

Agnès et Cédric: Tu t’occupes du blog Le Touilleur Express et du site l’eXpress-Board, racontes-nous les débuts de ces projets, qu’est-ce qui t’a poussé à ouvrir ces sites et quelle audience avais-tu à leurs débuts?

Nicolas: J’ai commencé à écrire pour Le Touilleur Express fin 2003. J’avais besoin d’avoir un bloc note pour marquer ce que je voyais et ce que je testais. J’ai d’abord commencé avec JRoller, l’ancien blog est d’ailleurs toujours en ligne http://jroller.com/Trecollo. Pendant 4 ans, peu de visiteurs. Le site a vraiment démarré en 2008. A force de publier de plus en plus d’articles, le nombre de visiteurs a grimpé rapidement. Aujourd’hui le site reçoit entre 13500 et 15000 visites selon les mois. Il y a plus de 1100 personnes abonnées sur Google Reader. Tout ceci c’est 3 ans de travail. L’ensemble des 600 articles du blog représenterait un livre de 2500 pages environ.
Pour l’eXpress-Board, je me suis lancé il y a un an. Ce qui m’a poussé à ouvrir ce site, c’est l’envie de changer la façon dont on recherche et on recrute les développeurs. Le site aujourd’hui tourne à environ 1800 visites par semaine. Certaines annonces ont dépassé les 2000 affichages en moins de 30 jours.

Agnès et Cédric: On te connait comme une rock star de la communauté française java, membre de la Crew du Paris JUG, le fameux touilleur (on sait que tu adores que l’on t’appelle comme ça!) mais que fait le Touilleur le jour? Depuis 2008 tu as franchi la frontière du monde merveilleux des indépendants (“le pays des Bisounours” comme dirait Mathilde Lemée), es-tu satisfait de ce mode de travail? Quels sont tes types de missions? Indépendant, et surtout “consultant indépendant”, n’est-ce pas la fin du travail quotidien et stimulant en équipe?

Nicolas: Je travaille en ce moment sur une mission longue en régie pour une grande banque, je suis technical team leader. Je bosse dans une équipe de quelques développeurs. Mon travail consiste à développer et à gérer la réalisation du projet. Je tiens le rôle de Scrum Master. Cela fait 6 ans que je bosse dans la finance, et avec mon profil web, j’aide les équipes métiers à exprimer et spécifier l’interface de notre logiciel. Sinon je gère aussi les développeurs et surtout… je code !
L’indépendance me permet de gérer mon emploi du temps plus facilement. Je suis satisfait, mais je sais que ce n’est pas une finalité. Je souhaite un jour soit travailler à plusieurs dans une structure sympa, soit continuer à développer des services sur Internet. Bien qu’étant indépendant, je bosse autant qu’avant en équipe. Ce n’est que lorsque je fais des missions au forfait chez moi, que je suis seul.

Agnès et Cédric: Récemment un de tes tweets nous a interpellé “Dans le monde Java, y-a-t-il une bulle spéculative de complexité ? cela nous donne du boulot mais est-ce normal ?” Peux-tu développer ce que tu sous-entendais? Tu penses vraiment que la complexité provient de l’écosystème java? Certes, on doit toujours choisir parmi plusieurs frameworks qui adressent une même problématique, mais ne penses-tu pas que la richesse du monde java est au contraire une arme pour affronter la complexité de notre métier?

Nicolas: C’est une prise de conscience depuis un an. Je pense que dans le monde Java, pour certains projets et certains clients, nous gérons trop de complexité. Ce que je veux dire par là, c’est qu’il y a tout un tas de frameworks, tout un tas de procédures pour passer en prod, pour installer un serveur, pour déployer une application… qui n’existent que parce que le système d’information ne sait pas digérer cela. Nous manquons parfois de simplicité. Faire simple c’est bien plus dur que ce que l’on peut penser. Lorsque tu développes, si tu es un bon développeur, tu n’ajoutes pas de code qui casse le logiciel. Si tu es un excellent développeur, tu peux en retirer sans casser le logiciel. Je pense que nous devrions tourner la page de l’ancienne architecture J2EE et que Spring est devenu maintenant le super réacteur à tout faire. Nous n’avons pas encore conscience que tout ceci coûte très cher. Parfois, une solution avec un peu de Ant, un peu de JDBC, et bien ça marche très bien. Bien mieux qu’une soupe maven+spring+configuration de cow-boy… Pourquoi prendre un fusil à pompe pour tuer une mouche ?

Agnès et Cédric: Tu nous fais le plaisir d’un talk sur Play framework “Pimp My App” pour MIX-IT. Ce framework reprend la philosophie que tu évoquais, à savoir moins de complexité et un développement rapide. En dehors de l’eXpress-Board, as-tu pu utiliser ce framework chez des clients ? Le leur proposes-tu et crois-tu pouvoir les convertir à ce genre de nouveauté?

Nicolas: Je l’utilise chez le client pour lequel je travaille en ce moment depuis le mois de juillet dernier. C’est un outil formidable, qui permet de travailler sur une base de données existante, et de sortir rapidement des écrans qui fonctionnent. Deuxième point : pour des débutants, c’est un outil facile à maitriser. Troisième point : lorsque tu passes derrière le code de quelqu’un, tu n’as pas 10 fichiers à travailler. Tu es bien plus efficace. Enfin, et c’est la cerise sur le gâteau, tu peux générer un WAR qui tourne très bien sur IBM Websphere 7. Même mieux qu’une autre application classique, qui nous a demandé des efforts de configuration avec WAS.
Je ne vois pas plus de freins à son adoption qu’il y a quelques années lorsque je proposais de passer à Spring MVC et de dégager Struts par exemple. Le frein est psychologique : bye bye les fichiers XML compliqués à modifier ou la nécessité de faire appel à un expert pour mettre en place la stack. Tout d’un coup, tu reprends le contrôle de ton application.

Agnès et Cédric: Tu as mis en place la plateforme l’eXpress-Board qui permet aux entreprises de proposer leurs offres d’emploi en s’assurant un public conséquent (plusieurs centaines de visites par annonce). Sais tu combien de passionnés ont pu trouver un emploi grâce à l’eXpress-Board? Que retires tu de cette expérience?

Nicolas: Je n’ai pas de décompte exact, mais ce serait bien d’ajouter un moyen de donner ce chiffre via son profil. Je vais l’ajouter à la prochaine version. Pour répondre à ta question, je peux te citer 4 personnes que j’ai croisé et qui ont trouvé un boulot grâce à l’eXpress-Board (Olivier, Frédéric, Guillaume et Christophe). Il y en a plus, mais je n’ai pas de décompte exact.
Aujourd’hui l’eXpress-Board c’est 134 entreprises inscrites, une trentaine très active qui se connecte presque chaque jour. C’est aussi 85 profils actifs, environ 220 candidats enregistrés. J’ai surtout des retours très positifs de la part des équipes RH. On me dit souvent : “ce sont des profils que l’on n’a jamais vu” ou aussi “… très belle rencontre, cela n’a pas marché, mais merci”. Vois cela comme un site de rencontre finalement. Toutes celles-ci ne débouchent pas sur une embauche (aka un mariage si on pousse l’analogie). Pour être juste donc, il faudrait compter les “mises en relation” effectuées plus que les embauches.

Agnès et Cédric: Quel regard portes-tu sur l’évolution de la communauté Java en France ? Le succès du Paris JUG ne vous motive-t-il pas à essayer un événement de plus grande envergure “à la Devoxx”?

Nicolas: La communauté Java a explosé en 3 ans. Plus de 16 JUGS, plusieurs conférences comme le JUG Summer Camp, Soft-Shake et MIX-IT. Le Paris JUG réfléchit à monter quelque chose l’an prochain, mais rien n’est encore fixé.

Agnès et Cédric: MIX-IT, ça n’est pas que la technique, c’est aussi beaucoup d’agilité. Utilises-tu les méthodes agiles au quotidien ? Est-ce un élément que tu considères comme essentiel à la réussite d’un projet ? Les proposes-tu à tes clients?

Nicolas: Oui je suis fan de l’Agilité, et de Scrum. J’en utilise les principes, j’ai fait plusieurs projets avec Scrum. J’ai débuté en 2008. Ce n’est pas essentiel à la réussite d’un projet. Certains projets réussissent sans Agilité, on a très bien réalisé de grands projets avant l’arrivée des méthodes Agiles. Mais le coût est différent. C’est une approche intéressante sur la perception entre la demande du client et la réalisation. Pour moi c’est indispensable, et l’un des challenges est donc d’amener les équipes vers l’Agilité.

Merci Nicolas! Et rendez-vous le 5 avril à Mix-IT

Les inscriptions à Mix-IT sont ouvertes!

Le 5 avril aura lieu à Lyon la première édition de Mix-it!

Le Lyon JUG et le Club Agile Rhône-Alpes s’unissent pour vous proposer une journée exceptionnelle autour de l’agilité, des technologies Java/JEE et des tendances novatrices. Mix-IT 2011 est avant tout un rassemblement d’acteurs de tous horizons et de tous domaines.

En mettant en avant l’innovation, les bonnes pratiques et la découverte, Mix-it concerne toutes les personnes et entreprises qui veulent en savoir plus sur l’agilité et/ou les technologies Java/JEE.

Vous êtes développeur, testeur, architecte et vous avez envie de rencontrer des intervenants renommés sur des projets tels que Spring ? Vous vous demandez ce que peut bien être NoSQL ou Apache Mahout? Vous avez envie d’avoir les bons arguments pour promouvoir l’agilité au sein de votre société ? Cette conférence est pour vous !

Vous êtes chef de projet, responsable produit, manager et vous voulez maîtriser des sujets tels que les estimations, la planification ou la contractualisation agiles ? Vous désirez échanger avec vos homologues sur la mise en place de l’agilité en entreprise ? Vous souhaitez également comprendre ce qui se cache derrière le mouvement DevOps… Cette conférence est pour vous !

Niveau speakeurs, on retrouvera des noms connus des JUGs (Nicolas Martignole, David Gageot, Didier Girard, Michaël Figuière) et des agilistes reconnus (Laurent Bossavit, Mack Adams, Mauro Talevi, Thierry Cros)…

Si vous désirez proposer une session, vous êtes invités à envoyer ce document de proposition renseigné à l’email orateur@mix-it.fr.
Les propositions de session sont à envoyer au plus tard le 08 Mars 2011.

Au niveau pratique, les frais d’entrée sont très modérés (20€ ) et toute la conférence se déroule dans les locaux de l’E.P.I.T.E.C.H. (Ecole pour l’Informatique et les nouvelles Technologies) à Lyon (à 5min. de la gare Part-Dieu).

Mardi prochain, le 15 février, le Lyon JUG présente une soirée autour de la thématique du Business Process Management (BPM) et de Bonita Open Solution, solution Open-Source complète BPM. Une soirée particulière puisque les personnes intéressées auront l’opportunité de se lancer dans l’utilisation de Bonita, avec un mini-exercice encadré sous les conseils du speaker, Mickael Istria.
Mickael est l’un des développeurs du Studio de Bonita Open Solution chez BonitaSoft, C’est un grand fan d’Eclipse depuis quelques années, et avant de rejoindre BonitaSoft, il était committer et release engineer sur le project Eclipse Java Workflow Tooling. Au-dela d’Eclipse, il s’intéresse notamment aux différentes manières de rendre le développement Agile, grâce à l’architecture logicielle et l’intégration continue.

@mickaelistria

Agnès : Tu vas aborder dans ta session du Lyon JUG le vaste domaine du Business Process Management (BPM). Pour commencer, peux-tu nous dire ce qu’est pour toi un processus métier? Peut-on en distinguer plusieurs catégories en fonction des acteurs qu’ils impliquent ou de leur granularité ?
Mickael : Une définition formelle que je donne d’un processus est qu’un processus métier est la définition d’un ensemble d’étapes (humaines, automatiques ou interagissant avec d’autres parties du SI) qui permettent de répondre à un besoin métier (production d’une pièce d’usine, gestion d’une commande, accueil d’un nouvel employé…). On pourrait comparer un process métier à une recette de cuisine, sauf que le résultat n’est pas nécessairement quelque chose qu’on peut manger.
On peut observer différents types de processus métiers en fonction des besoins et des gens qui les développent. Des fonctionnels très haut niveau auront tendance à dessiner des processus très abstraits, assez loin de l’exécutable, privilégiant les interactions humaines ; alors que des développeurs habitués à une logique de « flow » auront tendance à rentrer dans des détails de connectivité avec les autres parties du SI, et utiliseront le BPM plus dans une optique de chorégraphie entre les différents acteurs et systèmes.
La différence fondamentale est que quand on dit BPM à un fonctionnel, il comprend dessin ; là où un développeur entend API.

Agnès : Comment décrire un processus métier? UML me suffit-il? Peux-tu nous présenter les autres normes existantes permettant de modéliser un processus métier ou de décrire leur exécution? Ces normes sont-elles majoritairement adoptées par les solutions BPM, ou le mode propriétaire prédomine-t-il?
Mickael : UML s’est révélé trop technique et insuffisant pour le BPM. Du coup un standard graphique a émergé et a été rapidement adopté par le monde du BPM (open-source et propriétaire). C’est une version modernisée et légèrement étendue des diagrammes d’activité d’UML. Du coup tout le monde est aligné sur cette notation graphique. Mais il s’agit juste de dessin et pas d’un format d’échange entre solutions. Le cœur de BPMN2 est extrêmement simple: des boites, des losanges, des ronds et des flèches… Ce langage se révèle plus agréable qu’UML, mais aussi plus puissant grâce à ses constructions avancées. BPMN2 possède aussi une spécification de sérialisation, qui permet d’en faire un format d’échange entre les différentes solutions BPM.
Mais pour ce qui est des langages d’exécution, c’est un autre histoire. Il y a eu BPEL, trop complexe pour la problématique BPM ; XPDL 1 puis 2, qui spécifiait l’essentiel d’un processus métier, mais pas assez pour supporter les features de tous les éditeurs ; et maintenant BPMN2, qui souffre des mêmes problèmes que XPDL lorsqu’on l’utilise comme format de sérialisation. Du coup, même les solutions qui suivent les standards d’exécutions sont obligées d’ajouter des extensions propriétaires pour supporter leurs features.
Bonita a pris le parti de ne pas se reposer sur un standard d’exécution précis, mais de conserver la possibilité d’échanger avec les autres solutions via des imports (XPDL, jBPM3, BPMN2) et exports (BPMN2) des standards et formats courants.
Je n’ai pas le sentiment que le monde propriétaire prédomine sur l’open-source en terme de technologie et de standard de BPM.

Agnès : Le grand spectre d’une architecture SOA met en exergue des processus métiers dits transverses, impliquant plusieurs services ou processus d’applications différentes communiquant à travers un Bus d’entreprise (ESB). Un point qui m’intéresse particulièrement est la manière dont la gestion transactionnelle peut être réalisée sur de tels processus (utilisation de transactions distribuées, de mécanismes de compensation). Quels sont tes retours d’expériences sur la question ?
Mickael : Le moteur de Bonita est suffisamment flexible et paramétrable pour utiliser JTA (Java Transaction API). Cela permet aux personnes qui seront responsables de l’intégration de choisir, voire de développer, leur propre gestion de transactions pour résoudre leur cas spécifique à leur système d’intégration. Ainsi il est possible d’utiliser des transactions distribuées en restant en JEE standard. Une autre solution technique est de se reposer sur la gestion de transactions d’Hibernate, utilisé par Bonita. Mais comme tu l’as compris, il s’agit de tweaker le déploiement. L’implémentation par défaut des transactions dans Bonita gère l’intégrité du moteur BPM, pas celles de tout le SI, qui sont dans la plupart des cas vraiment spécifiques. Le partage de transaction est quelque chose qui a été déjà implémenté par quelques uns de nos gros utilisateurs/clients.
Bonita sait gérer les évènements et les erreurs dans le processus, qui ont grosso-modo le même comportement que des exceptions dans le monde du Java, et permet de catcher ces erreurs pour les corriger ensuite. La compensation est donc logiquement possible dès qu’on a la possibilité d’envoyer et de rattraper les erreurs. On peut donc l’appliquer avec Bonita. Elle s’implémente facilement à l’aide de sous-process évènementiels, qui sont une construction standard de BPMN2 et supportés par Bonita.

Agnès : Tu travailles sur Bonita Open Solution, présentée comme une solution complète de BPM. Cela signifie-t-il qu’avec ce seul outil je peux à la fois modéliser, implémenter, exécuter et monitorer mes processus? Peux-tu nous en dire un peu plus sur les fonctionnalités offertes par Bonita Open Solution ?
Mickael : Yes you can ! Et plus encore… En fait, Bonita se compose de plusieurs parties :

Je pense que là où Bonita se démarque le plus, c’est dans son approche duale : BPM tout intégré, où on génère des applications prêtes à l’emploi pour les processus, mais BPM pour les développeurs aussi avec une API facile à mettre en place et à utiliser ; le tout avec un tooling qui permet une grande productivité. La plupart des autres acteurs du milieu ne s’attaquent qu’à un seul de ces problèmes.

Agnès : Sur les choix stratégiques de développements de l’offre Bonita Open Solution… Je note que Bonita Open Solution est open source dans un marché du BPM encore aujourd’hui assez dominé par quelques éditeurs propriétaires. Quelles sont les raisons qui ont poussé l’entreprise à choisir ce type de licence? En quoi cela est-il potentiellement un atout pour la solution ?
Mickael : C’est avant tout culturel et historique. Bonita est né dans les laboratoires de l’INRIA de Nancy il y a maintenant 10 ans. A l’époque, c’était Miguel Valdes Faura, aujourd’hui PDG de BonitaSoft, qui le développait (depuis Bonita a été entièrement réécrit plusieurs fois, je vous rassure ). Le lien entre la recherche et l’Open-source est très fort, si bien que Bonita a toujours été Open-source, et que ça ne changera pas, ça fait partie du produit, des développeurs et de l’entreprise.
Ceci présente de nombreux avantages sur le marché, ce qui tombe bien car le mot d’ordre de BonitaSoft est « démocratiser le BPM ». D’abord Open-source implique qu’on peut s’attaquer au problème sans payer le moindre dollar. Or le BPM est généralement quelque chose d’onéreux, que les concurrents propriétaires vendent à coup des dizaines de milliers de dollars minimum. Si bien que Bonita offre aux organisations la possibilité d’évaluer gratuitement, simplement et sans engagement le BPM avant de se lancer dans l’aventure et d’investir pour obtenir un support professionnel et accéder à des fonctionnalités additionnelles de productivité et d’industrialisation des déploiements. C’est plutôt rassurant d’avoir cette possibilité lorsqu’il s’agit de mettre en place des projets critiques ! Ensuite, Open-source implique aussi que le code est ouvert et que donc quoiqu’il arrive au produit ou à l’entreprise, l’accès au code assure une certaine sécurité sur le long terme. Enfin, il y a la transparence vis-à-vis du code, de la communauté et des clients. Bref, être open-source sur un marché si cher et risqué permet cette démocratisation.

Agnès : Toujours sur les choix stratégiques de développement, tu indiques que l’équipe de Bonita utilise Scrum pour gérer le cycle de développement du produit. Quel est ton retour d’expérience sur cette méthode Agile ? Qui représente le product owner? Organisez-vous des sessions de tests fonctionnels / tests d’intégration à chaque sprint?
Mickael : Ce que j’adore dans les méthodes Agiles, c’est leur réalisme. On ne se fixe pas d’objectif impossible, on se félicite des succès et on s’avoue les échecs, et on peut en tirer les conséquences très vite. Tout ce réalisme amène à un cadre de travail très plaisant et à une bonne ambiance dans l’équipe. Au final, Scrum nous a permis de produire très vite un produit de très bonne qualité, que ce soit vu de l’extérieur (features) ou de l’intérieur (qualité du code).
Le rôle de product owner est joué par Charles Souillard, directeur technique et co-fondateur de BonitaSoft, qui nous élabore la roadmap à partir des diverses évolutions demandées au produit, par la communauté d’utilisateurs, de clients, par le marché, ou encore par nous qui avons parfois nos petits caprices qu’on veut vraiment implémenter
Pour le testing, on se félicite déjà de notre suite de tests automatisés (~2300 tests sur chaque OS), qui contient environ 50% de tests unitaires et 50% de tests d’intégration. Chaque jeudi après le repas, on organise une petite session de tests d’une ou 2 heures pour tester les nouveautés, puis une demie-journée en fin de sprint, et une semaine avant chaque release. On a récemment eu le plaisir d’étendre l’équipe R&D avec en place une équipe QA à Pékin en Chine qui effectue des tests fonctionnels, et je dois avouer qu’on a quasi-immédiatement ressenti un grand progrès dans la qualité du produit et dans notre confort de développement. On est actuellement dans une période ou bien qu’on ajoute des features, le code continue de s’améliorer, et ce en grande partie grâce aux méthodologies Agiles.

Merci Mickael!

Les inscriptions sont ouvertes! Rendez-vous sur le site du Lyon JUG

Mardi prochain, le 18 janvier, le Lyon JUG propose une soirée autour de la thématique de Messaging. Pour vous donner envie de vous rendre à cette soirée, voici l’interview de Jean-Frédéric “Jeff” Mesnil. Jeff écrit des logiciels de middleware liés au messaging, aux transactions distribuées et à la réplication de base de données depuis une décennie. Récemment, il a travaillé sur HornetQ, l’implémentation de messaging de JBoss et Red Hat. Il écrit maintenant des logiciels de data mining pour un éditeur de sites Web, Bestofmedia.
Lors de cette même soirée, Arnaud Simon viendra également nous parler d’AMQP, et d’une de ses implémentations Apache Qpid (voir l’interview d’Arnaud également sur le site des JDuchess).

Agnès : Tu es un des leaders du projet HornetQ. Peux-tu nous présenter brièvement ce projet, notamment son “ontologie” (vis-à-vis de JBoss Messaging, de son intégration dans JBoss Application Server 6). Comment évolue-t-il? Qui est garant de ses évolutions?
Jeff : HornetQ est le successeur de JBoss Messaging. JBoss Messaging était le service de messaging fourni par JBoss AS. Quand Red Hat et JBoss ont défini la roadmap pour le messaging, il a été convenu que la base de code de JBoss Messaging n’était plus adaptée à certaines nouvelles contraintes (notamment pour embarquer un service de messaging dans une application). On a donc ré-architecturé le projet pour simplifier son utilisation, maximiser ses performances tout en offrant un panel de déploiement couvrant toutes les attentes de nos utilisateurs. Au fur et à mesure de la réécriture du code, il est devenu apparent que la nouvelle base de code était fondamentalement différente de celle de JBoss Messaging. Red Hat a alors décidé de renommer le projet pour marquer ce changement global.
Il y a un noyau de développeurs qui travaillent sur HornetQ employés par Red Hat et autour d’une communauté qui contribue de façons diverses et variées (bug report, patches, RFE, support sur les forums, etc.). HornetQ est devenu le service de messaging par défaut dans JBoss AS 6 et dans la prochaine version d’EAP. HornetQ est aussi beaucoup utilisé en mode “standalone” afin de fournir un serveur de messaging servant de bases à la communication d’applications plus complexes.

Agnès : Qu’est-ce qui le distingue d’une part des autres MoM (peux-tu en particulier nous parler de ses points forts vis-à-vis du cloud, notamment d’une solution PaaS) et d’autre part du projet JBossESB?
Jeff : Un aspect important du développement d’HornetQ est les performances. Un benchmark indépendant a été utilisé pour montrer les performances d’HornetQ comparées aux autres MOM du marché (Open Source et propriétaires). HornetQ est premier dans la plupart des scénarii (et avec une bonne longueur d’avance dans beaucoup!)
Un MOM est souvent utilisé comme base de communication pour les applications complexes. Les performances globales de l’application sont alors liées aux performances du MOM et de sa capacité à passer à l’échelle.
L’architecture d’HornetQ basée sur Java NIO permet un passage à l’échelle en évitant les goulots d’étranglements induits par du code bloquant. Dans HornetQ, le chemin du code est asynchrone et ne bloque pas, par exemple en attendant de recevoir des données du disque dur ou du réseau. Nous essayons aussi de rendre HornetQ le plus simple possible à configurer même si c’est souvent un compromis entre la simplicité de la configuration et la possibilité de configurer “au mieux” en fonction de son utilisation. HornetQ dispose d’une documentation exhaustive et d’exemples pour chacun de ces fonctionnalités afin de les appréhender au cas par cas avant de les combiner en utilisation réelle.
JBossESB et HornetQ sont à deux niveaux de fonctionnalités différents. HornetQ fournit un service de messagerie asynchrone. JBossESB fournit des services de plus haut-niveau (transformation, routage) qui peuvent utiliser les messages comme méthode de communication. Dans ce cas, JBossESB bénéficie “automatiquement” des performances de HornetQ.

Agnès : HornetMQ supporte STOMP et depuis peu REST. Qu’en est-il d’AMQP? Que penses-tu de ce standard, ce protocole “wire-level”?
Jeff : Arnaud Simon qui présentera AMQP au JUG de Lyon est mieux placé que moi pour répondre
Pour HornetQ, nous avons décidé dans un premier temps de supporter STOMP pour l’interopérabilité avec d’autres plateformes que Java. STOMP est un bon protocole pour l’interopérabilité: il est simple, basé sur du texte. Par contre, il ne permet pas d’obtenir les mêmes performances qu’un protocole binaire. AMQP offre un tel protocole et plus encore: il définit aussi le comportement des brokers pour envoyer et recevoir des messages mais aussi la topologie du système. Il semble pour l’instant qu’il n’y ait pas encore de consensus pour la sortie d’une version 1.0 du protocole et les différents brokers qui implémentent AMQP ne sont pas tous capables de discuter entre eux. C’est un gros point négatif pour un protocole censé assurer l’interopérabilité entre les implémentations…

Agnès : Peux-tu nous parler de l’architecture d’HornetQ (ses couches applicatives, ses dépendances)? Puis-je l’embarquer facilement dans mon application java (utile pour la partie tests unitaires par exemple)?
Jeff : En tirant les leçons de JBoss Messaging, il a été décidé très tôt de rendre HornetQ plus facilement déployable et intégrable. A la base, HornetQ est un ensemble de classes Java “POJO”. HornetQ ne dépend que d’un seul jar pour Netty, le remarquable framework NIO. Il suffit d’inclure le jar d’HornetQ et celui de Netty pour embarquer un serveur de messaging complet dans n’importe quelle application Java. Cela est rendu encore plus facile par l’utilisation d’un framework comme JBoss Microcontainer ou Google Guice mais vous pouvez aussi instantier directement les classes de HornetQ. Un autre aspect important de HornetQ est son “journal”. Il s’agit du composant chargé de persister les messages sur disque pour éviter de les perdre en cas de crashs. HornetQ n’utilise pas de bases de données relationnelles mais une bibliothèque utilisant Java NIO pour son journal afin de garantir la persistance des données de manière fiable et rapide. Si HornetQ est exécuté sur Linux, nous supportons la lib asyncio qui permet encore d’augmenter les performances du journal. Le reste des dépendances est optionnel et dépend de l’utilisation d’HornetQ. Ainsi, la couche JMS est écrite en fonction du propre protocole de messaging de HornetQ. Pour bénéficier du support de JMS dans HornetQ, il suffit de rajouter un jar pour l’API JMS et hornetq-jms.jar.
Pour les tests unitaires, il est ainsi possible de créer en quelques lignes de code un serveur HornetQ en mémoire qui ne nécessitera aucun port ouvert (tous les échanges de message se feront en mémoire, les clients et le serveur étant dans la même JVM) et aucun accès disque dur (en désactivant la persistance des messages par exemple). Cela permet de tester le code fonctionnel de manière très simple sans installer une infrastructure complète au préalable.

Agnès : Un peu de teasing… Peux-tu nous parler de la roadmap d’HornetMQ?
Jeff :L’équipe d’HornetQ est au four et au moulin pour sortir HornetQ 2.2 très bientôt. Cette version étendra et simplifiera le déploiement de cluster de serveurs HornetQ et permettra une meilleure haute-disponibilité du service tout en simplifiant son déploiement. L’implémentation de STOMP a été aussi optimisé et ses performances deviennent vraiment intéressantes. De façon plus générale, HornetQ devient aussi le service de messaging par défaut dans JBoss AS 6 et sera disponible dans la prochaine version de JBoss EAP. Je ne veux pas gâcher les prochaines annonces de Clebert Suconic, le project lead de HornetQ, mais attendez-vous à des développements intéressants autour du cloud computing et des smartphones. Si vous venez me voir après la présentation au JUG de Lyon, je vous en dirai peut-être un peu plus

Merci Jeff!

Merci à Anne-Laure Rigaudon pour son aide précieuse sur la relecture de cet interview.

Les inscriptions sont ouvertes! Rendez-vous sur le site du Lyon JUG

Mardi prochain, le 18 janvier, le Lyon JUG propose une soirée autour de la thématique de Messaging. Pour vous donner envie de vous rendre à cette soirée, voici l’interview d’Arnaud Simon, Senior Solution Architect pour la division Red Hat middleware. Arnaud travaille sur les solutions de Messaging et ESB et contribue également à l’écriture des spécifications AMQP (Advanced Message Queuing Protocol) et au projet Apache Qpid, une implémentation AMQP.
Lors de cette même soirée, Jeff Mesnil viendra également nous parler d’HornetQ, la nouvelle implémentation de messaging de JBoss (voir l’interview de Jeff également sur le site des JDuchess).

Agnès : Une des caractéristiques d’AMPQ est qu’il se définit apparemment comme un protocole “wire-level”, permettant de standardiser les échanges entre serveurs de messages. Comment pourrais-tu le définir, notamment en quoi se distingue t’il d’autres tentatives de standardisation comme l’API JMS ou, au niveau protocole, de CORBA/IIOP? Dans mes vieux souvenirs un peu poussiéreux, les tentatives de standardisation qui me semblent les plus proches d’AMQP sont les spécifications émanant de l’OMG : Notification Service basée sur CORBA et étendant la spécification antérieure Event Service.
Arnaud : AMQP définit non seulement le protocole réseau mais aussi les sémantiques d’échange des messages ce qui permet une interopérabilité et une portabilité totale des applications. L’API JMS définit uniquement les sémantiques d’échange des messages et ne garantit donc que la portabilité des applications clientes Java d’un fournisseur à un autre. Les communications inter-fournisseurs nécessitent l’utilisation de ponts “bridges” assurant la transformation des messages d’un format à un autre. Toutes ces contraintes vont disparaître avec AMQP qui permet d’échanger des messages entre applications Java, C++, python, etc. et ceci indépendamment du fournisseur. AMQP offre donc une réelle indépendance de choix tant au niveau de la plate-forme que du fournisseur. AMQP n’a pas pour vocation première de fournir une API, même si le groupe de travail en discute, mais a été pensé afin de facilement supporter JMS. La version 1.0 d’AMQP a pour vocation de devenir un standard.

Agnès : Qui “se cache” derrière AMQP? Comment le protocole évolue? Tout le monde peut-il apporter sa contribution?
Arnaud : AMQP a été créé il y a maintenant plus de quatre ans sous l’impulsion de JPMorgan et Red Hat. De nombreuses sociétés du monde des finances ont rapidement rejoint le groupe de travail. C’est par exemple le cas de Credit Suisse et Bank of America. Des constructeurs et éditeurs contribuent aussi au développement des spécifications et à leur implémentation. C’est évidemment le cas de Red Hat mais aussi de Microsoft Corporation, Cisco Systems, Novell, Progress Software et plus récemment VMware et Software AG. Il est très facile de rejoindre le groupe de travail. Il suffit pour cela de faire part de son intention et évidemment de prendre part aux réunions hebdomadaires.

Agnès : Quels sont les cas d’utilisation standards que couvre AMPQ?
Arnaud : AMQP couvre tous les paradigmes de messagerie tels : point à point, publication/souscription, transactions distribuées, routage des messages basé sur le contenu, transfert de fichiers volumineux, sécurité, etc. Le protocole réseau a été pensé pour pouvoir atteindre des performances optimales sur les hardwares modernes. Son utilisation est donc des plus larges même si le secteur des finances reste privilégié par son besoin de performance élevé. Le monde du SOA et plus particulièrement les ESB basés sur AMQP gagnent aussi en interopérabilité et en flexibilité.

Agnès : Il existe plusieurs implémentations d’AMQP comme par exemple RabbitMQ, OpenAMQP et Apache Qpid. Sans rentrer dans une comparaison exhaustive, qu’est-ce qui distingue ces différentes implémentations?
Arnaud : Je resterai bref et certainement partial. OpenAMQP est un projet qui semble mort. Les membres d’OpenAMQP n’ont pas modifié le projet depuis longtemps maintenant et ont de surcroit quitté le groupe de travail. RabbitMQ est maintenant sous le contrôle de VMware et implémente AMQP 0.9.1. Apache Qpid implémente AMQP 0.10 et AMQP 1.0 est en cours d’implémentation. Qpid offre un grand nombre de clients, un serveur C++ pour linux mais aussi pour Windows ainsi qu’un serveur Java. Les fonctionnalités sont très riches et sont source d’inspiration pour AMQP.

Agnès : Tu travailles chez Redhat, et notamment sur Apache Qpid. Peux-tu nous présenter brièvement la solution Red Hat Enterprise MRG, qui s’appuie justement sur Apache Qpid?
Arnaud : Red Hat Enterprise MRG intègre un serveur de messagerie « M », un noyau linux temps réel « R » et des technologies de grille informatique, « G ». MRG-M s’appuie sur Apache Qpid et intègre le serveur C++ spécifiquement optimisé pour Linux ainsi qu’un grand nombre de clients : Java JMS, C, C++, .net, python, etc. MRG-M est considéré chez Red Hat comme la colonne vertébrale pour une informatique distribuée haute performance, les déploiements SOA et les systèmes de cloud. MRG-M offre des performances jusqu’à 100 fois supérieures aux solutions du marché et grâce à AMQP, une interopérabilité sans précédent.

Merci Arnaud!

Merci à Anne-Laure Rigaudon pour son aide précieuse sur la relecture de cet interview.

Les inscriptions sont ouvertes! Rendez-vous sur le site du Lyon JUG