Revue de Presse Xebia
La revue de presse de l’actualité Java/J2EE hebdomadaire proposée par Xebia.
Agilité
RIA
Le coin de la technique
- Rapide présentation de Hermes JMS Console
- Slice your database, OpenJPA
- Polémique sur l’avenir de Geronimo. IBM abandonne-t-il le projet ?
- Présentation de certains algorithmes de garbage collection de la JVM de Sun
Agilité
3 bonnes résolutions pour cette nouvelle année
Un agiliste propose des bonnes résolutions pour les équipes agiles. Peut-être que vos bonnes résolutions de cette année devraient déjà être de passer aux méthodes agiles …
Top 5 developer benefits of agile development
Cet article présente les 5 principaux bénéfices des développements agiles sur les équipes de développements :
- Un lien plus étroit avec les clients : l’équipe est en contact direct avec les clients et de ce fait, la qualité du produit mis en place est plus en accord avec les attentes des clients.
- Une équipe plus autonome : c’est à l’équipe de décider comment réaliser le sprint. Le but est de faire confiance aux équipes de développement et de leur donner plus de responsabilités.
- Laisser l’équipe prendre des décisions : lorsque des problèmes trop complexes se présentent, il est préférable de laisser les personnes plus à même de comprendre les impacts d’une évolution ou d’un changement prendre les décisions.
- Améliorer la participation de l’équipe : favoriser la constitution de petites équipes (7 personnes environ) permet aux différents membres de participer.
- Des développeurs plus productifs : la mise en place des méthodes agiles permet d’avoir des développeurs plus épanouis dans leur travail, car ceux-ci sont plus valorisés.
Pour finir, les méthodes agiles entraînent certains changements et entre autre, dans le cas de cet article, la confiance envers les équipes de développements doit être plus grande. En conclusion de ces méthodes agiles, il en résulte que les clients sont mieux satisfaits, et avec un produit de qualité.
RIA
BEA Workshop et Flex Builder en bundle
Nous apprenons dans cet articleque BEA propose sur son site un bundle spécial comprenant son IDE Workshop et l’IDE Flex Builder d’Adobe. Aucune information en revanche le support apporter par BEA sur l’IDE ou sur la technologie Flex.
Flex semble être adopté par certains éditeurs du monde Java/J2EE, Oracle en Novembre dernier lors de son « Oracle OpenWorld » avait déjà présenté plusieurs utilisations maison de Flex.
Google sait indexer le contenu Flash
Ce n’est pas un fait très connu, mais oui Google sait indexer les fichiers Flash! Une recherche sur Google sur le type de fichier « swf » permet de s’en assurer: près de 23 millions de fichiers indexés. En revanche, Google n’indexe que le contenu statique, en « dur » dans le code. Donc pas d’indexation pour les boutiques en ligne développées en Flex… Mais de nouvelles possibilités se profilent à l’horizon, d’après cet article sur le blog CNET, Google utilise désormais le Search Engine SDK d’Adobe pour parser les fichiers Flash. Ce qui signifie deux choses:
- les développeurs vont pouvoir utiliser le Search Engine SDK pour optimiser le référencement de leurs fichiers Flash
- pour peu qu’Adobe mette à jour son outil, on peut espérer dans un futur proche avoir la possibilité de référencer des applications Flex sans avoir à recourir à des techniques un peu barbares (copie statique HTML du contenu de l’application Flex par exemple…)
Le coin de la technique
Rapide présentation de Hermes JMS Console
Sur le blog Dev2Dev de BEA, on peut actuellement trouver une rapide présentation de Hermes JMS Console. Cette petite console est bien pratique pour explorer des files JMS et devrait faire partie de la trousse de base des développeurs. Pour la tester, c’est ici que ça se passe.
Slice your database, OpenJPA
Pinaki Poddar, employé BEA et committer sur le projet Apache OpenJPA présente Slice [1] , une extension d’OpenJPA qui permet un partitionnement horizontal multi-instances des bases de données (aka database sharding).
Si Slice est fonctionnellement un concurrent direct d’Hibernate Shards, ce n’est encore qu’un ‘proof-of-concept’ développé par une seule personne dans un sous projet de l’Apache Lab Fluid ( »JPA for Service Data Object »).
Nous sommes très loin d’une version release (les règles des Apache Labs stipulent qu’un lab ne peut pas faire de release) et on regrettera que Slice n’ait pas été développé en tant que sous-projet d’OpenJPA pour lui assurer un avenir plus certain.
Pour ceux qui espèrent voir OpenJPA s’étoffer pour concurrencer Hibernate, il faudra hélas patienter.
Nous en profitons pour émettre un voeu pour 2008 : l’intégration d’OpenJPA au moteur de recherche Lucene pour rivaliser avec Hibernate Search ; ce besoin est sûrement moins ‘hype’ que la ‘database sharding’ mais beaucoup proche des réalités de nos projets d’informatique de gestion.
[1] Ressources complémentaire sur BEA Dev2dev Blog : Slice : OpenJPA for Distributed databases part I and Part II.
Polémique sur l’avenir de Geronimo. IBM abandonne-t-il le projet ?
The Server Side (TSS) commence l’année 2008 avec la très belle polémique Geronimo: Are its days numbered ?. Le résultat est là. Plus de 50 commentaires souvent acerbes, un grande séance de ‘websphere bashing’ toujours aussi peu argumentée ; de la vraie polémique The Server Side 
Après s’être bien amusé avec le sensationnalisme de TSS, revenons sur les faits.
Le serveur J2EE Open Source Apache Geronimo a été lancé en 2003, époque à laquelle le serveur open source JBoss faisait frémir les éditeurs commerciaux qui voyaient en lui un concurrent très menaçant et d’un type nouveau auquel il n’avaient pas l’habitude d’être confronté.
A l’époque, les branches système d’exploitation et environnement de développement d’IBM avaient déjà adressé des concurrents open source (Linux et Sun NetBeans) en promouvant des alternatives elles aussi open source (Linux et Eclipse). Cette approche de type « quitte à ce que quelqu’un scie la branche sur laquelle je suis assis, autant que ce soit moi pour que j’anticipe mieux » a permis à IBM de très bien se placer sur Linux et de devenir l’acteur clef de la gouvernance du socle de développement aujourd’hui quasi-universel qu’est Eclipse.
IBM a racheté en 2005 GlueCode, la société fondatrice de Geronimo, et on peut voir dans cette stratégie des similarités avec la gestion par Big Blue des enjeux Linux et Eclipse.
La suite des événements est elle, en revanche, légèrement différente mais pas moins à l’avantage d’IBM :
- JBoss n’a pas balayé les serveurs d’applications commerciaux comme le prédisait Marc Fleury, son virulent fondateur.
- JBoss, racheté par RedHat en 2006, est progressivement devenu un concurrent ‘classique’ pour les éditeurs commerciaux.
- BEA, le principal concurrent d’IBM sur le marché des serveurs d’applications, connaît des rumeurs récurrentes de rachat (cf. Oracle announces bid to buy BEA).
- Le serveur commercial d’IBM, Websphere Application Server, connaît une croissance forte et des parts de marché très solides chez ses clients.
- Les serveurs J2EE commerciaux comme open source rencontrent aujourd’hui un nouveau type de concurrence : les simples moteurs de servlet comme Tomcat (cf Is it a Tomcat, or the Elephant in the Room? par Rod Johnson, fondateur de Spring Framework).
JBoss et les serveurs J2EE open source ne sont plus aujourd’hui des concurrents aussi menaçant qu’ils ne l’étaient lors du rachat de Glue Code ; il n’est donc pas étonnant que l’engagement d’IBM sur Geronimo semble aujourd’hui moins intense. Il ne s’agit pas d’un abandon mais juste d’un focus moins important.
Parallèlement, fort de ses succès auprès de ses clients, IBM poursuit ses investissements massifs sur sa stack commerciale Websphere Application Server qui sert de socle à Websphere ESB et Websphere Process Server.
Qu’y a-t-il d’anormal à voir une entreprise ne pas « mettre tous ses oeufs dans le même panier » et réajuster sa stratégie en fonction du marché ?
Présentation de certains algorithmes de garbage collection de la JVM de Sun
Il est toujours intéressant de se pencher sur le fonctionnement du garbage collector de la machine virtuelle. Il faut cependant garder en tête que l’optimisation par changement d’algorithme de garbage collection ne fait pas de miracle : l’optimisation d’une application métier passe bien généralement d’abord par l’optimisation du code en lui-même.
Heh… Unfortunately, I don’t speak French… Is it possible for you to send me a translation of what you wrote? I’m always interested in seeing what people wrote in their pingbacks..
Hello Aviad,
Here is a basic translation :
« Presentation of some garbage collection algorithms of Sun’s JVM
It is always interesting to know about the behavior of the JVM’s garbage collector. Once should still keep in mind that optimizing an application changing the garbage collector mechanism doesn’t make miracles : optimizing a business aplication usually go through optimizing the code itself. »
Thanks for your interesting blog post, it has been a pleasure to read it.
Cheers,
Cyrille (Xebia)
« JBoss et les serveurs J2EE open source ne sont plus aujourd’hui des concurrents aussi menaçant qu’ils ne l’étaient lors du rachat de Glue Code ».
Peut-être qu’ils sont beaucoup plus entrés dans les moeurs?
After getting the translation both from Cyrille and Manuel (via e-mail, thanks both!) this is my response:
It’s true what you wrote. However, I’d like to add two things: (1) I didn’t mention how to choose a certain GC, as it matters not, because of (2) the JVM usually picks the right GC based on the amount of memory and the amount of processors your machine has.
It’s interesting to see how GC works, because then you’ll be confident that it works well and you won’t try to make « tricks » to outperform it – It’s almost impossible to outperform the GC. But that’s another post’s point.
Bonjour Alexis,
Pris par les exigences de concision de notre revue de presse, j’ai manqué de clarté. Quelques précisions :
JBoss est moins menaçant qu’en 2003/2005
A cette époque, certains croyaient que les grands éditeurs commerciaux de serveur J2EE seraient balayés par cette startup qui apportait une concurrence d’un nouveau genre. Cela n’a pas été le cas.
JBoss a certes de très belles parts de marché mais n’a pas ébranlé les positions des éditeurs commerciaux et il n’y a pas de raison que cet équilibre soit bouleversé dans un futur proche.
JBoss est progressivement devenu un acteur similaire aux éditeurs commerciaux. C’est maintenant un acteur très ‘classique’ (avec des commerciaux, du marketing, des contrats de support, etc) auxquels les éditeurs commerciaux sont habitués. Le côté menace d’un nouveau genre s’est estompé.
La banalisation des serveurs J2EE open source professionnels
Comme vous le disiez, les serveurs J2EE open source se sont banalisés (Geronimo, GlassFish, JBoss). Cependant, c’est de l’open source largement supporté par des éditeurs commerciaux qui proposent une offre de support.
On peut y voir une nouvelle équation économique de la commercialisation de logiciel : un éditeur porte un projet open source (souvent avec une gouvernance exclusive) et vend du support.
Tomcat, la nouvelle menace des serveurs J2EE
Les serveurs J2EE rencontrent aujourd’hui une nouvelle forme de concurrence avec l’essor moteur de servlet open source Apache Tomcat.
C’est une fois de plus une concurrence en rupture qui s’inscrit dans la lignée des ‘lightweight containers’ (Spring Framework, etc).
Face à ce concurrent, JBoss, l’ancien challenger, se retrouve aujourd’hui tout aussi historique que BEA, IBM ou SUN.
Les éditeurs de serveurs J2EE sont armés pour répondre à Tomcat et l’émulation se fera au bénéfice des clients
Cyrille (Xebia)
> JBoss a certes de très belles parts de marché mais n’a pas ébranlé les positions des éditeurs commerciaux et il n’y a pas de raison que cet équilibre soit bouleversé dans un futur proche.
Même avec des rachats?
> Tomcat, la nouvelle menace des serveurs J2EE
Tomcat est #1 loin devant tous les autres et depuis longtemps. La question est de savoir si ça va durer ou si les serveurs d’application vont gagner en modularité et les specifications justifier d’aller au delà de Servlet/JSP/Spring. Je pense que oui (sans m’engager sur du volume ou une date bien entendu
)
> Tomcat est #1 loin devant tous les autres et depuis longtemps.
A tout seigneur, tout honneur [1]. MySQL, dans le domaine des SGBD, est largement plus utilisé en production que Tomcat
.
> si les serveurs d’application vont gagner en modularité
Les profiles JavaEE et les modèles de composants (JSR 291 – OSGI, JSR 277 – Java Module System, HK2) [2] sont des voies prometteuses pour modulariser nos serveurs d’application mais
- J’espère que le très politique débat OSGI versus JSR 277 – Java Module System ne va pas ralentir le JCP
- Tomcat va peut être emprunter plus vite ce chemin avec le rachat par Spring Source de Covalent, l’acteur clef de Tomcat. Rod Jonhson, fort de la récente sortie de Spring Dynamic Modules for OSGI, évoque à demi-mot l’osgi-fication de Tomcat.
> et les spécifications justifier d’aller au delà de Servlet/JSP/Spring
Spring a toujours été un ardent promotteur des API JavaEE (excepté EJB mais ce n’est qu’une petite partie de Java EE). On peut même voir Spring comme le démocratiseur de JMS, JTA ou JCA ; des APIs que Tomcat, à la différence des serveurs Java EE, n’implémente pas [3].
Pouvez-vous nous éclairer sur des spécifications qui nous donneront envie d’utiliser un serveur JavaEE complet plutôt qu’un simple moteur de servlet comme Tomcat ? Vous nous en avez dit trop ou pas assez
[1] Jonathan Schwartz’s blog : … we’re putting a billion dollars behind the M in LAMP
[2] Resources : Enterprise OSGi, a Discussion with Eric Newcomer, Javapolis : JSR-277 Java Module System, The Hundred Kilobytes Kernel (HK2).
[3] On remarquera en plus que les implémentations open source d’API comme JTA manquent encore de maturité, JOTM a certes beaucoup de qualité mais ObjectWeb n’a pas la notoriété de la fondation Apache.
Cyrille (Xebia)
Covalent fournit du support pour Tomcat. C’est pas tout à fait ce que j’appelerai l’acteur clef. Sérieusement, qui a entendu parler de Covalent en France?
La nuance entre « un acteur clef » et « l’acteur clef » ne vous a pas échappé. J’ai hésité entre les deux hier soir ; la prochaine fois, je serais plus précautionneux ou j’expliquerai davantage mon raisonnement, quitte à allonger mon commentaire
Tomcat, un projet à la gouvernance partagée
Identifier le(les) acteur(s) clef(s) d’un projet Apache présente quelques subtilités.
En effet, la Fondation Apache exige des projets qu’elle héberge un partage de la gouvernance sur le principe de méritocracie. Ainsi, un projet qui ne serait animé que par une société contreviendrait à l’esprit de la Fondation.
C’est notamment la raison pour laquelle le projet CXF n’est toujours pas sorti de l’incubateur : la plupart des acteurs clefs du projet étaient employés par IONA.
Ce principe de gouvernance partagée complexifie l’identification des acteurs clefs d’un projet. Une démarche est de retrouver les employeurs des committers actifs [2]. Ces sociétés proposent souvent du support commercial sur les projets auxquels participent leurs employés.
Enfin, j’insisterai sur le rôle clef des sociétés qui fournissent du support sur les middlewares open source en me référant à récent billet Support for GlassFish – What’s in it for me?
.
Covalent, acteur clef de Tomcat
quelques éléments pour voir en Covalent un acteur clef de Tomcat :
- Covalent est Silver Sponsor de la Fondation Apache (4 ème donateur après Google, Yahoo! et HP).
- Covalent est l’une des deux grandes sociétés de support de Tomcat avec SourceLabs. Covalent supporte plus de 400 organisations (notamment 50% des Fortune 500 et 20% des Global 2000).
- Covalent emploie plusieurs acteurs clefs du projet Tomcat (source Ohloh : Tomcat contributors), des committers jusqu’au PMC Members comme Jim Jagielski ou Filip Hanik.
Covalent, absent du marché français
Covalent n’a pour le moment que des bureaux aux Etats Unis et ne propose que du support en langue anglaise.
Je vous rejoins complètement sur la langue et l’éloignement qui sont des freins majeurs pour des clients.
… et je suis plein d’espoirs après le rachat de Covalent par Spring Source qui a des bureaux dans de nombreux pays [3] et qui prévoit de se développer encore plus
Cyrille (Xebia)
[1] Ce partage de gouvernance est différent de l’approche qu’ont choisi d’autres projets open source célèbres non moins célèbres comme Glassfish, JBoss, MySql, SpringFramework (cités par ordre alphabétique).
[2] Le portail ohloh et la liste des ASF Committers by Project Modules sont des bons points d’entrée pour mener cette analyse.
[3] USA, Canada, UK, The Netherlands, Germany et Australia pour le moment.
> … gouvernance sur le principe de méritocracie
Oui, les modèles de gouvernance sont différents entre les différents projets et c’est bien le challenge de springsource qui devra travailler avec deux gouvernances bien différentes. Sun en sait quelque chose.