Revue de Presse Xebia

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

Actualité éditeurs / SSII

• Hibernate 3.3 sous le signe de Maven et de JBoss Cache

Agilité

• Scrum-ban

Le coin de la technique

• AMQP, l’avenir des Middlewares Orientés Message ?
• Performance et monitoring d’une application Java

Actualité éditeurs / SSII

Hibernate 3.3 sous le signe de Maven et de JBoss Cache

Steve Ebersole, JBoss, présente dans Hibernate 3.3: Redesigned, Modular JARs and a Refactored Caching System les grandes nouveautés de la version 3.3 du célèbre framework de persistence. Nous retiendrons :

• La migration du projet vers un nouveau build basé sur Maven 2 alors que JBoss semblait jusqu’ici réticent à cet outil de la fondation Apache.
• La modularisation du monolythique hibernate.jar vers un ensemble de jars plus petits qui faciliteront la gestion des dépendances.
• Le redesign du système de cache de second niveau, pour offrir aux utilisateurs un contrôle plus fin de celui ci à travers une nouvelle SPI. Cette nouvelle SPI introduit le partitionnement du cache par ‘région’.
• L’intégration de JBoss Cache 2.x comme cache de second niveau, utilisant cette nouvelle SPI en exploitant le nouveau mécanisme de partitionnement. A noter que JBoss Cache 2.x est le seul cache supporté nativement par cette nouvelle SPI, les autres implémentations (EHCache, etc) étant ‘bridgées’ sur l’ancienne SPI aujourd’hui dépréciée.

On notera aussi que JBoss, jusqu’ici agnostique avec JBoss Micro Container, s’ouvre à OSGI avec l’appel de Steve Ebersole à la communauté pour participer à l’osgi-fication d’Hibernate (en réglant les problèmes de classloading et de redéfinition dynamique de la SessionFactory déclarés dans Jira)

Sur le futur d’Hibernate, Steve Ebersole reste flou et rappelle que JBoss communique peu sur les roadmaps. On peut y voir le mode de gouvernance exclusive des projets open source de JBoss à la différence des gouvernances partagées que nous connaissons notamment avec la Fondation Apache qui débat de ces sujets sur les mailing lists publiques. Nous noterons deux des axes de travail pour la futures version 3.4 :

• Amélioration des performances et de l’utilisation des ressources dans le cadre des scénarios de fail over en cluster. On peut y voir des synergies avec les travaux menés sur JBoss Application Server 5 et JBoss Cache.
• Introduction des « fetch profiles » qui rappellent JDO . Ces profiles permettent de définir des stratégies de requêtage en tant que metadata, et de les utiliser dynamiquement en Session à l’exécution.

L’intégralité de l’article à lire sur InfoQ.

Agilité

Scrum-ban

Corey Ladas propose aux équipes Scrum d’évoluer vers le Lean en introduisant un système de Kanban.

Le tableau des tâches utilisé par certaines équipes Scrum (avec les 3 colonnes A faire, En cours, Terminée) peut en effet rappeler le système des Kanban utilisé dans les méthode de gestion de la production Juste à temps (JAT).
Corey propose de compléter ou de remplacer certaines pratiques Scrum pour aller vers un vrai Kanban :

• Limiter le nombre de fiches (user stories) en circulation pour éviter d’avoir un tas de fiches « en cours »
• Amorcer une spécialisation fonctionnelle si le contexte s’y prête (si elle permet d’améliorer la productivité)
• Remplacer le Burndown chart par un Cumulative Flow Diagram qui apportent d’avantage d’informations

Il affirme également que la plupart des efforts dépensés dans les estimations sont du gâchis. Il rejoint ainsi le débat initié par J.B. Rainsberger sur le groupe Yahoo! extreme programming.

Au final Corey présente Scrum comme un cadre pouvant être utile à la construction d’une équipe avant d’aller vers une solution plus optimisée grâce au Kanban et au Lean.

Le coin de la technique

AMQP, l’avenir des Middlewares Orientés Message ?

Jeff Gouyd, Interop Systems, présente dans Can AMQP break IBM’s MOM monopoly? (part 2 et part 3) les grands enjeux de l’initiative AMQP (Advanced Message Queuing Protocol). Les points essentiels :

