Revue de Presse Xebia

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

Actualité éditeurs / SSII

Enfin une intégration native de Maven à Eclipse

Le coin de la technique

Actualité éditeurs / SSII

Enfin une intégration native de Maven à Eclipse

Le projet q4e vient d’être proposé à la fondation Eclipse. Ne vous réjouissez pas trop vitre pour autant, d’après leur roadmap, la première release est prévu pour septembre 2008. En attendant, il est possible d’essayer d’utiliser la version actuelle 0.2.3.

Plus d’info sur http://www.eclipse.org/proposals/iam/.

Le coin de la technique

Les 12 commandements pour préparer le ‘troubleshooting’ de production

Daniel Julin, WebSphere Serviceability, nous livre ses 12 ways you can prepare for effective production troubleshooting :

Créer et maintenir à jour un schéma d’architecture système.
Créer et suivre un inventaire des éléments qui permettent de diagnostiquer les problèmes (localisation des fichiers de logs, etc).
Attacher une attention particulière aux dumps et autres éléments qui ne sont générés que lorsqu’un problème survient (cores système, javacores, heap dumps, First Failure Data Capture – FFDC, etc)
Revoir et améliorer les niveaux de logs durant le fonctionnement normal de la plateforme.
Suivre les indicateurs des couches système d’exploitation et réseau (cpu, disque, trafic réseau inter composants, etc).
Etre préparé à générer des informations de diagnostique complémentaires lorsqu’un problème survient (générer des dumps, collecter des métriques, générer de l’activité métier, etc).
Définir une procédure de collecte d’informations de diagnostique et s’entraîner à exécuter cette procédure.
Etablir une image de référence pour connaître la valeurs des indicateurs et logs lorsque la plateforme fonctionne correctement (logs, dumps générés à la demande, niveaux d’activité cpu/disque/réseau, débit moyen des applications, etc).
Purger et archiver régulièrement les logs et les dumps.
Eliminer les ‘fausses erreurs’ et autres messages bruyants des logs.
Maintenir un change log des modifications de la plateforme.
Mettre en place des outils de supervision de bon fonctionnement du système.

Une liste pleine de bon sens qui sera une bonne base de réflexion pour aborder le ‘troubleshooting’ de production.

WebSphere MQ Low Latency Messaging : le ‘multicast messaging’ version IBM

IBM annonce la sortie de WebSphere MQ Low Latency Messaging version 2, un middleware de message destiné aux places de marchés [1] capable d’envoyer jusqu’à 3 millions de messages par seconde avec une latence de quelques dizaines de microsecondes.

Quelle est la différence entre Websphere MQ Low Latency Messaging et le classique Websphere MQ utilisé en informatique de gestion ?

Websphere MQ Low Latency Messaging repose sur un modèle de distribution multicast : l’émetteur envoi un seul exemplaire du message via un multicast UDP que reçoivent tous les destinataires. Ce modèle est particulièrement adapté aux scénarios ayant un très grand nombre de destinataires (one-to-very-many) mais est inadapté à la garantie d’acheminement des messages qui requiert de contrôler que chaque destinataire a reçu le message et de gérer le cas échéant les ré-envois sans pour autant envoyer plusieurs fois le même message à un destinataire.
Le classique Websphere MQ repose sur un modèle hub-and-spoke : l’émetteur envoi un exemplaire du message à un hub (le Queue Manager) qui prend en charge l’acheminement du message à chacun des destinataires. Ce modèle permet de gérer facilement la garantie d’acheminement et tient bien la charge tant que le nombre de destinataires est limité. La principale difficulté du modèle hub-and-spoke est la haute disponibilité qui nécessite la mise en cluster du hub.

Pour conclure, Websphere MQ et Websphere MQ Low Latency reposent sur deux modèles fondamentalement différents : hub-and-spoke et multicast. Si le modèle hub-and-spoke est adapté aux scénarios classiques d’informatique de gestion en offrant des fonctionnalités riches (garantie d’acheminement, etc), il devient inadapté lorsque le nombre de destinataires augmente. A l’inverse, le modèle multicast offre de grandes performances dans les scénarios qui impliquent un très grand nombre de destinataires mais cela se fait au dépend des fonctionnalités comme la garantie d’acheminement qui devient très complexe.

Qu’en est-il de l’offre de Tibco, le principal concurrent de Websphere MQ ? Tibco propose également les deux modèles de middlewares de messages : Tibco Rendezvous (RV) repose sur le modèle multicast et le récent Tibco Enterprise Messaging Service (EMS) repose sur le modèle hub-and-spoke [2]. On notera que :

Seul Tibco EMS offre un connecteur JMS ; Tibco Rendezvous expose une API Java propriétaire. On peut y voir que Tibco positionne plus EMS pour l’informatique de gestion classique.
Tibco Rendezvous propose deux mécanismes pour pallier au problème de garantie d’acheminement du modèle multicast : RV Certified Messaging (le message est acheminé au moins une fois, avec un risque de duplication) et RV TX (le message est acheminé exactement une fois, avec une dégradation sensible des performances).

[1] Plus de détails dans Smart Money : IBM WebSphere Products Improve Financial Markets Firms’ Ability to Manage Growing Market Data Volumes and Speeds.
[2] Voir Tibco RV vs Tibco EMS by Narendra Naidu.

Spring 2.5 released

Spring 2.5 vient d’être releasé et apporte son lot de nouveautés que vous pouvez consulter ici.

InfoQ se lance pour l’occasion dans un découverte des apports de cette version 2.5 : http://www.infoq.com/articles/spring-2.5-part-1.

Nous avions déjà traité des nouveautés de Spring 2.5 dans notre revue de presse de la semaine dernière :

Réduction et simplification des configurations XML
- Java Config
- XML namespaces « jms » et « context »
- etc
Componentisation avec OSGI
Unification des accès aux systemes externes avec JCA 1.5
Support officiel de Websphere

Comparing JVM Web Frameworks Videocast

Dans la revue de presse précédente, nous parlions de la comparaison des principaux framework de présentation effectuée par Matt Raible. JavaZone vient de publier une vidéo de cette même analyse dans laquelle les frameworks Jsf, Spring MVC, Struts 2, Stripes, Tapesty, Wicket sont détaillés sous deux angles de vue principaux : un premier aspect « technique » étudiant les fonctionnalités offertes par chacun des framework et un aspect « communautaire » mesurant l’activité de chacun.