• AMQP vise à standardiser le protocole de transport des « middleware orientés message » (MOM) ; son objectif, très ambitieux, est de devenir le protocole le business messaging sur Internet à côté d’HTTP et de SMTP.
• Le marché des MOM est aujourdhui dominé par IBM (Websphere MQ) et Tibco (RendezVous et EMS) qui totalisent 93% des parts de marché selon Gartner ; le troisième acteur, Progress Software (Sonic MQ) ne détient que 2% du marché. Beaucoup de clients estiment qu’IBM et Tibco profitent de leur position pour pratiquer des tarifs élevés et être peu enclin à l’interropérabilité.
• AMQP a été initié par un client, JP Morgan Chase (JPMC) ; la version 1 du protocole est attendue pour la fin 2008 et les principales implémentations, toutes open source, sont OpenAmq (développé par iMatix pour JPMC), Apache QPid (ardement supporté par RedHat) et RabbitMQ (LShift et CohesiveFT.
• AMQP et JMS : JMS standardise l’API Java d’accès à un MOM quand AMQP standardise le protocole de communication du MOM. Ces deux standards sont complémentaires, il y aura des connecteurs JMS pour AMQP comme il en existe aujourd’hui pour Websphere MQ et pour Tibco EMS.
• AMQP et WS-RM (Reliable Messaging) : WS-RM a été introduit pour pallier au manque de fiabilité intrinsèque à HTTP alors qu’AMQP est un protocole qui intègre nativement la fiabilité ; il y a donc chevauchement. Les grandes différences d’AMQP par rapport à WS-RM sont le concept de file d’attente et le support de messages binaires. La participation de Paul Fremantle, président du comité du WS-RM à l’Oasis Group, à l’AMQP Working Group laisse augurer des synergies.
• AMQP et ESB : les ESB utilisent traditionnellement un MOM pour leur couche transport ; AMQP se positionne comme le protocole possible du MOM sous-jacent d’un ESB. Par exemple, l’implémentation AMQP RabbitMQ annonce avoir séduit des clients initialement intéressés par Websphere MQ comme transport pour leur ESB Mule.

Performance et monitoring d’une application Java

Dans un précédent article, nous vous avons présenté le top 10 des problèmes de performance.

Nicholas Whitehead présente dans Java Runtime Monitoring (part 1, part 2 et part 3) un guide sur le monitoring et la démarche d’évaluation de performance d’une application Java.

La gestion des performances applicatives suit des bonnes pratiques (APM, application performance management). Elle doit être :

• Exhaustive : tous les éléments applicatifs et leurs dépendances doivent être monitorés. Cela va de l’application au matériel, en passant par le système d’exploitation ,les différents middlewares, et toute la chaine réseau.
• Précise : afin de localiser au mieux la source des problèmes, il faut des mesures en boite blanche. Si les mesures sont faites en boîte noire (par exemple au niveau de la JVM), le problème ne pourra pas être identifié et les pistes seront nombreuses (problème mémoire, thread, garbage collector, configuration de la JVM…).
• Cohérente : un problème a, la plupart du temps, des causes multiples. Il faut relier les causes entre elles mais aussi les lier aux conséquences. Par exemple, un problème de base de données peut être remonté par les logs applicatives.
• Constante : le monitoring doit être effectué 7 jours sur 7, 24 heures sur 24. De plus, les intervalles de relevé de mesures doivent être suffisamment courts pour ne pas avoir un manque d’information. Attention cependant à l’overhead.
• Efficace : La règle d’or du monitoring est que les outils de monitoring doivent avoir un overhead minimal et garanti. Il est difficile de justifier une dégradation des performances dûe aux outils de monitoring.
• (proche du) temps-réel : selon le besoin de réactivité, les mesures doivent être collectées le plus rapidement possible.
• Tracée : Historisation, souvent négligé, est un outil très intéressant pour exploiter les applications J2EE. En effet, un problème de performance apparait dans un contexte défini (généralement de charge). Grâce à l’historisation des mesures et des problèmes, on peut caractériser repérer un problème identifié et (éventuellement) résolu. Ainsi les futures apparitions de ce problème pourront être anticipées.

Ainsi les difficultés du monitoring résident essentiellement dans :

• L’exhausitivité et la précision des informations relevées.
• L’intégration et l’articulation de sources d’information hétérogènes et nombreuses (matériel, OS, logs applicatives..)
• La gestion des spécificités de la plate-forme (spécificités applicatives, infrastructure réseau…)

Depuis la JVM 5 et surtout 6, Sun fournit beaucoup d’efforts afin de résoudre ces problèmes de performance et de monitoring sur la partie JVM. Plusieurs outils et techniques sont maintenant à votre disposition pour réaliser différentes mesures :

• API JMX, pour le monitoring à distance
• API d’instrumentation du code afin de réaliser des mesures boites blanches (java.lang.instrument)
• Un panel d’outils : hprof pour le profiling heap/CPU, jconsole pour la gestion et monitoring de la JVM (à distance), jhat pour l’analyse de la heap, jstat pour collecter des informations de performance sur la JVM, VisualVM …

Retrouvez l’intégralité des articles :

• part 1 : Run-time performance and availability monitoring for Java systems
• part 2 : Postcompilation instrumentation and performance monitoring
• part 3 : Monitoring performance and availability of an application’s ecosystem