Je toile ou j* au choix...

Resign Patterns : les nouveaux patterns

2011-12-02T08:29:00.001+01:00

Cet article est une traduction "libre" de l'excellent papier de Michael Duell qui se nomme "Resign Patterns" Ailments of Unsuitable Project-Disoriented Software.

En fait, Resign Patterns reprend le principe des Design Patterns tels que décrit par the Gang Of Four mais en proposant un tout autres types de Patterns... Je vous laisse juger de leur véracité... Je pense qu'ils ont suffisamment fait leurs preuves pour ne pas avoir droit, eux aussi, à leur gloire... ;-)

Aussi, au même titre que les patterns du GoF, je vous invite à utiliser les dénominations décrites par les Resign Patterns pour vous faire comprendre de vos collègues quand vous parlez du design d'un programme. Ainsi, vous pourrez briller en société mais surtout vous faire comprendre par vos pairs ;-)

Dans le même style, je vous conseille les excellents articles suivants :

Crédit photo : http://www.flickr.com/photos/esthervargasc/6010520395/

Cremational Patterns

Cette catégorie de Patterns en regroupe 5 :

Abject Poverty

Le Abject Poverty Pattern est visible dans les logiciels qui sont si difficiles à tester et à maintenir que cela abouti généralement à un dépassement de budget pharaonique.

Blinder

Le Blinder Pattern est la solution opportune à un problème sans qu'aucune anticipation n'ait été faite sur de futurs modifications dans les exigences. Il est difficile de savoir s'il est nommé de la sorte en raison de la pauvre vision des personnes qui ont faites le design du logiciel pendant la phase de développement, ou du désir de faire souffrir ses yeux pendant la phase de maintenance.

Fallacy Method

Le Fallacy Method Pattern est visible dans le traitement de cas particuliers. La logique semble correct mais si quiconque tente de tester ces cas aux limites ou s'ils venaient à se produit, alors les erreurs de logiques apparaitraient au grand jour.

ProtoTry

Le ProtoTry Pattern offre une façon rapide et sale de développer un logiciel. Généralement, l'intention première est de vouloir réécrire le code utilisant le ProtoTry mais en l'améliorant en mettant en pratique les leçons apprises pendant la phase de conception. Malheureusement, souvent, un planning inadapté ne le permet pas. Le ProtoTry est aussi connu sous le nom de code Legacy.

Simpleton

Le Simpleton Pattern est un pattern extrèmement complexe utilisé pour faire une tache triviale. Le Simpleton offre un indicateur fiable sur le niveau de compétence des concepteurs du code.

Les Destructural Patterns

Cette catégorie de Patterns en regroupe 7 :

Adopter

L'Adopter Pattern fournit un foyer à toutes les fonctions orphelines. Il en résulte une large famille de fonctions qui ne se ressemblent pas et qui n'ont de commun que le fait d'avoir été adopté.

Brig

Le Brig Pattern est un conteneur de classes pour le mauvais logiciel, aussi connu sous le nom de Module.

Compromise

Le Compromise Pattern est utilisé pour trouver un compromis entre la qualité et le planning. Il en résulte généralement un logiciel d'une piètre qualité qui, de plus, est en retard.

Detonator

Le Detonator Pattern est extrèmement commun mais souvent indétectable. Par exemple, une implémentation fréquente du Detonator Pattern est l'utilisation des deux derniers chiffres d'une année lors de la manipulation et le calcul appliqué à des dates. La bombe est présente et n'attend qu'à faire son travail...

Fromage

Le Fromage Pattern est souvent remplis de trous. Il consiste en une multitude de petites astuces qui rendent impossible toute portabilité du code. Généralement, plus il est vieux et plus il sent fort!

Flypaper

Le FlyPaper Pattern est écrit par une personne et maintenu par une autre. Cette dernière se retrouve alors coincé et préfèrerait périr avant de se perdre.

ePoxy

L'ePoxy Pattern est visible dans les modules logiciels fortement couplés. Lorsque le couplage entre modules augmente, c'est qu'il y a souvent le pattern ePoxy qui lie ces modules.

Misbehavioral Patterns

Cette catégorie de Patterns en regroupe 11 :

Chain of Possibilities

Le Chain of Possibilities Pattern est visible dans les gros modules peu documenté. Personne n'est sûr de l'étendu de ses fonctionnalités, mais ses possibilités semblent infinis. Il est aussi connu sous le nom de Non-Deterministic Pattern.

Commando

Le Commando Pattern est utilisé pour intervenir rapidement et faire que le travail soit fait. Ce pattern est capable de briser toutes les encapsultation afin d'accomplir sa mission. Il ne fait pas de prisonniers.

Intersperser

L'Intersperser Pattern éparpille ses fonctionnalités dans tout le système, rendant impossible le test, la modification ou même la compréhension d'une fonction.

Instigator

L'Instigator Pattern semble bénin mais permet de faire des ravages dans d'autres parties du système.

Momentum

Le Momentum Pattern grossit de manière exponentielle, en taille, en besoin mémoire, en complexité et en temps d'exécution.

Medicator

Le Medicator Pattern est un tel goulot d'étranglement en terme de performance pour le système que toute autre partie du système semble dopé aux stéroïdes.

Absolver

L'Absolver Pattern est visible dans des problème résolus par des anciens employés. Tant de problèmes historiques ont été résolus par le logiciel que les personnes présentes peuvent absoudre le logiciel de blâme en déclarant que l'Absolver est responsable de tous les problèmes présents. Aussi connu sous le nom de "It's not in my code".

Stake

Le Stake Pattern est visible dans les problèmes dirigés par un logiciel écrit par une personne qui a, depuis lors, choisi la voie du management. Ainsi, même si de nombreux problèmes se produisent, l'auteur du pattern Stake (qui est donc devenu manageur) empêchera quiconque de réécrire le logiciel sous prétexte qu'il est l'image de la réussite technique du manageur.

Eulogy

L'Eulogy Pattern est présent dans tous les projets qui emploie les 22 autres Resign Patterns. Il est aussi connu sous le nom de Post Mortem.

Tempest Method

Le Tempest Method Pattern et utilisé dans les derniers jours qui précède la livraison du logiciel. Il est caractérisé par un manque de commentaires tout en introduisant un grand nombre de Detonator Pattern.

Visitor From Hell

Le Visitor From Hell Pattern coïncide avec l'absence de contrôle sur le temps écoulé entre deux vérification d'un tableau. Ainsi, au moins une boucle de contrôle du système aura le pattern Visitor From Hell qui surchagera les données critiques.

Devoxx 2011 - What's probably coming in Java Message Service 2.0

2011-11-20T18:51:00.001+01:00

La semaine dernière, j'ai eu la chance d'aller à Devoxx en Belgique à Anvers.

Pour ceux, qui ne connaissent pas, je vous invite à aller directement à la pêche aux informations sur le site : http://www.devoxx.com/ et même à vous y inscrire l'année prochaine et/ou même mieux... d'aller assister à Devoxx France!!

Bon, sinon, pour revenir à nos moutons, cet article est un petit retour de la session de Nigel Deakin présentée à Devoxx 2011 et à laquelle j'ai assisté.

Elle avait pour objectif de montrer l'avancée des travaux sur JMS 2.0 (Java Message Service) aussi connu sous le doux nom de JSR 343. A ce jour, en version early draft, elle devrait être intégrée à JEE7.

Cet article a donc pour vocation de tenter de retranscrire ce que nous a présenté Nigel.

Pour la repositionner dans son contexte, la JSR343 fait suite à JMS 1.1 (JSR 914) et a pour but de :

Simplifier l'API de JMS :
- En utilisant CDI (Context Dependency Injection).
- En clarifiant certaines ambiguïtés présentes dans les spécifications.
Améliorer l'intégration de JMS avec les serveurs d'application :
- En intégrant plus facilement les problématiques de PaaS (Platform As A Service).
- En permettant le multi-tenancy.
- En clarifiant ses relations avec les autres spécifications de JEE7 (ou même ultérieure) : cela est notamment vrai avec la partie MDB (Message-Driven Beans) de la spécifications des EJB.
Ajouter des nouvelles fonctionnalités à l'API.

Je ne reviendrai pas sur ce qu'est JMS (Java Message Service) si ce n'est que sa version actuelle est la 1.1 et qu'elle date de 2003, mais le fait que la spécification JMS n'ait pas évoluée depuis 2003, montre bien qu'elle était solide et qu'elle répondait bien à ce pour quoi elle avait été écrite.

Cependant, autant il n'y a rien à redire quant à la réception d'un message, autant la partie émission était souvent verbeuse puisqu'il était nécessaire pour émettre un message, dans le cas des EJB, de :

injecter les factory (ConnectionFactory et Destination) à l'aide de l'annotation @Resource,
créer la Connection à l'aide de la ConnectionFactory,
créer la Session à l'aide de la Connection,
créer le MessageProducer à l'aide de la Session.

C'est seulement suite à toutes ces actions que l'émission d'un message était possible via la méthode send().

En outre, à cela, il fallait, bien sûr, gérer les exceptions checkées (JMSException pour ceux à qui cela parle ;-)) mais également la fermeture de la Session et de la Connection...

Enfin, lors de l'utilisation conjointe de JMS et des EJB, certains paramètres de méthodes (notamment lors de la création de la Session) étaient redondants car gérés par le conteneur EJB (createSession(boolean transacted, int acknowledgeMode)).

Un des prérequis principals de cette nouvelle version de la spécification est donc la simplification... simplification mais pas à n'importe quel prix puisqu'il était nécessaire de conserver la rétro compatibilité avec les versions ultérieures de la spécification.

Nigel nous a donc présenté certaines des pistes qu'ils avaient (pistes encore ouvertes à discussion).

Ce sont ces dernières que je vais essayer de retranscrire ci-dessous dans l'ordre dans lesquelles il les a énoncé.

Simplification sur la création de Sessions

Afin de simplifier l'API de JMS pour créer une Session, Nigel nous a présenté deux pistes :

Ajout d'une méthode createSession(SessionMode sessionMode) pour JavaSE où la classe SessionMode pourrait être une classe ayant comme variable d'instance le mode de transaction et le type d'acknowledge.
Ajout d'une méthode createSession() qui serait utilisée et présente seulement pour JEE.

Supprimer la lourdeur des close()

Afin de rendre moins verbeuse l'utilisation des Connection et des Session, une proposition plausible pourrait être de leur faire implémenter l'interface java.lang.AutoCloseable.

Ainsi, il serait alors possible d'avoir les résultats suivants (pour rappel, il ne s'agit que de propositions car cela est toujours à l'étude) :

avec Java 7 dans un contexte JEE :

@Resource(mappedName="...")
ContextFactory contextFactory;

@Resource(mappepdName="...")
Queue orderQueue;

public void sendMessage(String payload) {
  try (messagingContext mCtx = contextFactory.createContext() ;) {
    TextMessage textMessage = mCtx.createTextMessage(payload);
    mCtx.send(orderQueue, textMessage);
  }
}

avec CDI dans un contexte JEE :

@Resource(mappedName="...")
Queue orderQueue;

@Inject
@MessagingContext(lookup="...")
MessagingContext mCtx;

@Inject
TextMessage textMessage;

public void sendMessage(String payload) {
  textMesage.setText(payload);
  mCtx.send(orderQueue, textMessage);
}

toujours avec Java 7 dans un contexte JEE :

@Inject
@JMSConnection(lookup="...")
@JMSDestination(lookup="...")
MessageProducer producer;

@Inject
TextMessage textMessage;

public void sendMessage(String payload) {
  try {
    textMessage.setText(payload);
    producer.send(textMessage);
  } catch (JMSException e) {
    //todo
  }
}

Autres simplifications

Les autres simplifications d'API envisageables pourraient être :

de ne pas à créer préalablement un objet de type Message (ce qui pourrait permettrait de faire directement : producer.send(String/Serializable); ). Cependant, ce type d'API ne permettrait pas de positionner des propriétés sur le message et ne serait pas adapter pour des messages de types BytesMessage ou StreamMessage. A ajouter à cela la question de son pendant pour la réception
de simplifier la gestion des DurableSubscriber (http://download.oracle.com/javaee/1.4/api/javax/jms/Session.html#createDurableSubscriber(javax.jms.Topic, java.lang.String)), qui, au jour d'aujourd'hui, doivent obligatoirement posséder un identifiant client et un nom de souscription. Ces deux paramètres pourraient être rendus optionnels dans le cadre d'une utilisation conjointe avec les EJB 3.2

Vers le futur...

Autre que la simplification des APIs, Nigel nous a présenté ce que pourrait apporter JMS 2.0 dans nos besoins de demain.

Ainsi, JMS 2.0 devra, pour répondre aux besoins des problématiques de type SaaS (Software As A Service), permettre de déclarer ses ressources créées dans un serveur d'applications et de les enregistrer dans un annuaire JNDI (comme c'est actuellement le cas pour les DataSource).

Pour ce faire, de nouvelles annotations pourraient voir le jour (par exemple : @JMSConnectionFactoryDefinition et @JMSDestinationDefinition) mais également un SPI (Service Provider Interface) pour le faire de manière programmatique.

Concernant une meilleure intégration avec les serveurs d'applications (ce qui permettrait d'utiliser n'importe quel JMS Provider dans n'importe quel serveur d'application JEE), Nigel propose la solution de JCA (Java Connector Architecture), un peu comme ce qui existe avec le drivers de bases de données.

Nouvelles features

Concernant les nouvelles features de l'API, Nigel nous a ensuite présenté ce qui pourrait arriver, à savoir (en vrac) :

l'émission de messages avec un acquittement asynchrone du serveur,
la possibilité pour un client JMS d'utiliser des Future,
la possibilité d'émettre un message et de ne pas à avoir à attendre la réception d'un acquittement pour savoir si le message a bien été émis.

Il se pourrait également que la propriété JMSXDeliveryCount ne soit plus optionnelle, ce qui permettrait aux serveurs d'applications de mieux gérer le flood.

De même, la gestion des Topics hiérarchiques pourraient être rendue obligatoire.

Enfin, une meilleure gestion des batch pourrait être possible via de nouvelles API comme par exemple l'introduction de la méthode receive(Message[]).

Conclusion

En conclusion, je suis assez mitigé par cette session.

En effet, autant, je trouve que certaines propositions permettraient de rendre moins verbeuses l'utilisation de JMS, autant, je ne suis pas convaincu que pouvoir faire la même chose de différentes manières soit une bonne chose (et, cela, même si ça simplifie le travail du développeur...).

En outre, je trouve que, pour la majorité des propositions (même si elles sont totalement viables), l'axe de JEE est trop important.

Enfin, intégrer fortement CDI avec JMS m'embête un peu car cela nécessite de disposer d'un conteneur CDI, chose qui n'est pas toujours le cas dans un contexte Java SE et, même si je trouve CDI sexy, je ne pense pas que la majorité des développeurs ou que nos clients soient prêts à franchir le pas en raison de la complexité intrinsèque à CDI (bien sûr, JMS 2.0 se devait de se tourner vers le futur et CDI se devait d'être pris en compte)... enfin, il ne s'agit que d'un avis personnel... l'avenir nous dira ce qu'il en est... ;-)

Dernier point (mais là encore, c'est totalement personnel), j'aurais aimé voir une intégration des notions d'EIP (Enterprise Integration Pattern) même si la notion de filter (au sens EIP du terme) sort un peu du scope de JMS mais bon... ;-)

Pour conclure, Nigel a bien présenté la direction que pourrait prendre JMS dans un futur proche mais, comme il nous l'a fréquemment fait remarquer, il ne s'agit que de pistes et, d'ailleurs, toutes les contributions sont les bienvenues.

Petite découverte de CloudBees

2011-11-14T09:00:00.000+01:00

La semaine dernière, j'ai eu la chance d'assister à un atelier sur CloudBees chez nos amis de Xebia.

Ce dernier a été organisé avec brio par (je le fais par ordre alphabétique pour éviter tout favoritisme ;-) ) :

Comme d'habitude, organisation bien rodée et atelier préparé aux petits oignons mais ce n'est pas le but de mon article...

L'objectif de cet article est, pour ceux qui n'étaient pas présents, de faire un rapide tour d'horizon de ce qui m'a marqué dans la solution qu'apporte Cloudbees avec ses offres DEV@Cloud et RUN@Cloud. Cet article sera surtout focalisé sur la partie usine logicielle offerte par Cloudbees car c'est celle qui a été mise en avant pendant l'atelier et c'est aussi celle qui me semble la plus intéressante du point de vue de mes besoins actuels.

Je vais donc essayer de vous résumer ce que j'ai apprécié... Pour ce faire, je ne reviendrai pas sur le usecase qui a été utilisé car je pense qu'il vaut mieux assister à l'atelier et qu'il faut bien laisser un peu de suspens... ;-). De même, je ne parlerai ni de l'intérêt du cloud ni de comment mettre en place DEV@Cloud ou RUN@Cloud.

Cet article s'articulera donc en deux parties :

la première consistant en un très rapide retour sur ce que propose CloudBees,
et la deuxième sur ce qui me plait dans une approche telle que celle proposée par CloudBees.

PS : au passage, encore un grand merci aux organisateurs de l'atelier!

{DEV,RUN}@Cloud?... Kesako?

CloudBees propose deux services DEV@Cloud et RUN@Cloud.

DEV@Cloud offre, pour sa part, un service de type ~~PaaS (Platform As A Service)~~ SaaS (Software As A Service) qui offre un environnement de développement, de construction et de test en s'appuyant sur le cloud.

DEV@Cloud permet :

de collaborer avec d'autres personnes en s'appuyant sur des SCM/DVCS comme SVN ou Git,
de construire, tester et déployer de manière continue avec Jenkins,
de tester l'application web cible en s'appuyant sur le service à la demande SauceLab,
de controler la qualité du code en s'appuyant sur Sonar,
de gérer les artéfacts en utilisant Artifactory.

RUN@Cloud fournit, quant à lui, un ensemble d'outils permettant de simplifier le processus de déploiement d'une application Java dans le cloud. Il correspond, pour sa part, un service de type PaaS (Platform As A Service).

PS : vous aurez remarqué que, pour cette partie, je ne me suis pas trop foulé puisque je n'ai fait que reprendre les informations présentes sur le site... ;-)

C'est bien gentil tout ça et moi, ça m'apporte quoi?

Comme vous avez pu le constater, DEV@Cloud et RUN@Cloud fournissent tout pleins de services.

Cependant, la première question qui me vient à l'esprit quand je vois tout ça, c'est :

"ben, je fais pareil dans mon usine logicielle... : pourquoi je m'embêterai à payer une solution et surtout, pourquoi serais-je prêt à perdre la main sur mon infra mais aussi qu'on m'enlève l'occasion de m'amuser avec de nouveaux jouets..."

(pour le dernier argument, cela ne regarde que moi... ;-))

En fait, les réponses sont simples (et je ne parlerai pas des réponses évidentes de coûts -infra, supervision, maintenance, etc.-).

Déjà revenons sur les possibilités offertes par DEV@Cloud (je n'aborderai pas le fait que CloudBees propose également l'hébergement du SCM, du Repository Manager et de Sonar) :

En offrant la partie orchestrateur (via Jenkins), on délègue au cloud le soin de gérer les agents de build. Ainsi, il n'y a plus à administrer la ferme de serveurs succeptibles d'héberger les agents (tâche assez réberbative et ingrate).

De plus, en combinant la partie build/package à la partie RUN@Cloud permettant de déployer de manière continue l'application sur une instance dédiée, cela permet de tester fonctionnellement et de manière intégrer la solution. Encore une fois, en passant par un service de CloudBees, il n'y a plus à se soucier de devoir réserver un serveur ou de devoir déployer un conteneur de servlets puisque cela est fait pour nous.

Concernant les tests à proprement parler, CloudBees offre une intégration avec SauceLab qui se charge de l'exécution des tests Selenium (ie. qui prends à sa charge l'installation des agents Selenium ainsi que leurs configurations en mettant à disposition les browsers (butineurs ;-)) nécessaires à l'exécution des tests Selenium). En outre, SauceLab propose même la vidéo du test exécuté permettant, ainsi, a postériori d'analyser ce qui a échoué pendant le test. Bien sûr, DEV@Cloud n'offre pas encore la décorrélation entre le test fonctionnel exécuté et la partie vue mais, coté infrastructure, il n'y a plus à se soucier des agents et coté analyse, il n'est plus nécessaire d'analyser les rapports surefire pour connaitre le test en échec.

Il est également possible d'effectuer un test de charge en s'appuyant sur le plugin maven JMeter en ciblant l'instance déployée dans RUN@Cloud. L'intégration avec le service New Relic offre la possibilité de superviser l'activité de l'instance afin d'évaluer son comportement. En outre, en configurant RUN@Cloud de manière scalable, il est aisé de tester la charge supportée par de multiples instances (pour ce faire, CloudBees passe par un load balancer qui, si je ne me trompe pas, fonctionne, à ce jour, en round-robin). L'intégration du service New Relic permet de s'abstraire de la mise en place d'une solution comme Hyperic sur un environnement de recette, chose qui manque régulièrement et qui peut être consommateur en temps. En outre, New Relic permet même de déterminer les points de contension en offrant la possibilité d'activer un profiling à chaud dans l'application cible.

Concernant le comportement applicatif, l'intégration du service Papertrail offre la possibilité d'accéder aux logs de l'application mais permet également d'agréger les logs pour l'ensemble des instances et de les analyser. Ce dernier point est généralement manquant lors de la mise en place d'un environnement de test/validation/recette pour des questions d'infrastructure mais également de moyen. Aussi, disposer d'un tel service intégré avec l'offre RUN@Cloud dans un contexte de test (mais, bien sûr, pas uniquement) apporte un réel plus dans l'analyse des anomalies et du comportement de l'application.

Conclusion

Vous l'aurez compris (enfin, je l'espère), les offres DEV@Cloud et RUN@Cloud de CloudBees m'ont vraiment fait bonne impression. Je n'ai fait qu'effleurer les possibilités offertes et je suis sûrement passé à coté de beaucoup de features mais je tenais tout de même à partager mon ressenti sur ces offres.

C'est vrai que mon article est très orienté usine logicielle (peut être parce que c'est justement le point de départ de l'atelier) mais, au moins pour ce seul point, il mérite qu'on s'intéresse aux services offerts par CloudBees (et services, il y en a...).

Cependant, il reste un point qui me chagrine... en effet, CloudBees offre une excellente forge logicielle clé en main et qui semble parfaitement fonctionnelle mais, à mon sens, ce qui manque le plus est la bonne utilisation de ces outils et surtout, en amont, la bonne compréhension de ce qu'est une bonne usine logicielle et de son importance.

Bien sûr, si le client est réticent, il est toujours possible de faire une approche bottom/up en attaquant par la forge et en lui montrant le gain mais, je trouve cela dommage que l'on soit obligé d'en arriver là alors qu'il devrait en voir tout le bénéfice (un peu comme maitriser son livrable et son build ou le cycle de vie de son application...) surtout dans un contexte où l'agilité est un terme de plus en plus courant et qui prone des livraisons fréquentes, chose possible que si l'on dispose d'une bonne méthodologie, d'une bonne forge et que l'on a compris de l'intérêt des TUs, du refactoring et de la revue de code...

Enfin, je m'égare... ;-)
Pour revenir à nos moutons, ce que j'ai apprécié avec DEV@Cloud et RUN@Cloud est la grande intéraction et la modularisation des services avec Jenkins. Cependant, même si la solution offerte par CloudBees est de qualité et est simple à mettre en oeuvre en étant clé en main, il reste du ressort de l'équipe de mettre en place les bonnes pratiques pour construire l'usine logicielle sans lesquelles aussi bon que soient les outils et services à sa disposition, cela s'achèvera par un échec (enfin, là, il s'agit de mon humble avis... ;-)).

Pour finir, je tiens à préciser que je n'ai pas testé de manière plus approfondie les différents services offerts par CloudBees autre que ce qui nous a été présenté lors de l'atelier et j'espère ne pas avoir dénaturé le produit. Si des points étaient à ajouter, n'hésitez pas à m'en faire part afin de pouvoir compléter l'approche naïve que je pourrais en avoir ;-)

A noter aussi que concernant l'injection de charge, à ce jour, il n'existe pas de possibilité de scaler les injecteurs dans différents agents, ce qui limite l'intérêt de l'injection (je ne reviendrai pas sur le fait que si l'injecteur est saturé, cela fausse les résultats obtenus pour le SUT (System Under Test)) mais que cela devrait être résolu dans un futur proche.

PS : Je tenais aussi à préciser que je ne touche rien pour ce post mais que cela me faisait plaisir de parler d'un truc que j'ai apprécié (et puis je fais ce qui me chante avec mon blog... !! ;-) ) et puis aussi à remercier Stéphanie pour avoir consacré du temps à relire cet article et m'avoir apporté son esprit critique ;-)

FuseSource Community Day 2011

2011-10-20T00:53:00.000+02:00

Ce jeudi 13 octobre dernier a eu lieu la troisième édition du FuseSource Community Day à la Défense.

Pour ceux qui ne connaissent pas la société FuseSource, il s'agit, en fait, du nouveau nom de Iona et c'est une société spécialisée dans l'open source qui propose un ensemble de produits packagés et intégrés de différentes solutions de la fondation Apache.

Parmi ces produits, on peut y trouver :

Apache CXF (Fuse Service Framework)
Apache ServiceMix (Fuse ESB)
Apache ActiveMQ (Fuse Message Broker)
Apache Camel (Fuse Mediation Router)

En fait, si elle propose un package gratuit de ces différents produits, elle offre également un support ainsi que l'accompagnement aux personnes ou entreprises qui le souhaitent en offrant différentes formules.

Cet accompagnement est d'autant plus crédible que la société participe activement à ces framework puisqu'elle compte en son sein de nombreux commiteurs/créateurs de ces framework, ce qui permet de bénéficier d'une vrai expertise mais, aussi, d'être assurée que les corrections seront bien reversées à la communauté (ça c'est mon coté geek qui parle... ;-) ).

Pour revenir au FuseSource Community Day, il s'agit d'une journée de conférences allant de la présentation/démonstration des dernières features d'un produit aux annonces de Roadmap en passant par des retours clients.

Vous l'aurez compris, ayant eu l'opportunité d'y participer, je tenais à remercier grandement FuseSource pour cette excellente journée que j'ai passée en leur compagnie : c'était une journée passionnante où j'ai eu la chance de rencontrer quelques-uns des créateurs/commiteurs de ces produits et où j'ai pu assister à des présentations de qualité.

Coté programme, voilà ce que vous avez manqué :

Des "Enterprise Integration Patterns" (EIPS) vers la Production avec Apache Camel par Claus Ibsen et James Strachan
Présentation client et retour d’expérience : Atos Worldline
Présentation client et retour d’expérience : CapGemini pour le Ministère de l'Education Nationale
Intégration Open Source et messagerie avec FuseESB/Apache ServiceMix par Guillaume Nodet
Outil Fuse IDE et la stratégie Fuse Fabric par Charles Mouillard

Normalement des comptes-rendus de quelques-unes des sessions seront bientôt accessible sur le blog de So@t et je mettrai les liens dès qu'ils seront diffusés.

PS : Je tenais aussi à préciser que je ne touche rien pour ce post mais que cela me faisait plaisir de parler d'une société full open source ;-)

PS2 : Pour ceux qui me connaissent et qui savent que je n'aime pas Apache Camel (cf. ici), cela n'a pas changé mais je veux bien admettre qu'il faut parfois savoir replacer le métier en avant et pas juste faire ses choix en fonction de l'architecture intrinsèque d'un produit ou parce qu'on trouve qu'une API n'est pas assez sexy... ;-)

Par contre, j'ai trouvé bluffante la présentation sur Fuse Fabric et je vous invite vraiment à aller y jeter un oeil...

Nouveaux thèmes Blogger

2011-09-28T23:51:00.000+02:00

Pour une fois, ce post n'a pas pour objectif de parler d'une technologie ou d'un évènement en particulier, mais juste d'introduire une nouvelle fonctionnalité de la plateforme de blog Blogger.

En effet, il vient d'être offert aux utilisateurs de cette plateforme, la possibilité d'appliquer un thème dit "dynamique". En fait, il existe 7 thèmes différents qui ont la particularité d'être assez sobres.

Pour plus d'informations, je vous renvoie vers le blog officiel de Google France.

En attendant que des utilisateurs en appliquent un, il est possible de prévisualiser tous les blogs sous Blogger avec ces derniers afin de se faire une idée du rendu de vos sites préférés ;-)

Si on prends l'exemple du mien, vous pouvez vous faire une idée du rendu en allant sur l'url suivante (attention, il semble que cela ne fonctionne pas sous chrome - en tout cas la version sous linux - ) :
http://jetoile.blogspot.com/view/sidebar

Du coup, j'en profite pour faire un petit sondage... :

Préférez-vous que mon blog reste avec le thème actuel ou que je lui donne un petit coup de jeune (et dans ce cas, certaines parties risques d'être dégradées).

Je vous laisse y répondre via les commentaires.

S'il n'y a pas de réponses - ce qui est fort probable... - , je ferai selon mes humeurs ;-)

Jetty, Maven et JMX

2011-09-26T19:49:00.000+02:00

Vous avez peut être remarqué que ces derniers temps, j'étais très Maven et JMX. Cet article ne déroge pas à la règle puisque je vais parler de... Maven et de JMX.

Enfin pour être plus précis, je vais montrer comment il est facilement possible de déployer une application web dans le conteneur embarqué Jetty via Maven en activant la couche JMX afin de pouvoir tester de manière intégrée cette couche.

Pour ce faire, je présenterai dans un premier temps le contexte, puis comment cela peut être mise en œuvre.

Bien sûr, cet article montre comment j'ai fait mais il ne représente pas la seule manière de faire... ;-). En outre, il ne présente rien de novateur mais je me suis dit que cela pouvait toujours être utile afin d'éviter de faire perdre du temps à d'autres personnes.

Contexte

Ce paragraphe présente mes motivations pour avoir eu un besoin d'une utilisation d'un Jetty embedded à Maven en activant la couche JMX car, c'est vrai, ce n'est pas un besoin très courant et qu'il peut même sembler, au premier abord, paraitre un peu stupide (en effet, utiliser un Jetty embedded répond plutôt à un besoin de poste de développement ou au pire (et je dis bien au pire!!) à un pseudo TU qui n'est, du coup, pas un TU... (ndlr : enfin, encore une fois, je diverge... ;-) )).

En fait, pour les besoins d'une démonstration, je voulais juste présenter une petite application web qui remontait des métriques via JMX. N'ayant pas foncièrement envie d'avoir à décompresser un Jetty sur mon poste, je me suis dit qu'un Jetty embedded dans Maven suffisait largement à ma petite démo.

En outre, cela offrait également la possibilité à n'importe qui de rejouer la démo sans avoir à installer localement un conteneur de Servlets et sans à avoir à modifier le paramétrage de ce dernier pour activer la couche JMX de la JVM.

L'application web utilisée pour ce petit POC est assez basique puisqu'il ne s'agit que d'un simple Servlet redirigeant vers une simple jsp.

Ce Servlet incrémentera un compteur exposé en JMX afin de fournir cette métrique basique à la couche de supervision.

Spring 3 sera également utilisé pour lier le tout...

En fait, si vous me demandez pourquoi j'ai branché Spring pour une application ausi simple, c'est, en fait, que JMX n'était pas le seul composant que je voulais montrer pendant la petite démonstration...

Si vous avez l'esprit chagrin et que vous me re-demandez pourquoi je n'ai pas utilisé un aspect, c'est que l'aspect était justement l'autre aspect de ma démo ;-).

Mise en œuvre

Pour ce paragraphe de mise en œuvre, je présenterai successivement :

Le code de l'application web utilisé.
La configuration Maven utilisée permettant de démarrer l'application web dans un Jetty embedded.
Les subtilités de la configuration à effectuer pour ajouter la couche JMX.

Application web cible

Comme annoncé précédemment, notre application web cible se compose de :

un Servlet,
une page JSP,
un POJO utilisé par Spring pour la partie MBean (Spring aura, à sa charge, sa proxification en MBean Standard et son enregistrement au sein du MBean Server),
un fichier de configuration web.xml,
et un fichier de contexte Spring.

Il est à noter qu'elle utilisera la spécification 2.5 des Servlets afin de permettre, dans les parties suivantes, de montrer la différence de configuration qu'il existe entre Jetty 6 et 7.

Code du Servlet

public class SimpleServlet extends HttpServlet {
    private static Logger LOGGER = LoggerFactory.getLogger(SimpleServlet.class);

    @Override
    protected void service(HttpServletRequest req, HttpServletResponse resp) throws ServletException, IOException {
        ApplicationContext beanFactory = WebApplicationContextUtils.getRequiredWebApplicationContext(getServletContext());
        SimpleCounter jmxTestBean = beanFactory.getBean("simpleCounter", SimpleCounter.class);
        jmxTestBean.inc();

        req.setAttribute("nbInvocation", jmxTestBean.getNbGet());

        RequestDispatcher dispatcher = req.getRequestDispatcher("WEB-INF/jsp/simpleDisplay.jsp");
        if (dispatcher != null) {
            dispatcher.forward(req, resp);
        } else {
            LOGGER.warn("unable to get the request dispatcher");
        }
    }
}

On constate que le Servlet est basique. Il n'y a donc rien à dire dessus si ce n'est la récupération du POJO proxifié par Spring pour incrémenter un compteur qui sera exposé en JMX.

Code du POJO utilisé comme MBean Standard

public class SimpleCounter {
    private int nbGet = 0;

    public void inc() {
        this.nbGet++;
    }

    public void setNbGet(int nbGet) {
        this.nbGet = nbGet;
    }

    public int getNbGet() {
        return nbGet;
    }
}

Concernant le POJO, rien de spécial non plus à remarquer. Juste à noter que les setter et getter sont nécessaires afin de rendre l'attribut nbGet accessible en lecture/écriture par la couche cliente JMX.

Code de la jsp

<%@ page language="java" contentType="text/html; charset=UTF-8" pageEncoding="UTF-8"%>
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<html>
    <head>
        <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
        <title>simple display</title>
    </head>
    <body>
        <h1>This is a simple display</h1>
        Has been invoked: ${nbInvocation} times
    </body>
</html>

Rien de particulier non plus à dire sur la jsp...

Code du web.xml

<web-app version="2.5" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://java.sun.com/xml/ns/javaee" xsi:schemalocation="http://java.sun.com/xml/ns/javaee 
	http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd">
	<context-param>
		<param-name>contextConfigLocation</param-name>
		<param-value>classpath:applicationContext*.xml</param-value>
	</context-param>
	<listener>
		<listener-class>org.springframework.web.context.ContextLoaderListener</listener-class>
	</listener>

	<servlet>
		<servlet-name>SimpleServlet</servlet-name>
		<servlet-class>fr.jetoile.demo.servlet.SimpleServlet</servlet-class>
		<init-param>
			<param-name>sleep-time-in-seconds</param-name>
			<param-value>10</param-value>
		</init-param>
		<load-on-startup>1</load-on-startup>
	</servlet>

	<servlet-mapping>
		<servlet-name>SimpleServlet</servlet-name>
		<url-pattern>/sample</url-pattern>
	</servlet-mapping>
</web-app>

Le fichier descripteur web.xml est classique donc rien de nouveau sur les tropiques ;-). Comme dit plus haut, c'est ici la version 2.5 des servlets qui est utilisée afin de permettre un choix plus important de conteneurs de Servlets.

Code du contexte Spring

<beans xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://www.springframework.org/schema/beans" xsi:schemalocation="http://www.springframework.org/schema/beans
	http://www.springframework.org/schema/beans/spring-beans-3.0.xsd">
	<bean class="org.springframework.jmx.support.MBeanServerFactoryBean" id="mbeanServer">
		<property name="locateExistingServerIfPossible" value="true"></property>
	</bean>

	<bean class="org.springframework.jmx.export.MBeanExporter" id="exporter">
		<property name="beans">
			<map>
				<entry key="bean:application=jmx-sample,name=simpleCounter" value-ref="simpleCounter"></entry>
			</map>
		</property>
 		<property name="server" ref="mbeanServer"></property>
	</bean>

	<bean class="fr.jetoile.demo.jmx.SimpleCounter" id="simpleCounter"></bean>
</beans>

Concernant le fichier descripteur de Spring, on constate que la classe MBeanServerFactoryBean de Spring est utilisée comme moyen de récupération/création du MBeanServer et que c'est le MBeanExporter qui a la charge de l'enregistrement du MBean injecté.

Application web exécutable via Jetty au sein de Maven

Afin de permettre une exécution de notre application web dans un Jetty embedded dans Maven, il faut, bien sûr, une structure Maven.

Elle est la suivante :

Concernant le fichier descripteur pom.xml, il contiendra, bien sûr, le plugin nécessaire au lancement de jetty.

Afin d'être plus exhaustif, dans notre POC, deux profils Maven seront utilisés afin de pouvoir spécifier la version de Jetty à utiliser (le choix sera laissé entre Jetty 6 et 7). En outre, le port d'écoute est forcé à 9090 :

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
	xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
	<modelVersion>4.0.0</modelVersion>
	<groupId>fr.jetoile.demo</groupId>
	<artifactId>jmx-sample</artifactId>
	<packaging>war</packaging>
	<version>1.0-SNAPSHOT</version>

	<properties>
		<java.version>1.5</java.version>
		<project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>

		<slf4j.version>1.6.1</slf4j.version>
		<logback.version>0.9.27</logback.version>
		<commons-lang.version>2.5</commons-lang.version>
		<spring.version>3.0.6.RELEASE</spring.version>
		<servlet.version>2.5</servlet.version>
	</properties>

	<dependencies>
		<dependency>
			<groupId>ch.qos.logback</groupId>
			<artifactId>logback-classic</artifactId>
			<version>${logback.version}</version>
		</dependency>
		<dependency>
			<groupId>org.slf4j</groupId>
			<artifactId>slf4j-api</artifactId>
			<version>${slf4j.version}</version>
		</dependency>
		<dependency>
			<groupId>commons-lang</groupId>
			<artifactId>commons-lang</artifactId>
			<version>${commons-lang.version}</version>
		</dependency>
		<dependency>
			<groupId>org.springframework</groupId>
			<artifactId>spring-context</artifactId>
			<version>${spring.version}</version>
		</dependency>
		<dependency>
			<groupId>org.springframework</groupId>
			<artifactId>spring-web</artifactId>
			<version>${spring.version}</version>
		</dependency>
		<dependency>
			<groupId>javax.servlet</groupId>
			<artifactId>servlet-api</artifactId>
			<version>${servlet.version}</version>
			<scope>provided</scope>
		</dependency>
	</dependencies>

	<build>
		<plugins>

			<plugin>
				<artifactId>maven-deploy-plugin</artifactId>
				<version>2.6</version>
			</plugin>

			<plugin>
				<artifactId>maven-release-plugin</artifactId>
				<version>2.1</version>
			</plugin>

			<plugin>
				<artifactId>maven-compiler-plugin</artifactId>
				<version>2.3.2</version>
				<configuration>
					<source>${java.version}</source>
					<target>${java.version}</target>
					<encoding>UTF-8</encoding>
				</configuration>
			</plugin>

			<plugin>
				<artifactId>maven-resources-plugin</artifactId>
				<version>2.4.3</version>
				<configuration>
					<encoding>UTF-8</encoding>
				</configuration>
			</plugin>
		</plugins>
	</build>
	
	
	<profiles>
		<profile>
			<id>jetty6</id>
			<properties>
				<jetty.version>6.1.26</jetty.version>
			</properties>
			<build>
				<plugins>
					<plugin>
						<groupId>org.mortbay.jetty</groupId>
						<artifactId>maven-jetty-plugin</artifactId>
						<version>${jetty.version}</version>
						<configuration>
							<scanIntervalSeconds>10</scanIntervalSeconds>
							<webAppConfig>
								<contextPath>/jmx-sample</contextPath>
							</webAppConfig>
							<connectors>
							  <connector implementation="org.mortbay.jetty.nio.SelectChannelConnector">
									<port>9090</port>
									<host>0.0.0.0</host>
									<maxIdleTime>60000</maxIdleTime>
								</connector>
							</connectors>		
						</configuration>
					</plugin>
				</plugins>
			</build>
		</profile>
		<profile>
			<id>jetty7</id>
			<properties>
				<jetty.version>7.4.5.v20110725</jetty.version>
			</properties>
			<build>
				<plugins>
					<plugin>
						<groupId>org.mortbay.jetty</groupId>
						<artifactId>jetty-maven-plugin</artifactId>
						<version>${jetty.version}</version>
						<configuration>
							<scanIntervalSeconds>10</scanIntervalSeconds>
							<webAppConfig>
								<contextPath>/jmx-sample</contextPath>
							</webAppConfig>
							<connectors>
							    <connector implementation="org.eclipse.jetty.server.nio.SelectChannelConnector">
									<port>9090</port>
									<host>0.0.0.0</host>
									<maxIdleTime>60000</maxIdleTime>
								</connector>
							</connectors>		
						</configuration>
					</plugin>
				</plugins>
			</build>
		</profile>
	</profiles>
</project>

Il n'y a rien de particulier à remarquer si ce n'est une version de plugin maven pour Jetty qui diffère, ainsi qu'un changement de package pour le SelectChannelConnector utilisé pour spécifier le port d'écoute.

Pour démarrer notre Jetty, il ne reste plus qu'à exécuter, au choix, la commande :

mvn -Pjetty6 jetty:run

ou :

mvn -Pjetty7 jetty:run

Activation de JMX

Après avoir montré l'application web ainsi que la configuration du plugin Maven de Jetty nécessaire à son exécution dans le conteneur embarqué, il est possible de démarrer l'application web dans le Jetty embedded.

Cependant, même si nos JConsole ou VisualVM préférés proposent une connexion au MBean Server local (visible au travers notre processus Maven3 org.codehaus.plexus.classworlds.launcher.Launcher), il n'est pas possible d'effectuer une connexion en spécifiant le JMXServiceURL de type : service:jmx:rmi:///jndi/rmi://localhost:1099/jmxrmi .

En effet, par défaut, Jetty ne créé pas de MBeanServer et, à fortiori, n'enregistre aucun connecteur RMI nécessaire à une application JMX cliente.

A titre informatif, même en démarrant un serveur Jetty en mode standalone, il est nécessaire de préciser, à son démarrage, le fichier de configuration jetty-jmx.xml se trouvant, par défaut, dans son répertoire etc et qu'il faut éditer (pour préciser le port du serveur RMI à démarrer et le JMXServiceURL du connecteur JMX RMI).

Pour Jetty 7, cela peut être fait, soit en modifiant le fichier start.ini, soit en démarrant Jetty en ligne de commande :

java -jar start.jar etc/jetty-jmx.xml etc/jetty.xml

Pour Jetty 6, cela peut être fait, soit en modifiant le fichier bin/jetty-service.conf, soit en démarrant Jetty en ligne de commande :

java -DOPTIONS=jmx -jar start.jar etc/jetty-jmx.xml etc/jetty.xml

Aussi, pour activer la création d'un serveur RMI et créer un MBean Server dans le Jetty embarqué par Maven, il est nécessaire de fournir au plugin le fichier jetty-jmx.xml.

Pour ce faire, il est possible de spécifier une configuration à Jetty via l'élément : <jettyConfig>

	<profiles>
		<profile>
			<id>jetty6</id>
			<properties>
				<jetty.version>6.1.26</jetty.version>
			</properties>
			<build>
				<plugins>
					<plugin>
						<groupId>org.mortbay.jetty</groupId>
						<artifactId>maven-jetty-plugin</artifactId>
						<version>${jetty.version}</version>
						<configuration>
							<scanIntervalSeconds>10</scanIntervalSeconds>
							<jettyConfig>${basedir}/src/config/jetty-jmx-6.xml</jettyConfig>
							<webAppConfig>
								<contextPath>/jmx-sample</contextPath>
							</webAppConfig>
							<connectors>
							  <connector implementation="org.mortbay.jetty.nio.SelectChannelConnector">
									<port>9090</port>
									<host>0.0.0.0</host>
									<maxIdleTime>60000</maxIdleTime>
								</connector>
							</connectors>
						</configuration>
					</plugin>
				</plugins>
			</build>
		</profile>
		<profile>
			<id>jetty7</id>
			<properties>
				<jetty.version>7.4.5.v20110725</jetty.version>
			</properties>
			<build>
				<plugins>
					<plugin>
						<groupId>org.mortbay.jetty</groupId>
						<artifactId>jetty-maven-plugin</artifactId>
						<version>${jetty.version}</version>
						<configuration>
							<scanIntervalSeconds>10</scanIntervalSeconds>
							<jettyConfig>${basedir}/src/config/jetty-jmx.xml</jettyConfig>
							<webAppConfig>
								<contextPath>/jmx-sample</contextPath>
							</webAppConfig>
							<connectors>
							    <connector implementation="org.eclipse.jetty.server.nio.SelectChannelConnector">
									<port>9090</port>
									<host>0.0.0.0</host>
									<maxIdleTime>60000</maxIdleTime>
								</connector>
							</connectors>		
						</configuration>
					</plugin>
				</plugins>
			</build>
		</profile>
	</profiles>

La nouvelle arborescence de notre projet devient donc :

En outre, il est nécessaire de démarrer la JVM avec l'option -Dcom.sun.management.jmxremote :

mvn -Dcom.sun.management.jmxremote -Pjetty6 package jetty:run

mvn -Dcom.sun.management.jmxremote -Pjetty7 package jetty:run

Suite au lancement du serveur Jetty via Maven, il est alors possible d'y accéder au travers d'un client JMX en mode distant :

A titre informatif, ci-joint les fichiers de configuration de Jetty permettant la création d'un serveur RMI, du MBean Server et du connecteur RMI ainsi que de sa configuration.

Pour Jetty 6 :

<?xml version="1.0"?>
<!DOCTYPE Configure PUBLIC "-//Mort Bay Consulting//DTD Configure//EN" "http://jetty.mortbay.org/configure.dtd">

<Configure id="Server" class="org.mortbay.jetty.Server">
    <Call id="MBeanServer" class="java.lang.management.ManagementFactory" name="getPlatformMBeanServer"/>

    <Get id="Container" name="container">
      <Call name="addEventListener">
        <Arg>
          <New class="org.mortbay.management.MBeanContainer">
            <Arg><Ref id="MBeanServer"/></Arg>
            <Call name="start" />
          </New>
        </Arg>
      </Call>
    </Get>

    <Call id="rmiRegistry" class="java.rmi.registry.LocateRegistry" name="createRegistry">
      <Arg type="int">1099</Arg>
    </Call>
    
    <Call id="jmxConnectorServer" class="javax.management.remote.JMXConnectorServerFactory" name="newJMXConnectorServer">
      <Arg>
        <New  class="javax.management.remote.JMXServiceURL">
          <Arg>service:jmx:rmi://localhost:1099/jndi/rmi://localhost:1099/jmxrmi</Arg>
        </New>
      </Arg>
      <Arg/>
      <Arg><Ref id="MBeanServer"/></Arg>
      <Call name="start"/>
    </Call>
</Configure>

Pour Jetty 7 :

<?xml version="1.0"?>
<!DOCTYPE Configure PUBLIC "-//Jetty//Configure//EN" "http://www.eclipse.org/jetty/configure.dtd">
<Configure id="Server" class="org.eclipse.jetty.server.Server">

  <Call id="MBeanServer" class="java.lang.management.ManagementFactory"
    name="getPlatformMBeanServer" />

  <New id="MBeanContainer" class="org.eclipse.jetty.jmx.MBeanContainer">
    <Arg>
      <Ref id="MBeanServer" />
    </Arg>
  </New>

  <Get id="Container" name="container">
    <Call name="addEventListener">
      <Arg>
        <Ref id="MBeanContainer" />
      </Arg>
    </Call>
  </Get>

  <Call name="addBean">
    <Arg>
      <Ref id="MBeanContainer" />
    </Arg>
  </Call>

  <Get id="Logger" class="org.eclipse.jetty.util.log.Log" name="log" />
  <Ref id="MBeanContainer">
    <Call name="addBean">
      <Arg>
        <Ref id="Logger" />
      </Arg>
    </Call>
  </Ref>
  
  <Call name="createRegistry" class="java.rmi.registry.LocateRegistry">
    <Arg type="java.lang.Integer">1099</Arg>
    <Call name="sleep" class="java.lang.Thread">
       <Arg type="java.lang.Integer">1000</Arg>
    </Call>
  </Call>
 
 <New id="ConnectorServer" class="org.eclipse.jetty.jmx.ConnectorServer">
    <Arg>
      <New class="javax.management.remote.JMXServiceURL">
        <Arg type="java.lang.String">rmi</Arg>
        <Arg type="java.lang.String" />
        <Arg type="java.lang.Integer">0</Arg>
        <Arg type="java.lang.String">/jndi/rmi://localhost:1099/jmxrmi</Arg>
      </New>
    </Arg>
    <Arg>org.eclipse.jetty:name=rmiconnectorserver</Arg>
    <Call name="start" />
  </New>
</Configure>

Conclusion

Cet article avait pour objectif de montrer comment il pouvait être facile d'activer la couche JMX pour un serveur Jetty embedded dans Maven.

C'est vrai que démarrer un Jetty embarqué n'a pas pour objectif de faire des tests d'intégration mais cela peut toujours être utile dans le cas d'un POC ou d'une démonstration (qui était d'ailleurs l'objectif de ce petit cas d'usage. ;-) ).

Présentation sur les problématiques liées à une architecture distribuée

2011-09-23T20:40:00.001+02:00

Ci-dessous se trouve une présentation que j'ai donné dans le cadre de So@t sur les problématiques liées aux architectures distribuées. Pour information, c'est un retour d'expérience d'une mission qui date un peu puisque c'était en 2007 mais les préconisations restent identiques à ce jour.

Enjoy et n'hésitez pas à commenter ;-)

Introduction sur les problématiques d'une architecture distribuée

View more presentations from jetoile

Présentation sur un retour d'expérience pour la mise en oeuvre de Maven 2

2011-09-23T20:39:00.001+02:00

Ci-dessous se trouve une présentation que j'ai donné dans le cadre de So@t sur un retour d'expérience sur Maven 2.

Enjoy et n'hésitez pas à commenter ;-)

Présentation sur Maven 2 et petit retour d'expérience

View more presentations from jetoile

JugSummerCamp 2011 : C'est fini...

2011-09-18T17:45:00.000+02:00

Voilà, pour ceux qui l'auraient manquée ou qui ne le savaient pas (ouh!!!), le JugSummerCamp a fermé ses portes ce vendredi 16 septembre 2011.

Ce fut une journée bien remplie, fatigante mais que du bonheur : des sessions intéressantes, des speakers compétents mais également une super organisation (merci au Poitou-Charente Java User Group mais également à tous les sponsors de l'évènement sans qui rien n'aurait été possible... (on les oublie tout le temps... ;-) ))!

C'est toujours un plaisir de rencontrer/retrouver des personnes géniales (je ne citerai pas de noms, ça fait trop lèche... ;-) ).

Donc, en gros, vous l'aurez compris, au vu de mon enthousiasme, merci encore et vivement l'année prochaine!!

Bon, et pour les néophytes, je vais tenter de vous présenter succinctement ce que vous avez loupé (pour des CRs, je vous invite à aller voir d'autres sites comme celui de So@t, de Nicolas Martignole et de Claude Falguière).

Le JugSummerCamp est donc une journée entière de conférences se déroulant à La Rochelle plutôt orientées Java.

Pour donner un ordre d'idée, ci-dessous le planning de la journée (pour les résumés des présentations, c'est ici) :

Voilà, plus grand chose à ajouter, les présentations parlent d'elles-mêmes... ;-)

Sur ce, à l'année prochaine alors! ;-)
[edit]
Ci-dessous ma modeste contribution :

Retour sur le BreizhCamp 2011

2011-07-29T18:26:00.000+02:00

Cela fait un petit moment (plus d'un mois déjà...) qu'a eu lieu le BreizhCamp.

Pour les néophytes, BreizhCamp est une journée de conférence sur diverses technologies allant de Python, en passant par .Net pour, finalement finir sur Java.

Cette année, elle a eu lieu le vendredi 17 Juin à Rennes dans les locaux de l’ISTIC et a été organisée par l’équipe du BreizhJug qui comprend :

Nicolas De loof,
Michel David,
Julien Coste.

Ayant eu l'opportunité d'y participer, j'ai rédigé quelques petits compte-rendu de quelques-une des présentations auxquelles j'ai eu la chance d'assister. Les liens se trouvent ci-dessous :

Applications mobiles avec GWT 2.0 par Salvador Diaz
Déploiement Continu en production par Claude Falguière
Behaviour Driven Development par Olivier Billard et Thierry Henrio
La vie dans du code legacy par Emmanuel Hugonnet

Le programme complet est ici.

En tout cas, encore un grand merci aux organisateurs ainsi qu’aux speakers et vivement la prochaine édition (en espérant que, la prochaine fois, la Bretagne daigne nous offrir un peu de soleil sans passage pluvieux ;-) )!

Ubuntu 11.04, problème de complétion?

2011-06-11T17:53:00.000+02:00

Ubuntu 11.04 est sorti depuis le 28 avril 2011. Je ne reviendrai pas ni sur son ergonomie ni sur ses ajouts puisque cela a déjà été débattu sur de nombreux sites/blogs. Cependant, depuis la mise à jour, un point avait tendance à m'agacer.

En effet, dans un shell bash, sur la complétion de la commande ls (entre autre) avec des répertoires contenant des espaces, il ne m'échappait plus ces derniers. Du coup, obligation d'aller les échapper manuellement mais chose encore plus embêtante était qu'il ne me proposait plus le contenu de mon répertoire.

Pire, en échappant les espaces et en utilisant la complétion, il me supprimait mon échappement...

Cet article fournira donc une rapide solution pour corriger ce problème.

Symptôme
Pour l'arborescence ci-dessous, j'avais le comportement suivant :

Utilisation basique de la complétion :

Avec échappement de l'espace...
Avant :

Après exécution de la commande Tab :

Entraînant, bien sûr, une erreur lors de son exécution :

Correctif

Du coup, après une ou deux recherche sur mon ami google, je suis tombé sur le bug suivant.

En fait, pour résumer, il semble que cela vienne du script de complétion utilisé par bash.

Aussi pour corriger ce problème, il ne vous reste plus qu'à éditer le fichier /etc/bash_completion avec les bons droits et à modifier sa ligne 1587 pour y remplacer "default" par "filenames".

# makeinfo and texi2dvi are defined elsewhere.
for i in a2ps awk bash bc bison cat colordiff cp csplit \
    curl cut date df diff dir du enscript env expand fmt fold gperf gprof \
    grep grub head indent irb ld ldd less ln ls m4 md5sum mkdir mkfifo mknod \
    mv netstat nl nm objcopy objdump od paste patch pr ptx readelf rm rmdir \
    sed seq sha{,1,224,256,384,512}sum shar sort split strip tac tail tee \
    texindex touch tr uname unexpand uniq units vdir wc wget who; do
    have $i && complete -F _longopt -o filenames $i
done
unset i

Après un petit coup de rechargement du bashrc (qui charge le bash_completion), vous aurez alors résolu votre problème ;-)

Rechargement du ~/.bashrc :

Utilisation basique de la complétion et exécution :

Utilisation de la complétion après complétion du répertoire :

Voilà pour cet article qui, pour une fois, ne parle pas Java mais qui, je l'espère, pourra être utile... ;-)

Maven pour les nuls... les archetypes

2011-06-05T22:45:00.025+02:00

Dans le cadre d'une problématique d'une usine logiciel, il peut s'avérer utile de posséder un patron ou template de projet qui fournit les "bonnes" pratiques que doivent respecter l'ensemble des applications du projet.

Bien sûr, notre cher IDE est capable de générer un joli patron de projet. Cependant, il reste toujours nécessaire de modifier la configuration du projet pour y mettre, par exemple :

la version de jdk,
les libs utilisées (comme mockito par exemple),
optionnellement, la configuration de plugins,
optionnellemet, l'url du SCM,
ou tout simplement, la référence à un projet parent qui permet de définir, par exemple, la version des librairies ou des plugins utilisés.

Le hic, c'est que, généralement, cela fini par de jolis copier/coller dont le résultat diffère, bien sûr, en fonction du projet qui a servi de template. Le résultat : le syndrome du téléphone arabe sachant qu'en plus, on n'est même plus capable de savoir qu'elle était la référence du départ... embêtant tout ça... surtout pour un projet se voulant industriel...

En outre, posséder un patron de projet peut également s'avérer utile si vous êtes amené à POCer des frameworks ou faire des projets perso chez vous...

Vous l'aurez compris, cet article se focalisera sur les projets construits sur maven où les notions de dépendances, de plugins, d'informations projet sont présentes dans le pom.

Cet article a donc pour objectif de montrer comment il est possible de créer un archetype maven qui permet de répondre à ce problème.

Le use case sera simple puisque je m'appuierai sur la création d'un archetype simple pour mes besoins personnels afin de me fournir un patron normalisé (selon mes normes) me permettant de démarrer un POC rapidement pour un artifact de type jar et cela dans le seul but de ne pas avoir à faire moultes copier/coller... ;-)

A noter qu'il n'y a rien de révolutionnaire dans cet article pour toutes les personnes qui ont quelques connaissances de base en maven mais qu'il peut s'avérer utile (enfin j'espère) pour les autres... ;-)

Méthodologie

Afin de créer un archetype, il existe plusieurs méthodes :

la première consiste à créer l'archetype directement, chose pas trop complexe mais qui demande d'être rodée à la chose,
la deuxième consiste à créer le projet maven tel que l'on souhaiterait que l'archetype nous le créer et de demander à maven de nous générer l'archetype en lui-même. Suite à cela, il convient de modifier l'archetype généré afin de le rendre configurable (nom des packages, ...).

Suite à cela, il convient d'installer (ou de déployer) notre archetype au sein de notre repository (global ou distant) afin de le rendre accessible aux autres membres de l'équipe ou tout simplement à soi-même.

Dans mon cas, j'utiliserai la deuxième méthode qui consiste donc à générer l'archetype à partir du projet maven que je souhaite avoir.

Création du projet de base

Comme je l'ai dit précédemment, mes besoins sont purement personnels et mon projet devra répondre aux points suivants :

un seul projet,
de type jar,
utilisant un jdk 6,
déclarant les librairies suivantes : slf4j, logback-classic, commons-lang
déclarant les librairies suivantes pour mes TUs : JUnit, mockito, powermock
déclarant et configurant le plugin checkstyle et dont les rules seront dans le projet en lui-même
déclarant et configurant le plugin assembly afin de me permettre de fournir, au besoin, un livrable
déclarant le plugin source afin de me permettre de générer un jar de source

Bien sûr, il tentera de suivre au mieux les bonnes pratiques maven...

Cette partie n'étant pas bien intéressante et étant spécifique aux besoins de chacun, je la détaillerai donc peu...

Sa structure :

Son pom :

<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
 xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
 <modelVersion>4.0.0</modelVersion>
 <groupId>fr.jetoile</groupId>
 <artifactId>project-template</artifactId>
 <version>0.0.1-SNAPSHOT</version>

 <properties>
  <java.version>1.6</java.version>

  <junit.version>4.8.1</junit.version>
  <slf4j.version>1.6.1</slf4j.version>
  <logback.version>0.9.27</logback.version>
  <commons-lang.version>2.5</commons-lang.version>
  <powermock.version>1.4.7</powermock.version>
  <mockito.version>1.8.5</mockito.version>
 </properties>

 <!-- distributionManagement>
  <repository>
   <id>nexus</id>
   <url>http://localhost:8080/nexus/content/repositories/releases</url>
  </repository>
  <snapshotRepository>
   <id>nexus</id>
   <name>Nexus snapshot Repository</name>
   <url>http://localhost:8080/nexus/content/repositories/snapshots</url>
  </snapshotRepository>
 </distributionManagement>
 <scm>
  <developerConnection>scm:svn:svn://localhost/projet/trunk/TODO</developerConnection>
 </scm-->


 <developers>
  <developer>
   <email>kmx.petals@gmail.com</email>
   <id>khanh</id>
   <roles>
    <role>developer</role>
   </roles>
  </developer>
 </developers>

 <dependencies>
  <dependency>
   <groupId>ch.qos.logback</groupId>
   <artifactId>logback-classic</artifactId>
   <version>${logback.version}</version>
  </dependency>
  <dependency>
   <groupId>org.slf4j</groupId>
   <artifactId>slf4j-api</artifactId>
   <version>${slf4j.version}</version>
  </dependency>
  <dependency>
   <groupId>commons-lang</groupId>
   <artifactId>commons-lang</artifactId>
   <version>${commons-lang.version}</version>
  </dependency>
  <dependency>
   <groupId>org.mockito</groupId>
   <artifactId>mockito-all</artifactId>
   <version>${mockito.version}</version>
   <scope>test</scope>
  </dependency>
  <dependency>
   <groupId>org.powermock</groupId>
   <artifactId>powermock-module-junit4</artifactId>
   <version>${powermock.version}</version>
   <scope>test</scope>
  </dependency>
  <dependency>
   <groupId>junit</groupId>
   <artifactId>junit</artifactId>
   <version>${junit.version}</version>
   <scope>test</scope>
  </dependency>
  <dependency>
   <groupId>org.powermock</groupId>
   <artifactId>powermock-api-mockito</artifactId>
   <version>${powermock.version}</version>
   <scope>test</scope>
  </dependency>
 </dependencies>


 <build>
  <plugins>
   <plugin>
    <artifactId>maven-deploy-plugin</artifactId>
    <version>2.6</version>
   </plugin>

   <plugin>
    <artifactId>maven-release-plugin</artifactId>
    <version>2.1</version>
   </plugin>

   <plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-compiler-plugin</artifactId>
    <version>2.3.2</version>
    <configuration>
     <source>${java.version}</source>
     <target>${java.version}</target>
    </configuration>
   </plugin>

   <plugin>
    <artifactId>maven-checkstyle-plugin</artifactId>
    <version>2.6</version>
    <configuration>
     <configLocation>src/config/custom-checkstyle.xml</configLocation>
     <includeTestSourceDirectory>false</includeTestSourceDirectory>
     <logViolationsToConsole>true</logViolationsToConsole>
    </configuration>
    <executions>
     <execution>
      <phase>compile</phase>
      <goals>
       <goal>check</goal>
      </goals>
     </execution>
    </executions>
   </plugin>

   <plugin>
    <artifactId>maven-assembly-plugin</artifactId>
    <version>2.2.1</version>
    <configuration>
     <descriptors>
      <descriptor>src/assembly/src.xml</descriptor>
     </descriptors>
    </configuration>
    <executions>
     <execution>
      <id>make-assembly</id>
      <phase>install</phase>
      <goals>
       <goal>single</goal>
      </goals>
     </execution>
    </executions>
   </plugin>

   <plugin>
    <artifactId>maven-source-plugin</artifactId>
    <version>2.1.2</version>
    <executions>
     <execution>
      <phase>package</phase>
      <goals>
       <goal>jar</goal>
      </goals>
     </execution>
    </executions>
   </plugin>
  </plugins>
 </build>
</project>

Son fichier assembly :


<assembly>
 <id>bin</id>
 <formats>
  <format>zip</format>
 </formats>
 <includeBaseDirectory>false</includeBaseDirectory>
 <dependencySets>
  <dependencySet>
   <scope>compile</scope>
   <useProjectArtifact>true</useProjectArtifact>
   <useTransitiveDependencies>true</useTransitiveDependencies>
   <outputDirectory>lib</outputDirectory>
  </dependencySet>
 </dependencySets>

 <fileSets>
  <fileSet>
   <directory>target/</directory>
   <outputDirectory>sources</outputDirectory>
   <includes>
    <include>**sources.jar</include>
   </includes>
  </fileSet>
  <fileSet>
   <directory>bin/</directory>
   <outputDirectory>bin</outputDirectory>
  </fileSet>
 </fileSets>

</assembly>

Création de l'archetype

La création de l'archetype est simple puisqu'il suffit de lancer la commande suivante :

mvn archetype:create-from-project

Suite à cela, notre archetype se trouve dans le répertoire target/generated-sources/archetype et a la structure suivante :

Son pom :


<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
  <modelVersion>4.0.0</modelVersion>

  <groupId>fr.jetoile</groupId>
  <artifactId>project-template-archetype</artifactId>
  <version>0.0.1-SNAPSHOT</version>
  <packaging>maven-archetype</packaging>

  <name>project-template-archetype</name>

  <build>
    <extensions>
      <extension>
        <groupId>org.apache.maven.archetype</groupId>
        <artifactId>archetype-packaging</artifactId>
        <version>2.0</version>
      </extension>
    </extensions>

    <pluginManagement>
      <plugins>
        <plugin>
          <artifactId>maven-archetype-plugin</artifactId>
          <version>2.0</version>
        </plugin>
      </plugins>
    </pluginManagement>
  </build>
</project>

On constate qu'il y a deux points à noter dans cette structure d'archetype générée :

le patron de notre template de projet qui sera utilisé par maven lors de l'appel au goal archetype:generate se trouve dans le répertoire src/main/resources/archetype-resources/src,
dans le répertoire src/main/resources/META-INF/maven, se trouve le fichier archetype-metadata.xml qui contient le descriptif de ce qui doit être généré :

<?xml version="1.0" encoding="UTF-8"?>
<archetype-descriptor xsi:schemaLocation="http://maven.apache.org/plugins/maven-archetype-plugin/archetype-descriptor/1.0.0 http://maven.apache.org/xsd/archetype-descriptor-1.0.0.xsd" name="project-template"
    xmlns="http://maven.apache.org/plugins/maven-archetype-plugin/archetype-descriptor/1.0.0"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
    
  <fileSets>
    <fileSet filtered="true" packaged="true" encoding="UTF-8">
      <directory>src/main/java</directory>
      <includes>
        <include>**/*.java</include>
      </includes>
    </fileSet>
    <fileSet filtered="true" packaged="true" encoding="UTF-8">
      <directory>src/test/java</directory>
      <includes>
        <include>**/*.java</include>
      </includes>
    </fileSet>
    <fileSet filtered="true" encoding="UTF-8">
      <directory>src/config</directory>
      <includes>
        <include>**/*.xml</include>
      </includes>
    </fileSet>
    <fileSet filtered="true" encoding="UTF-8">
      <directory>src/assembly</directory>
      <includes>
        <include>**/*.xml</include>
      </includes>
    </fileSet>
    <fileSet filtered="true" encoding="UTF-8">
      <directory></directory>
      <includes>
        <include>README.txt</include>
      </includes>
    </fileSet>
  </fileSets>
</archetype-descriptor>

A cette étape, il est tout de suite possible d'installer l'archetype dans le repository maven (cf. Mise à disposition de l'archetype) et de l'invoquer (cf. Utilisation et résultat de l'archetype).
A noter qu'ici, il peut être intéressant de supprimer le support des .project, .classpath et .settings si le template a été géré avec eclipse.

Transformation de l'archetype

Dans le cadre de mon petit use case, je n'ai pas beaucoup besoin de customiser mon archetype. En effet, je souhaite seulement pouvoir demander à l'utilisateur (en l'occurence moi ;-) ), quel sera le nom de ma classe à me générer.

Pour ce faire, il n'y a qu'à ajouter une propriété dans le fichier src/main/resources/META-INF/maven/archetype-metadata.xml :

<requiredProperties>
    <requiredProperty key="className">
      <defaultValue>MyClass</defaultValue>
    </requiredProperty>
</requiredProperties>

Modifier le nom des fichiers java :

Test.java en __className__.java
TestTest en __className__.java

Et remplacer dans les fichiers respectifs :

public class Test {

public class ${className} {

public class TestTest {

public class ${className}Test {

En outre, il faut également modifier le fichier src/test/resources/projects/basic/archetype.properties pour y ajouter la ligne suivante :

className=MyClass

Enfin, il est possible de figer la version de l'archetype en modifiant le pom du projet ainsi que son artifactId et son groupId. Dans mon cas, il restera identique.

Mise à disposition de l'archetype

Une fois que l'archetype a été modifié pour répondre aux besoins, il n'y a plus qu'à exécuter la commande mvn install pour déployer l'archetype dans le repository local et la commande mvn deploy pour le déployer dans le repository partagé.

Utilisation et résultat de l'archetype

Une fois l'archetype déployé dans le repository adéquate, il n'y a plus qu'à l'invoquer via la commande :

mvn archetype:generate \
 -DarchetypeGroupId=fr.jetoile \
 -DarchetypeArtifactId=project-template-archetype \
 -DarchetypeVersion=0.0.1-SNAPSHOT \
 -DgroupId=fr.jetoile \
 -DartifactId=test-archetype

Ainsi, le résultat obtenu est le suivant :

Conclusion

Nous avons vu dans cet article qu'il était extrêmement simple de créer un archetype maven, action qui peut s'avérer très utile pour gagner du temps que ce soit pour des besoins personnels ou dans un cadre d'industrialisation du processus d'initialisation d'un projet dans une équipe.

[update] Je viens de mettre sur github le code :

du projet utilisé pour créer l'archetype ainsi que le code de l'archetype : https://github.com/jetoile/project-template
du projet permettant de créer l'archetype : https://github.com/jetoile/project-template-archetype

Cependant, je n'ai pas invoqué ici le cas de projets multimodules mais le principe reste identique, même s'il est possible d'utiliser d'autres templates (tel que __rootArtifactId__) si l'on souhaite préfixer le nom des modules avec l'artifactId du projet généré ou si l'on souhaite customiser plus finement un nom de répertoire (ou package) : dans ce cas, il peut être souhaitable d'ajouter d'autres propriétés dans le fichier archetype-metadata.xml :

<module id="${rootArtifactId}-core" dir="__rootArtifactId__-core" name="${rootArtifactId}-core">
      <fileSets>
        <fileSet filtered="true" encoding="UTF-8" packaged="true">
          <directory>src/main/java</directory>
          <includes>
            <include>**/*.java</include>
          </includes>
        </fileSet>
        <fileSet filtered="true" encoding="UTF-8" packaged="true">
          <directory>src/test/java</directory>
          <includes>
            <include>**/*.java</include>
          </includes>
        </fileSet>
      </fileSets>
    </module>
    <module id="${rootArtifactId}-client" dir="__rootArtifactId__-client" name="${rootArtifactId}-client">
      <fileSets>
        <fileSet filtered="true" encoding="UTF-8" packaged="true">
          <directory>src/main/java</directory>
          <includes>
            <include>**/*.java</include>
          </includes>
        </fileSet>
        <fileSet filtered="true" encoding="UTF-8" packaged="true">
          <directory>src/main/resources</directory>
          <includes>
            <include>**/*.xml</include>
            <include>**/*.properties</include>
          </includes>
        </fileSet>
        <fileSet filtered="true" encoding="UTF-8" packaged="true">
          <directory>src/test/resources</directory>
          <includes>
            <include>**/*.xml</include>
            <include>**/*.properties</include>
          </includes>
        </fileSet>
      </fileSets>
    </module>

Pour aller plus loin...

Apache Maven de N. De Loof, A. Héritier chez Pearson
Better Builds with Maven : http://repo.exist.com/dist/maestro/1.7.0/BetterBuildsWithMaven.pdf
Maven. Definitive Guide : http://www.sonatype.com/products/maven/documentation/book-defguide

Site de maven : http://maven.apache.org/

Les repositories Manager pour les nuls... focus sur Nexus

2011-05-20T12:32:00.000+02:00

Cela fait un moment que je n'ai pas bloggé faute de temps mais également d'inspiration... (ça c'est dit et ça, on s'en fout d'un coté ;-) ) Cet article parlera des repository manager. Rien de nouveau à l'horizon puisque la problématique et les solutions existent depuis un moment mais ayant dû en mettre un en place récemment et au vu de nombreuses questions que l'on m'a posées, je vais ici coucher sur "papier" ce qu'est un repository manager, c'est à dire quelques uns de ses concepts clés. En outre, cela me servira également d'aide mémoire et je me dis qu'une piqûre de rappel ne fait jamais de mal... ;-)

Pour ce faire, je vais m'appuyer sur l'excellent repository manager Nexus de Sonatype et plus particulièrement (comme à mon habitude... ;-) ) sur sa documentation officielle.

Par contre, je ne reviendrai pas sur les concepts de base de maven comme la définition de ce que sont les repositories local et distant.

Enfin, ici, j'utiliserai la même dénomination que le guide Nexus pour le terme organisation qui devra être pris au sens large du terme (entreprise, projet open source, poste local, ...).

Un repository Manager pour quoi faire?

Ce paragraphe fournit une courte introduction sur les repository Manager, qui pour ceux qui en douteraient encore, permet de répondre à deux problématiques :

il agit comme un proxy configurable entre votre organisation et les repositories publics maven,
il permet d'organiser l'endroit où se feront les déploiements des projets maven spécifiques à l'organisation.

En fait, ils sont le pendant de ce que sont les outils SCM (Source Code Management) au code source mais appliqué aux dépendances et aux artéfacts maven générés par le build.

Aussi, un repository Manager est un élément clé d'une usine logicielle en permettant, entre autre, une meilleure collaboration entre les développeurs et la mise à disposition de leurs binaires.

En effet, fournir un proxy (faisant également office de cache) à un repository maven public distant permet d'accélérer le processus de build en évitant les téléchargements inutiles sur internet : si une dépendance particulière est nécessaire (ainsi que ses dépendances transitives), elle ne sera téléchargée qu'une et une seule fois du repository public distant et sera mise à disposition de tous les développeurs. En outre, si un projet dépend de dépendances snapshot, maven, par défaut, tente d'accéder, à chaque build, aux repositories distants afin de vérifier s'il n'existe pas une version plus récente que celle présente dans le repository local. Le fait d'avoir un repository manager permet de scheduler ces mises à jour en fonction du besoin afin d'éviter un traffic trop important et parfois inutile.

De plus, un repository Manager permet à l'organisation de garder le contrôle de ce qui est téléchargé par maven empêchant ainsi à nos chers développeurs (dont je fais parti) de tirer n'importe quelle dépendance (ainsi que n'importe quelle version) dans son projet mais également de contrôler les licences des dépendances utilisés (c'est vrai que cela serait dommage de voir son projet tomber dans l'open source juste à cause d'une licence un peu trop contaminatrice...).

Enfin, un repository manager permet de fournir un repository partagé par tout ou parti de l'organisation offrant ainsi un repository privé où peuvent être entreposés les binaires de cette dernière, les rendant ainsi accessibles à tout ou parti des équipes de développement. Ces binaires pouvant être dans un état stable (release) ou en cours de développement (snapshot) permettent ainsi aux développeurs de ne pas à avoir à récupérer et à builder les sources lorsqu'une dépendance à une librairie interne est nécessaire.

Dernier point qui peut avoir son importance, mais si l'organisation se retrouve coupé d'internet ou que les repositories publics maven sont indisponibles, cela n'impacte pas les développeurs (modulo le fait qu'ils n'aient pas besoin d'une dépendance ne se trouvant pas sur le repository manager) qui peuvent alors continuer à travailler et même à releaser leurs projets, et cela même s'ils disposent d'un repository local vierge.

Retour sur les types de repositories possibles

Cet article prenant ses racines dans la documentation officielle de Nexus, il est possible que certains types de repositories présentés ci-dessous ne soient pas offerts par d'autres implémentations. Cependant, les concepts sont similaires même si certaines subtilités peuvent être présentes dans d'autres solutions.

Nexus offre 3 types de repositories :

Proxy Repository qui, comme son nom l'indique peut être vu comme le proxy d'un repository distant. Par défaut, Nexus vient configuré avec les proxies suivants :
- apache-snapshots (http://people.apache.org/repo/m2-snapshot-repository),
- codehaus-snapshot (http://snapshots.repository.codehaus.org/),
- et maven-central-repo (http://repo1.maven.org/maven2/)
Hosted Repository qui sont des repositories hébergés par Nexus. Par défaut, Nexus vient configuré avec les hosted repositories suivants :
- 3rd Party devant être utilisé pour des librairies non présentes dans les repositories maven publics
- Releases devant être utilisé pour les librairies stable de l'organisation
- Snapshots devant être utilisé pour les librairies en cours de développement de l'organisation
Virtual Repository qui peut être vu comme un adaptateur de repositories au format différents que ceux attendus. Par défaut, Nexus vient configuré avec 2 virtual repository permettant la conversion de repository au format maven 1 et 2 vers (respectivement) des repositories au format maven 2 et maven 1.

En outre, Nexus propose la notion de groupe qui permet de combiner de multiples repositories sous la même url d'accès. Ainsi, cela permet d'alléger la configuration du fichier settings.xml en offrant, sous la houlette d'un groupe, l'aggrégation de plusieurs repositories pouvant être de différentes natures.

Par exemple, Nexus vient configuré avec les deux groupes suivants :

public qui regroupe les repositories 3rd Party, releases et snapshots du repository maven-central-repo,

et public-snapshots qui regroupe les repositories apache snapshots et codehaus snapshot.

Il est à noter que l'ordre de déclaration des repositories dans un groupe a son importance puisque la recherche est ordonnée et que dès que la librairies est trouvée, la recherche s'arrête et l'artéfact rendu (ainsi, il convient de mettre le repository succeptible de posséder les librairies les plus recherchés en premier).

En outre, il est possible d'associer à un groupe des routes qui se comportent comme des filtres permettant ainsi d'inclure ou d'exclure des repositories. Cette fonctionnalité peut, par exemple, être utilisée afin d'être sûr que les artéfacts récupérés dans un groupe donné ne sont que ceux de l'organisation (en s'appuyant sur le groupId maven).

Gestion des repositories dans le cas où plusieurs équipes accèdent au même repository Manager

Ces recommandations s'appuient sur le chapitre 17 du guide sur Nexus.

Les façons les plus communes pour supporter différentes équipes est :

d'associer spécifiquement à chaque équipe/projet deux repositories (un repository release et un repository snapshot) en leurs associant les bons droits.
d'avoir un ou des ensembles de deux repositories (release et snapshot) pour l'ensemble de l'organisation et de contrôler l'accès en utilisant des repository target dans la gestion des privilèges d'accès par un rôle aux repositories. Ce sont ces rôles qui peuvent ensuite être associés aux utilisateurs pour gérer la sécurité.

Trucs et astuces en vrac...

Enfin, ce paragraphe liste en vrac un certain nombre de points qu'il peut être nécessaire de prendre en compte lors de la mise en oeuvre d'un repository Manager.

Ayant la flemme de commenter les différents points, je ne jetterai que les idées sans ordre de préférence en laissant le soin à chacun de les prendre en compte... ou pas... ;-)

Utilisation et mise en oeuvre de repository de Staging.
Attention au distributionManagement se trouvant dans le pom parent (ce qui est une bonne pratique malgré tout) : il peut être nécessaire de positionner cette information dans le fichier settings.xml via des propriétés afin de permettre une éventuelle migration du repository Manager sur un autre serveur (et s'il n'est pas possible d'avoir un DNS) et cela sans avoir à maintenir à tout jamais une redirection apache (cf. bonnes pratiques maven) (http://maven.40175.n5.nabble.com/Can-t-specify-distributionManagement-in-settings-xml-td3181781.html).
Le repository Manager étant un élément clé de l'usine logicielle au même titre qu'un annuaire d'entreprise pour une entreprise, il peut s'apparenter à un Single Point Of Failure (même s'il est possible de le mirrorer). Aussi, il convient de superviser le serveur avec soin (CPU, RAM, IO, espace disque, ...) et si possible de posséder une machine dédiée à cette tache. En outre, il convient de faire attention, si une VM est utilisée, de lui affecter suffisamment de ressources qu'elles soient réseau ou autre.
Mettre en place un Repository Manager, même s'il s'agit d'une tache aisée, peut demander du temps mais également quelques connaissances de base. Aussi, il ne faut pas prendre cette tache à la légère, en particulier concernant les choix d'organisation des différents repositories ainsi que des choix de sécurité. En effet, migrer d'une solution à une autre, même si cela est généralement possible, peut avoir des conséquences sur l'ensemble du parc informatique de développement.
Un repository Manager (ou plutôt ses hosted repositories) contenant les binaires et éventuellement les livrables des projets, il est important de le sauvegarder avec soin.
Il convient de réfléchir aux besoins de mettre en place une authentification des différents repositories et, dans ce cas, du besoin de la coupler à un annuaire.
Il convient de faire attention à l'ordre de résolution des différents repositories au risque de diminuer les performances de recherche et de téléchargement des différentes librairies.
Il convient de bien configurer les différentes taches d'administration et de maintenance du repository Manager (reindéxation, suppression des snaphots obsolètes, ...).

Enfin un point transverse, mais si la sécurité est mise en place sur les repositories et qu'elle utilise une authentification pour chaque utilisateur, il est possible de crypter les mots de passe plutôt que de les avoir en clair dans le fichier settings.xml (http://sonatype.com/books/maven-book/reference/appendix-settings-sect-encrypting-passwords.html et http://maven.apache.org/guides/mini/guide-encryption.html).

Conclusion

Vous aurez compris (si vous avez lu juste qu'au bout cet article) que cet article correspond plus à un aide-mémoire qu'à une vrai explication de ce qu'est un repository Manager... ;-)

Concernant les trucs et astuces, si vous en avez d'autre, je suis preneur et je me ferai un plaisir les intégrer dans la rubrique trucs et astuces ;-)

Pour aller plus loin...

Pdf de Sonatype sur Nexus : http://www.sonatype.com/repository-management-with-nexus-book.html

Apache Maven de N. De Loof, A. Héritier chez Pearson
Better Builds with Maven : http://repo.exist.com/dist/maestro/1.7.0/BetterBuildsWithMaven.pdf
Maven. Definitive Guide : http://www.sonatype.com/products/maven/documentation/book-defguide

Site de maven : http://maven.apache.org/

MicroBenchmark : par la pratique

2011-03-22T01:03:00.007+01:00

Cet article fait suite à mon article précédent afin de donner mon rapide retour d'expérience sur quelques écueils qui peuvent être commis lors de l'écriture d'un microBenchmark et dans lesquels je suis, bien sûr, tombé :(. Pour remettre dans le contexte, c'est l'écriture de ce benchmark qui a entrainé l'écriture de mon article précédent suite aux résultats que j'ai pu constater et pour lesquels j'ai eu l'aide de mes camarades.

Contexte

Un collègue me disait que le foreach était moins performant qu'une boucle for en raison du fait que l'invocation d'une opération supplémentaire (la méthode next()) rendait l'opération plus lente en raison de la pile de notre cher compteur ordinal (pour ceux qui ne se rappelleraient pas, je vous renvoie sur vos cours d'assembleur ;-) ), enfin que, du moins, en .Net ça marchait comme ça. Ma réponse : "ben j'en sais rien" puisque je ne savais pas quelles étaient les optimisations faites par le compilateur (ouais, je sais, super les sujets de conversation...).
Du coup, ni une, ni deux, j'ai ouvert mon IDE préféré et j'y ai jeté quelques lignes de code pour avoir ma réponse, et là... ce fut le drame... : des résultats bizarres sont apparus...
Ce petit article a donc pour objectif de vous fournir le résultat de ce qu'il faut faire et ne pas faire lors de l'écriture d'un microBenchmark mais également de fournir la réponse que tout le monde attend, à savoir : qui est réellement le plus fort entre le for et le foreach (ça peut éviter d'avoir à perdre 5 minutes de test...).
Bien sûr, n'étant pas expert dans ce domaine, il s'agit juste d'un retour d'expérience dont je vous laisse seul juge de la véracité... ;-)
Premier disclaimer : contrairement à ce que j'ai présenté dans mon post précédent, je n'effectuerai pas, ici, différents tirs sur différentes architectures d'ordinateurs, VM ou avec différentes options. En effet, ce qui m'intéresse dans cet article est d'entrevoir ce qui peut se passer dans la VM et comment cela peut impacter les performances d'un petit bout de code.
Deuxième disclaimer : lors de la procédure d'élagage, un coefficient de 0,5 sera utilisé afin de lisser au maximum mes résultats et cela, en raison de pics très importants observés (pics liés, comme nous le verrons par la suite soit, au warm-up de la JVM, soit au GC).

Procédure de test et analyse

Première tentative

Scénario

Ma première tentative de benchmark était la suivante :

on instancie une liste d'un chaîne de caractère,
on itère dessus sans rien faire,
on regarde le temps passé.

Ce petit test sera exécuté une centaine de fois afin de pouvoir lisser le résultat.
Le code utilisé pour faire ce petit test est le suivant :

public class IterableBenchmark0 {

    private final static int NB_ITEM = 100000;
    private final static int NB_TEST = 100;

    static List<String> list = new ArrayList<String>(NB_ITEM);

    static {
        for (int i = 0; i < NB_ITEM; i++) {
            list.add(Integer.toString(i));
        }
    }

    public static void main(String[] args) {
        Long[] res = new Long[NB_TEST];
        for (int j = 0; j < NB_TEST; j++) {

            long startTime = System.nanoTime();
            for (int i = 0; i < list.size(); i++) {
            }

            // for (String value : list) {
            // }

            // int i = 0;
            // while (i < list.size()) {
            // i++;
            // }

            res[j] = (System.nanoTime() - startTime);
        }

        long total = 0;
        for (int j = 0; j < NB_TEST; j++) {
            total += res[j];
            System.out.println(res[j]);
        }
        System.out.println("sum : " + total);
        System.out.println("moy : " + total / NB_TEST);
    }
}

On y constate, bien sûr, que la récupération des métriques n’encadre que l’opération à tester mais, également, que l’instanciation et l’initialisation de l’ArrayList utilisé ici sont faites en dehors du test.

Résultats

Suite à ce test, les résultats obtenus ont été les suivants :

Après élagage des résultats abérants (procédé commun à tous tes des charges), ces résultats peuvent être réduits aux résultats suivants (ici, k = 0,5) :

A noter que ce graphique n'a été issu que d'un seul tir... mais, si vous daignez croire mes dires, il est assez représentatif des autres tirs.

Analyse

Les résultats précédents montrent clairement une différence entre les tirs avec et sans élagages (normal me direz-vous). Cependant, elles apparaissent principalement sur les deux premières itérations de notre boucle chargée d'itérer notre List.
En outre, après élagage, on constate, malgré tout, qu'une nette différence persiste entre les boucles for et while et notre foreach.
A titre informatif, c'est à ce moment là que j'ai dû appeler mes amis (ça ne vous rappelle pas quelque chose...?) pour obtenir une analyse plus précise des résultats que je ne comprenais pas... :(
Du coup (et là, je ne vais pas me fouler ;-) ), je vous cite les réponses des différents intéressés (et oui, il est possible d'avoir plusieurs amis... (si cela vous amuse, je vous laisse deviner qui a dit quoi) que je remercie encore une fois ;-) :

première réponse :

Ces résultats sont parfaitement logiques.
Pour for et while, la VM s'aperçoit au bout de quelques itérations que la boucle est inutile.
- on connaît le nombre d'itérations sans avoir besoin d'itérer réellement sur la liste (list.size() est fixe) ;
- la boucle n'a aucun "side-effect" en-dehors.
Du coup, la boucle entière est éliminée, d'où les temps nuls.
Pour for-each, c'est plus compliqué :
- La notation syntaxique "for-each" est compilée sous la forme d'un parcours d'itérateur :
for (Iterator it=list.iterator(); it.hasNext; ) { ... }
Du coup, impossible de connaître le nombre d'itérations à l'avance : la JVM est obligée de tout parcourir
- En plus, pour éviter les modifications concurrentes de la collection (celles qui lancent le fameux ConcurrentModificationException), la méthode next() effectue des vérifications, qui prennent du temps.
Bref, dans ce cas, for-each est moins performant, ou du moins, nettement moins optimisable, que "for" ou "while"
Si tu veux un test plus représentatif des performances réelles, moins sujettes à des optimisations agressives, il faut que les boucles aient un "side-effect" (par exemple, ajouter chaque élément parcouru dans une seconde liste, située en-dehors de la boucle).

deuxième réponse :

(...) la Hotspot utilise la zone "code cache" pour cacher des informations à la volée et compiler du code plus optimisé grâce à JIT en fonction des hotspots détectés. Je viens de retrouver un post sur le blog de Sun qui confirme ce mécanisme. Il montre un exemple sur l'optimisation d'une boucle while: http://blogs.sun.com/ahe/entry/hotspot_and_other_compilers

troisième réponse :

Alors tout d'abord, je pense que comparer le for et le foreach n'a pas de sens en soi... En effet, il ne faut pas oublier que quand tu écrit ton code Java, celui-ci est compilé en .class (bytecode).
Ces .class sont alors interprétés ou compilés à la volées (par le compilateur Just In Time).
De plus, comme tout micro-benchmark Java, il faut se méfier des résultats.
Tout simplement, le comportement de la JVM (Hotspot) change du tout au tout en fonction des paramètres VM (-server et -client, les cycles d'optimisation...)
Ensuite, si ton code est fort utilisé, il sera automatiquement "inliné" par le JIT...

Je pense que les conclusions à tirer sont claires... le code testé est erroné : mon Compilateur Planning m'a inliné le code à tester et le fait que les deux premières itérations soit si élevées par rapport aux autres résultats est lié au warm-up de ma JVM.

Deuxième tentative

Scénario

Du coup, suite à ma première tentative de benchmark infructueuse, deuxième essai en apprenant de mes erreurs... :

on instancie une liste d'un chaîne de caractère,
on itère dessus en ajoutant un effet de bord afin d'empêcher mon Compilateur Planning de m'inliner mon code,
on regarde le temps passé.

Comme précédemment, ce petit test sera exécuté une centaine de fois afin de pouvoir lisser le résultat.
Le code utilisé pour faire ce petit test est le suivant :

public class IterableBenchmark1 {

    private final static int NB_ITEM = 100000;
    private final static int NB_TEST = 100;

    static List<String> list = new ArrayList<String>(NB_ITEM);

    static {
        for (int i = 0; i < NB_ITEM; i++) {
            list.add(Integer.toString(i));
        }
    }

    static StringBuilder sideEffect = new StringBuilder();

    public static void main(String[] args) {
        Long[] res = new Long[NB_TEST];
        for (int j = 0; j < NB_TEST; j++) {

            long startTime = System.nanoTime();
            for (int i = 0; i < list.size(); i++) {
                sideEffect.append(list.get(i));
            }

            // for (String value : list) {
            // sideEffect.append(value);
            // }

            // int i = 0;
            // while (i < list.size()) {
            // sideEffect.append(list.get(i));
            // i++;
            // }

            res[j] = (System.nanoTime() - startTime);
        }

        long total = 0;
        for (int j = 0; j < NB_TEST; j++) {
            total += res[j];
            System.out.println(res[j]);
        }
        System.out.println("sum : " + total);
        System.out.println("moy : " + total / NB_TEST);
    }
}

Résultats

Suite à ce test, les résultats obtenus ont été les suivants :

Après élagage des résultats aberrants (procédé commun à tous tests des charges), ces résultats peuvent être réduits aux résultats suivants (ici, k = 0,5) :

A noter que ce graphique n'est toujours isssu que d'un seul tir...

Analyse

Les résultats semblent enfin cohérents! ouf...!
En effet, on constate que, mis à part les GC, et le warm-up de ma VM, mon Compilateur Planning n'a pas réussi à inliner mon code et me fournit, du coup, le résultat attendu.
Après un coup d'élagage me permettant de me débarrasser de mes pics liés au GC, mes courbes sont lissées et se chevauchent même.
Enfin, j'ai ma réponse (mais je garde ça pour plus tard même si je suppose que, du coup, vous connaissez le fin mot de l'histoire!... mais attendez, ne partez pas... la suite est intéressante également ;-))

Troisième tentative

Scénario

Bon, il est vrai, j'ai obtenu mon résultat sur ma deuxième tentative.
Cependant, pendant la présentation de Joshua Bloch (cf. post précédent), un point m'a particulièrement intéressé : le framework Caliper.
En effet, ce framework semble être fait pour répondre aux problématiques des microBenchmark.
Du coup, je vais, ici, montrer comment je l'ai utilisé ainsi que les résultats qu'il m'a fourni.
Deux raisons à cela :

valider mes résultats précédents afin de vérifier que je n'ai rien laissé passer...
m'amuser un peu... ;-)

Disclaimer : cette partie n'abordera ni comment installer, ni comment utiliser Caliper. Elle est juste fournie à titre indicatif.
Le code utilisé pour faire cette troisième tentative est le suivant :

public class IterableBenchmark2 extends SimpleBenchmark {

    private final static int NB_ITEM = 100000;

    List list = new ArrayList(NB_ITEM);
    StringBuilder sideEffect = null;

    @Override
    protected void setUp() throws Exception {
        for (int i = 0; i < NB_ITEM; i++) {
            list.add(Integer.toString(i));
        }
        sideEffect = new StringBuilder();
    }

    public StringBuilder timeFor(int reps) {
        for (int i = 0; i < reps; ++i) {
            for (int j = 0; j < list.size(); j++) {
                sideEffect.append(list.get(j));
            }
        }
        return sideEffect;
    }

    public StringBuilder timeForeach(int reps) {
        for (int i = 0; i < reps; ++i) {
            for (String value : list) {
                sideEffect.append(value);
            }
        }
        return sideEffect;
    }

    public StringBuilder timeWhile(int reps) {
        for (int i = 0; i < reps; ++i) {
            int j = 0;
            while (j < list.size()) {
                sideEffect.append(list.get(j));
                j++;
            }
        }
        return sideEffect;
    }

    public static void main(String[] args) throws Exception {
        Runner.main(IterableBenchmark3.class, args);
    }
}

On remarque ici, que, plutôt que d'exécuter via un script extérieur mon tir, j'ai préféré le faire en invoquant directement le main().

Résultats

Suite à ce test, les résultats obtenus ont été les suivants :

0% Scenario{vm=java, trial=0, benchmark=For} 3535251,80 ns; σ=197827,29 ns @ 10 trials
33% Scenario{vm=java, trial=0, benchmark=Foreach} 3676070,55 ns; σ=190018,30 ns @ 10 trials
67% Scenario{vm=java, trial=0, benchmark=While} 3508898,75 ns; σ=222565,30 ns @ 10 trials

benchmark   ms linear runtime
      For 3,54 ============================
  Foreach 3,68 ==============================
    While 3,51 ============================

vm: java
trial: 0

Ces résultats sont donnés avec une seul tir.
Pour montrer comme il est aisé d'effectuer plusieurs tirs avec Caliper (tir qui lance à chaque fois une nouvelle JVM dans un process - process au sens UNIX du terme - différent), modifions juste notre méthode main() pour y passer d'autres options :

public static void main(String[] args) throws Exception {
        Runner.main(IterableBenchmark3.class, new String[] { "--trials", "5"});
    }

Ce qui donne le résultat suivant :

0% Scenario{vm=java, trial=0, benchmark=For} 3425915,23 ns; σ=207711,73 ns @ 10 trials
 7% Scenario{vm=java, trial=1, benchmark=For} 3453313,87 ns; σ=193613,25 ns @ 10 trials
13% Scenario{vm=java, trial=2, benchmark=For} 3807062,28 ns; σ=278917,43 ns @ 10 trials
20% Scenario{vm=java, trial=3, benchmark=For} 3807244,53 ns; σ=283377,19 ns @ 10 trials
27% Scenario{vm=java, trial=4, benchmark=For} 3808771,58 ns; σ=270090,07 ns @ 10 trials
33% Scenario{vm=java, trial=0, benchmark=Foreach} 3504679,81 ns; σ=190093,88 ns @ 10 trials
40% Scenario{vm=java, trial=1, benchmark=Foreach} 3620052,15 ns; σ=216116,18 ns @ 10 trials
47% Scenario{vm=java, trial=2, benchmark=Foreach} 3519711,06 ns; σ=173384,58 ns @ 10 trials
53% Scenario{vm=java, trial=3, benchmark=Foreach} 3527981,05 ns; σ=232274,54 ns @ 10 trials
60% Scenario{vm=java, trial=4, benchmark=Foreach} 3549837,79 ns; σ=196295,32 ns @ 10 trials
67% Scenario{vm=java, trial=0, benchmark=While} 3628542,80 ns; σ=223275,59 ns @ 10 trials
73% Scenario{vm=java, trial=1, benchmark=While} 3569981,43 ns; σ=225773,17 ns @ 10 trials
80% Scenario{vm=java, trial=2, benchmark=While} 3596601,06 ns; σ=266773,47 ns @ 10 trials
87% Scenario{vm=java, trial=3, benchmark=While} 3493799,14 ns; σ=220276,60 ns @ 10 trials
93% Scenario{vm=java, trial=4, benchmark=While} 3642079,85 ns; σ=185312,29 ns @ 10 trials

benchmark trial   ms linear runtime
      For     0 3,43 ==========================
      For     1 3,45 ===========================
      For     2 3,81 =============================
      For     3 3,81 =============================
      For     4 3,81 ==============================
  Foreach     0 3,50 ===========================
  Foreach     1 3,62 ============================
  Foreach     2 3,52 ===========================
  Foreach     3 3,53 ===========================
  Foreach     4 3,55 ===========================
    While     0 3,63 ============================
    While     1 3,57 ============================
    While     2 3,60 ============================
    While     3 3,49 ===========================
    While     4 3,64 ============================

vm: java

Analyse

On constate ici que les résultats obtenus avec Caliper sont cohérents avec ceux obtenus précédemment (ie. les résultats sont similaires quelque soit la méthode d'itération), même si on remarque une légère différence due au bruit ajouté par l'utilisation du framework, bruit qui ne doit pas être pris en compte puisque si un tel framework venait à être utilisé, tous les résultats analysés seraient, évidemment, issus de l'utilisation de Caliper. En outre, n'oublions pas qu'il faut raisonner en terme de statistique et non en terme de chiffre pur...

Quatrième tentative... juste pour le fun

Scénario

Cette avant dernière tentative est juste faite pour le fun pour montrer le comportement de Caliper avec un microBenchmark douteux... ie. notre premier test ;-).
Aussi, reprenons notre troisième tentative et supprimons les effets de bord :

public class IterableBenchmark3 extends SimpleBenchmark {

    private final static int NB_ITEM = 100000;

    List list = new ArrayList(NB_ITEM);

    @Override
    protected void setUp() throws Exception {
        for (int i = 0; i < NB_ITEM; i++) {
            list.add(Integer.toString(i));
        }
    }

    public void timeFor(int reps) {
        for (int i = 0; i < reps; ++i) {
            for (int j = 0; j < list.size(); j++) {
            }
        }
    }

    public void timeForeach(int reps) {
        for (int i = 0; i < reps; ++i) {
            for (String value : list) {
            }
        }
    }

    public void timeWhile(int reps) {
        for (int i = 0; i < reps; ++i) {
            int j = 0;
            while (j < list.size()) {
                j++;
            }
        }
    }

    public static void main(String[] args) throws Exception {
        Runner.main(IterableBenchmark3.class, args);
    }
}

Résultats

Suite à ce test, les résultats obtenus ont été les suivants :

0% Scenario{vm=java, trial=0, benchmark=For}  Failed to execute java -cp /home/khanh/eclipse-workspace/benchmark/target/classes:/home/khanh/eclipse-workspace/caliper-read-only/caliper/target/classes:/home/khanh/.m2/repository/com/google/code/gson/gson/1.7-SNAPSHOT/gson-1.7-SNAPSHOT.jar:/home/khanh/.m2/repository/com/google/guava/guava/r07/guava-r07.jar:/home/khanh/.m2/repository/com/google/code/java-allocation-instrumenter/java-allocation-instrumenter/2.0/java-allocation-instrumenter-2.0.jar com.google.caliper.InProcessRunner --warmupMillis 3000 --runMillis 1000 --measurementType TIME --marker //ZxJ/ -Dbenchmark=For fr.soat.blog.benchmark.IterableBenchmark3
starting Scenario{vm=java, trial=0, benchmark=For}
[caliper] [starting warmup]
[caliper] [starting measured section]
Error: Doing 2x as much work didn't take 2x as much time! Is the JIT optimizing away the body of your benchmark?

Analyse

La bonne surprise est que Caliper nous indique clairement que JIT a optimisé notre code et que, donc, notre microBenchmark est erroné!
A voir s'il se comporte ainsi avec tous les microBenchmark erronés...

Cinquième tentative... allez, une dernière pour la route

Scénario

Cette dernière tentative permet de voir ce qui se passerait si on désactivait JIT via l'option -Xint.
Pour rappel, l'option Xint permet de :

Operate in interpreted-only mode. Compilation to native code is disabled, and all bytecodes are executed by the interpreter. The performance benefits offered by the Java HotSpot Client VM's adaptive compiler will not be present in this mode.

Le code utilisé est celui de notre première tentative.

Résultats

Suite à ce test, les résultats obtenus ont été les suivants :

Après élagage des résultats aberrants (procédé commun à tous tes des charges), ces résultats peuvent être réduits aux résultats suivants (k = 1) :

A noter que ce graphique n'est toujours issu que d'un seul tir...

Analyse

Bien sûr, ces résultats ne sont pas du tout représentatifs puisque le byte code est seulement interprété par la JVM et que cela ne représente pas la réalité. Cette dernière tentative n'est présentée qu'à titre indicatif afin de constater les différences qu'il peut y avoir entre le code que l'on écrit (ou compilé) et le code qui est réellement exécuté.

Conclusion

Voilà, j'arrive à la fin de mes conclusions que je vous cite en vrac ;-) :

faire un microBenchmark est difficile et cet article ne montre qu'une ébauche des difficultés que cela peut poser,
il est plus simple d'utiliser un outil qui sait bien faire son travail,
il ne faut pas toujours se fier à ce que l'on peut constater : le risque que le cas observé ne soit pas représentatif de la réalité est élevé,
de manière générale, on peut dire qu'il y a match nul entre le for et le foreach (en tout cas, dans notre cas de figure!).

Bon, un dernier mot : cet article n'apportera rien aux personnes déjà sensibilisées à ce type de problématiques et ce qu'on peut retenir est qu'il ne faut pas tenter d'optimiser inutilement son code (cf. article précédent). Je trouvais juste les résultats intéressants à montrer ;-)

Ah oui, encore une chose, pour information, mon ordinateur possède les caractéristiques suivantes :

Remerciements

Par ordre alphabétique :

Zouheir Cadi (@ZouheirCadi),
Olivier Croisier (@OlivierCroisier),
Arnault Jeanson (@ArnaultJeanson),
Séven Lemesle (@slemesle)
et François Ostyn (@ostynf)

Pour aller plus loin...

Présentation de Joshua Blosh sur Parleys : http://www.parleys.com/#sl=0&st=5&id=2103
Site du framework Caliper : http://code.google.com/p/caliper/
Présentation de Cliff Click : http://www.azulsystems.com/events/javaone_2009/session/2009_J1_Benchmark.pdf
Page Wiki de Sun sur le microBenchmark : http://wikis.sun.com/display/HotSpotInternals/MicroBenchmarks
Page de google Android sur la gestion des perfomances d’Android : http://developer.android.com/guide/practices/design/performance.html

MicroBenchmark : mode d'emploi

2011-03-18T00:25:00.005+01:00

Cet article fait suite à une petite discussion que j'ai eue récemment avec un collègue sur qui était le plus fort entre le for et le foreach. Question qui peut paraitre, au premier abord, stupide mais qui m'a fait pas mal me creuser les neurones sur des points qui n'ont pas grand chose à voir avec le problème initial... (mais là, je m'avance un peu sur mon article... ;-) ).

Enfin, pour revenir au sujet initial (qui était, je le répète : "qui était le plus fort entre le for et foreach"), j'ai donc décidé de me faire un petit benchmark pour tester la performance des deux. Et là, ce fut le début des galères...

Je m'explique : suite à l'écriture rapide d'un petit benchmark pour tester mes deux méthodes d'itérations, j'ai obtenu des résultats qui pouvaient paraître bizarres (enfin bizarres pour moi). S'en est alors suivi de multiples discussions avec (par ordre alphabétique) Zouheir Cadi (@ZouheirCadi), Olivier Croisier (@OlivierCroisier), Arnault Jeanson (@ArnaultJeanson), Séven Lemesle (@slemesle) et François Ostyn (@ostynf) que je tiens d'ailleurs à remercier pour leurs lumières et leur disponibilité.

Je vous passe les résultats (cela fera l'effet d'un article ultérieur) pour en revenir juste à la notion de Benchmark qui s'avère être beaucoup plus complexe que cela peut paraitre.

Aussi, suite à cette longue introduction (qui, mis à part raconter ma vie, n'apporte pas grand chose mais qui permet de positionner le contexte ;-) ), je vais donc tenter de montrer en quoi le fait de benchmarker un simple petit bout de code peut amener à des résultats erronés et peut être quelque chose de non trivial.

Pour ce faire, je ne vais pas me casser trop la tête mais juste vous faire un petit compte rendu de la présentation de Monsieur Joshua Bloch (himself) qu'il a donné en 2010 à Devoxx sur l'importance du micro-benchmark ou plus précisément sur les optimisations des performances (encore merci à François pour le lien! ;-) ).

Un peu de vocabulaire...

Avant de commencer, nous allons d'abord définir ce qu'est un microBenchmark : un microBenchmark a pour objectif de mesurer les performances d'une petite portion de code. Ces tests s'exécutent généralement en un laps très court de temps (de l'ordre de la milliseconde) et ne font généralement pas d'opérations d'entrée/sortie (sauf, si bien sûr, c'est le but du microBenchmark). Le microBenchmark est très différent du profiling qui a pour cible l'application complète et qui fournit des résultats se voulant représentatifs de la réalité alors que le microBenchmark a vraiment pour objectif de se focaliser sur une portion de code très restreinte afin d'observer ses performances "brutes" sans se soucier d'un éventuel contexte d'exécution.

Le premier point que l'on peut se demander est : faut-il optimiser son code?

La réponse ne diffère pas de celle fourni par le livre "Effective Java" de Joshua Bloch : il ne faut pas tenter d'optimiser son code sauf dans certains cas comme lorsque l'on développe un API, un framework ou un langage (comme Groovy par exemple). En effet, écrire du code qui se veut optimisé peut conduire à complexifier le code le rendant ainsi illisible mais peut surtout avoir l'effet contraire en le rendant plus lent.

En effet, à l'époque, il était possible d'évaluer les performances d'un programme en comptant le nombre d'instructions qui était exécutées, c'est-à-dire en comptant le nombre de cycles des opérations. Cependant, cela n'est actuellement plus possible en raison de la trop grande différence qu'il existe entre le code écrit et le code qui est réellement exécuté par le processeur. Les coupables : le nombre de couches qui augmente avec notamment un langage de plus en plus compliqué qui s'appuie sur de plus en plus de librairies mais également sur une JVM de plus en plus complexe. A ces différentes couches logicielles vient également s'ajouter une couche matérielle qui se complexifie également et que peu de personnes peuvent prétendre maîtriser : les nouvelles architectures de processeurs, les unités de calculs fournies par les GPU, la gestion de la RAM. Et bien sûr, tout cela en y ajoutant le système d'exploitation.

Du coup, prédire les performances d'un bout de code devient quelque chose de non déterministe qu'il devient très difficile d'estimer.

Prenons un exemple simple : A votre avis, quel est le plus performant entre l'opérande && (et conditionnel) et l'opérande & (et logique)?

A première vue, on pourrait se dire que le et conditionnel est plus performant puisque la deuxième condition n'est pas obligatoirement évaluée. Cependant, cela n'est pas si simple. En effet, avec un bonne architecture (processeur, compilateur, ...), les deux conditions du et logique peuvent être évaluées en parallèle, ce qui est généralement plus rapide que de laisser au processeur le soin de deviner si la deuxième condition doit être évaluée (dans le cas du et conditionnel). Bien sûr, cela dépend du compilateur et de la capacité de la machine d'exécution (capacité du Just-In-Time Compiler ou de la famille de processeur utilisée) à traiter l'opération (modulo bien sûr que les conditions ne soient pas trop complexes).

Du coup, prédire de manière absolue laquelle de ces deux opérandes est la plus performante est quasi-impossible et le seul moyen de le savoir est de le mesurer.

Mesurer, oui!... mais comment?

Mesurer... cela semble simple, cependant, il est facile de se douter que les mesures relevées dépendent de l'environnement d'exécution. Plus grave encore, sur une même machine, l'exécution successive d'un même test (que l'on appellera tir par la suite) peut remonter des résultats très différents (différences qui peuvent atteindre 20%).

En outre, il est aisé de constater que si, lors d'un tir, le même test est effectué un grand nombre de fois, les métriques remontées ne sont pas linéaires. En effet, on constate trois phases (si on se concentre sur le temps de réponse d'une ou d'un ensemble d'opérations) :

la première phase où les temps observés sont élevés. Cette phase correspond au warm-up de la JVM,
la seconde phase où les temps observés diminuent et stagnent. Cette phase correspond à la phase de stabilisation de la JVM,
et la troisième phase où les temps diminuent. Cette dernière phase correspond à la phase de speed up de la JVM.

Ainsi, pour résumer, un benchmark doit effectuer un grand nombre de tirs qui doivent contenir plusieurs itérations du code à tester afin de permettre à la JVM de se stabiliser.

Les raisons de tous ces soucis?

En fait, si prédire les performances d'une opération par rapport à une autre est difficile, cela est paradoxalement dû à l'augmentation de la complexité de nos systèmes, complexité croissante entrainée par la recherche de la performance. En effet, ces optimisations d'exécution ont entraînées l'inline de code, le cache ainsi que beaucoup d'heuristiques (Paradoxal tout ça... n'est-il pas?).

Je m'explique (enfin pour être plus précis, Joshua Bloch explique ;-) ) : en fait, le thread compilateur planning utilise de nombreuses heuristiques pour décider ce qu'il faut inliner. Ces décisions sont prises en fonction d'informations locales et peuvent avoir un impact global. En outre le compilateur planning est exécuté par un thread tournant en tache de fond et dont le comportement peut varier pendant son exécution. Il est donc non déterministe.

Du coup, il est quasiment impossible de prédire quelles seront les performances d'une application et plus embêtant de savoir si une opération sera plus performante qu'une autre dans un contexte donné.

Et moi? Du coup, je fais quoi? Comment puis-je connaitre le gain de performances de mon code?

Et bien, la solution est statistique! Il faut mesurer les performances (en effectuant de nombreux tirs tels que cela a été décrit précédemment) du bout de code critique à surveiller régulièrement et en sortir des statistiques. Ce sont ces statistiques qui sont les seules métriques garantes des performance du code. Cependant, il est important de conserver les métriques de tous les tirs (qui pour rappel effectue l'opération de multiples fois) même si elles peuvent sembler aberrantes (bien sûr, si on suspecte que les résultats obtenus sont biaisés en raison d'un événement extérieur - comme une réindexation du disque dur ou le passage de l'anti-virus -, il ne faut pas les garder). Il convient alors de sortir de cet ensemble de tirs les métriques adéquates (moyenne, médiane, écart-type, ...).

Ainsi, ce sont ces résultats obtenus qui doivent être comparés dans le temps afin de déterminer l'impact d'une modification sur le bout de code à surveiller (en terme de performance).

Conclusion

Ainsi, vous l'aurez compris (enfin j'espère ;-) ), Le microbenchmark est un exercice bien plus complexe qu'il en a l'air et il ne suffit pas d'ouvrir son eclipse et de jeter trois lignes de code dans un main(). Bien sûr, cela permet de se donner un ordre de grandeur mais qui est souvent non représentatif de la réalité et dont le comportement sera, presque à coup sûr, différent dans son contexte d'exécution de ce qui est observé dans son main().

Cependant, il faut garder à l'esprit qu'il reste fortement déconseillé de tenter d'optimiser son code au risque de faire pire que mieux et surtout de rendre son code illisible et donc immaintenable.

Du coup (et toujours d'après Joshua Bloch) :

Si vous êtes développeur, utiliser les librairies high-level et déléguer les problématiques de performances aux couches inférieures (inférieures au sens géographique du terme bien sûr! ;-) ). Même si cela peut être dur à admettre, accepter de ne pas savoir et de ne pas pouvoir prédire les performances de votre code.
Si vous êtes développeur de librairies, langages, frameworks ou de JVM, alors il faut apprendre à éviter les sources d'étonnement en s'appuyant sur des bonnes pratiques de développement (comme privilégier l'accès aux variables d'instances en jouant sur le niveau de visibilité plutôt que d'utiliser des getter/setter, ...) mais surtout mesurer constamment (tel que cela a été décrit) et faire des statistiques pour déterminer le comportement global au niveau performance.
Si vous êtes un ayatolla (comme Doug Lea ou Cliff Dick), alors il faut prêcher la bonne parole autour de vous pour éviter les écueils dans lesquels il ne faut pas tomber.

Bien sûr (et cela conclura cet article), il faut garder à l'esprit qu'une optimisation ne s'applique potentiellement qu'à une famille de processeurs, VM ou architecture matérielle, et qu'au vu de la difficulté de prédire de quoi seront constitués nos ordinateurs de demain ou de prédire des optimisations qu'apporteront nos prochaines JVM, tout le travail effectué à l'instant t risque d'être totalement obsolète et erroné demain!

Pour aller plus loin...

Présentation de Joshua Bloch sur Parleys : http://www.parleys.com/#sl=0&st=5&id=2103
Site du framework Caliper : http://code.google.com/p/caliper/
Présentation de Cliff Click : http://www.azulsystems.com/events/javaone_2009/session/2009_J1_Benchmark.pdf
Page Wiki de Sun sur le microBenchmark : http://wikis.sun.com/display/HotSpotInternals/MicroBenchmarks
Page de google Android sur la gestion des perfomances d'Android : http://developer.android.com/guide/practices/design/performance.html
Blog de Peter Ahé sur les compilateurs Java : http://blogs.sun.com/ahe/entry/hotspot_and_other_compilers

Pour les gouverner tous - partie 3/3

2011-02-24T23:46:00.003+01:00

Cet article fait suite à mes précédents posts (ici et là) et à pour objectif d'intégrer la partie JMX à mon petit POC JGroups afin d'offrir une solution permettant de rendre complètement scalable la partie supervision/administration par JMX d'une application distribuée (ie. d'aggréger tous les MBeans au sein de tous les serveurs JMX). Pour rappel, le post précédent introduisait JGroups dans une petite application qui permettait à chaque instance d'une application d'obtenir la valeur d'une donnée offerte par les autres instances.

Expression du besoin et conception

Comme je l'ai expliqué ici, le principe est simple : en démarrant son application qui aura à sa charge d'appeler un petit bout de code de notre toolkit, tous les MBeans se trouvant sur les autres serveurs JMX (modulo que l'application qui les ait démarrés ait démarré en instanciant notre toolkit) doivent être remonter dans notre serveur JMX courant. Réciproquement, tous les MBeanServer devront enregistrer les MBeans offerts par notre instance d'application.

Pour ce faire, notre toolkit gérera la partie JMX, c'est-à-dire qu'il créera un connecteur JMX serveur (connecteur s'appuyant sur le protocole RMI) permettant d'accéder au MBeanServer courant (ie. il utilisera le MBeanServer s'il en existe un ou, dans le cas échéant, il en créera un) et qu'il l'exposera aux autres instances en fournissant un stub de la partie connecteur JMX cliente. Ce stub permettra aux autres instances d'instancier la couche de communication nécessaire vers le MBeanServer cible. C'est ce stub qui sera transmis par JGroups (et qui remplacera donc la donnée partagée de notre POC JGroups).

Ca va? Tout le monde suit? Bon, on va pouvoir accélérer... ;-)

Ainsi, lorsqu'une nouvelle instance sera démarrée dans le système, les instances déjà présentes seront notifiées de l'arrivé d'un nouveau membre dans la vue (concepts JGroups et cf. post précédent). Suite à cela, elles récupèreront le stub du JMXConnector du nouveau MBeanServer (toujours cf. post précédent) qui leur permettra de créer un proxy dynamique correspondant aux MBeans présents dans le MBeanServer cible. Ce proxy dynamique sera instancié et enregistré comme étant un nouveau MBean dans le MBeanServer de l'instance courante.

Cependant, ce proxy dynamique ne pourra pas être utilisé directement (sinon ça serait trop simple). En effet, la méthode statique JMX.newMBeanProxy() permet de créer un proxy dynamique du MBean standard d'un MBeanServer distant ou local. Cependant, il n'est pas possible de l'enregistrer comme MBean au sein d'un MBeanServer car il ne répond alors pas à la règle : "un MBean doit implémenter une interface de type MBean ou DynamicMBean". Aussi, la solution retenue a été de wrapper ce proxy dynamique dans un MBean dynamique. Ce wrapper fera donc passe-plat (en utilisant la réflexion) avec le proxy dynamique récupéré par la méthode JMX.newMBeanProxy() lors de l'invocation d'opérations dessus (pour ce faire, il s'appuiera sur les normes spécifiées par JMX pour l'accès en lecture/écriture aux variables d'instance).

En outre, pour le cas spécifique des MXBeans (un certain nombre de MXBean est spécifié par JMX : http://download.oracle.com/javase/6/docs/api/), un traitement particulier sera effectué. En effet, JMX offre la possibilité de créer directement un proxy de l'interface d'un MXBean donné via la méthode statique ManagementFactory.newPlatformMXBeanProxy(). Aussi, pour les MXBeans, notre wrapper ne sera pas utilisé puisqu'il est possible d'enregistrer directement au sein de notre MBeanServer courant le MXBean distant.

Bien sûr, encore une fois, cela aurait été trop simple s'il n'y avait pas un mais... ;-) En effet, la spécification JMX précise qu'il est possible d'avoir plusieurs MXBeans de type MemoryPoolMXBean, MemoryManagerMXBean et GarbageCollector (cf. http://download.oracle.com/javase/6/docs/api/). Dans ces cas précis, ce sont les propriétés de ces MXBeans qui permettent de les différencier : un traitement particulier sera donc effectué dans ces cas précis puisqu'une recherche pour décrouvrir les propritétés du MXBean sera faite.

En outre, un cas particulier lié à la JRE 6 de Sun (Hostpot) a, ici, été traité (du coup, cela rend le code proposé adhérent à notre jdk...) puisque le MXBean HotpostDiagnostic a fait l'objet d'une attention particulière...

Mise en oeuvre

Intégration de JMX

Note : à noter que le code présenté dans cet article comporte quelques raccourcis et n'a pour objectif que de montrer les points clé. Aussi, certaines portions (comme, entre autre, la gestion des threads, des exceptions ou les méthodes equals(), hashCode() ou toString()) ne sont pas présentes par soucis de clarté. Le code complet peut être trouvé sur GitHub : https://github.com/jetoile/jmanager4all.

Ici, la donnée, traduite par la classe Data dans mon article précédent, sera remplacée par le stub au JMXConnector. Ce stub sera créé par la classe utilisée pour instancier les objets nécessaires à la bonne initalisation du toolkit et il sera encapsulé dans la classe JManagerConnector (à noter, bien sûr que la classe RMIConnector (implémentation de l'interface JMXConnector) utilisée ici est sérialisable) lors de sa transmission entre les différentes instances de l'application.

public class JManagerConnector implements Serializable {
 private String location;
 private JMXConnector connector;

 public JManagerConnector() {
 }

 public String getLocation() {
  return location;
 }

 public void setLocation(final String location) {
  this.location = location;
 }

 public JMXConnector getConnector() {
  return connector;
 }

 public void setConnector(final JMXConnector connector) {
  this.connector = connector;
 }
}

Du point de vue création des objets JMX exposés (ie. le JMXConnector et son stub) et de l'initialisation de ces derniers (ie. démarrage du connecteur), cela sera fait, comme dit précédemment, par notre classe qui nous servira de point d'entrée à notre toolkit JManager4All :

public class JManager4All {

    final static private Logger LOGGER = LoggerFactory.getLogger(JManager4All.class);

    private static final String CONNECTOR_PROTOCOL = "rmi";

    private JMXConnectorServer jmxConnector;
    private JMXServiceURL jmxServiceUrl;
    final private JManagerConnector jmanagerConnector = new JManagerConnector();
    private final MBeanServer mBeanServer;
    final private JMXConnectorStubCache connectorsStub = new JMXConnectorStubCache();

    private JGroupsBindingComponent jmanagerBindingComponent;
    public JManager4All(final int port) {
        try {
            this.jmxServiceUrl = new JMXServiceURL(CONNECTOR_PROTOCOL, null, port);
        } catch (MalformedURLException e) {
            LOGGER.error("unable to create JMXServiceURL: {}", e);
        }
        this.mBeanServer = ManagementFactory.getPlatformMBeanServer();
        init();
    }

    private void init() {
        try {
            this.jmxConnector = JMXConnectorServerFactory.newJMXConnectorServer(this.jmxServiceUrl, null, mBeanServer);
            this.jmxConnector.start();

            final ObjectName objectName = new ObjectName(":type=csserver, name=csserver");
            mBeanServer.registerMBean(this.jmxConnector, objectName);
            this.jmanagerConnector.setConnector(this.jmxConnector.toJMXConnector(null));

            this.jmanagerBindingComponent = new JGroupsBindingComponent(this.jmanagerConnector);
            this.jmanagerBindingComponent.setConnectorsStub(this.connectorsStub);
        } catch (Exception e) {
            LOGGER.error("unable to init: {}", e);
        }
    }

    public void stop() throws IOException {
        this.jmxConnector.stop();
        this.jmanagerBindingComponent.stop();
    }

    public void start() {
        this.jmanagerBindingComponent.start();
    }

    public JManagerConnector getStubConnector() {
        return this.jmanagerConnector;
    }
}

On remarquera également que cette classe instancie et démarre une instance d'un JGroupsBindingComponent qui s'occupe de la couche communication pour récupérer nos stubs du système (ici, ça sera JGroups). Je ne reviendrai pas sur les détails d'implémentation de cette partie puisque cela a déjà été traité ici.

A noter également que nos stubs seront conservés dans un cache JMXConnectorStubCache qui déclenchera, lorsqu'un élément (ie. un stub d'un JMXConnector) sera ajouté ou supprimé, la récupération de nos MBean distant et leur enregistrement au sein du MBeanServer courant (resp. leur suppression).

public class JMXConnectorStubCache implements Serializable {

 volatile private Map<JManagerAddress, JMXConnector> connectorsStub = Collections.synchronizedMap(new HashMap<JManagerAddress, JMXConnector>());

 synchronized public Map<JManagerAddress, JMXConnector> getValue() {
  return this.connectorsStub;
 }

 synchronized public JMXConnector put(JManagerAddress key, JMXConnector value) {
  JMXConnector result = this.connectorsStub.put(key, value);
  MBeanHandler mBeanHandler = new MBeanHandler(key, value);
  mBeanHandler.handleAdd();
  return result;
 }

 synchronized public JMXConnector remove(JManagerAddress key) {
  JMXConnector result = this.connectorsStub.remove(key);
  MBeanHandler mBeanHandler = new MBeanHandler(key, result);
  mBeanHandler.handleRemove();
  return result;
 }
}

Ce dernier point nous amène au paragraphe suivant, à savoir la récupération des MBeans distants et leur enregistrement.

Récupération des MBeans distants et enregistrement

La récupération des MBeans distants est globalement simple et suit le schéma suivant (cet algorithme ne s'applique pas aux MXBeans) :

à partir du JMXConnector client, récupération du MBeanServerConnection,
à partir du MBeanServerConnection, une recherche est lancée sur le MBeanServer distant pour récupérer l'ensemble des ObjectInstance présenst sur ce dernier,
pour chaque ObjectInstance qui n'est pas dans le domaine JMX "remote" (qui sera le domaine utilisé pour stocker les proxy des MBeans distants), création d'un proxy dynamique représentant l'objet exposé par le MBean et encapsulation de ce dernier dans la classe MBeanWrapper qui est un DynamicMBean,
enfin enregistrement de chaque DynamicMBean créé dans le MBeanServer local via un ObjectName défini grâce à :
- ses propriétés,
- son domaine JMX distant sous forme de propriété "subdomain",
- mais également avec une propriété permettant de connaitre la provenance du MBean (propriété qui sera appelée "instance").

public class MBeanHandler {
 private static final String DOMAIN_REMOTE = "remote";

 private static final Logger LOGGER = LoggerFactory.getLogger(MBeanHandler.class);

 private final MBeanServer mbeanServer = ManagementFactory.getPlatformMBeanServer();
 private final JMXConnector connector;
 private final JManagerAddress address;

 public MBeanHandler(final JManagerAddress address, final JMXConnector connector) {
  this.connector = connector;
  this.address = address;
 }

 void handleAdd() throws Exception {
  if (connector != null) {
   connector.connect();
   ObjectName objectName = new ObjectName("*:*");
   final MBeanServerConnection mBeanServerConnection = connector.getMBeanServerConnection();

   final Set<ObjectInstance> instances = mBeanServerConnection.queryMBeans(objectName, null);

   for (ObjectInstance objectInstance : instances) {
    final ObjectName distantObjectName = objectInstance.getObjectName();
    if (DOMAIN_REMOTE.equals(distantObjectName.getDomain())) {
     continue;
    }
    final ObjectName newObjectName = new ObjectName(DOMAIN_REMOTE + ":instance=" + address + ", " + "subdomain=" + distantObjectName.getDomain()
      + ", " + distantObjectName.getKeyPropertyListString());
    final MBeanInfo mBeanInfo = mBeanServerConnection.getMBeanInfo(distantObjectName);
    registerRemoteMBean(mBeanServerConnection, distantObjectName, newObjectName, mBeanInfo);
   }
  }
 }

 private void registerRemoteMBean(final MBeanServerConnection mBeanServerConnection, final ObjectName distantObjectName, final ObjectName newObjectName,
   final MBeanInfo mBeanInfo) throws Exception {
  Object mBean = getRemoteMBean(mBeanServerConnection, mBeanInfo, distantObjectName);
  if (mBean != null) {
   mbeanServer.registerMBean(mBean, newObjectName);
  }
 }

 public Object getRemoteMBean(final MBeanServerConnection mBeanServerConnection, final MBeanInfo mBeanInfo, final ObjectName distantObjectName)
   throws Exception {
  if (!Boolean.parseBoolean((String) mBeanInfo.getDescriptor().getFieldValue("mxbean"))) {
   LOGGER.debug("current mxBeanInfo : {}", mBeanInfo);
   final Class<?> clazz = Class.forName(mBeanInfo.getClassName());
   final Class<?>[] interfazes = clazz.getInterfaces();
   if (interfazes.length == 1) {
    LOGGER.debug("current interface : {}", interfazes[0]);
    final Object proxy = JMX.newMBeanProxy(mBeanServerConnection, distantObjectName, interfazes[0]);
    final MBeanWrapper mBeanWrapper = new MBeanWrapper(mBeanInfo, proxy);
    return mBeanWrapper;
   }
  }
  return null;
 }
}

public class MBeanWrapper implements DynamicMBean {

 static final private Logger LOGGER = LoggerFactory.getLogger(MBeanWrapper.class);

 private final MBeanInfo mBeanInfo;
 private final Object proxy;

 public MBeanWrapper(final MBeanInfo mBeanInfo, final Object proxy) {
  this.mBeanInfo = mBeanInfo;
  this.proxy = proxy;
 }

 @Override
 public Object getAttribute(String attribute) throws AttributeNotFoundException, MBeanException, ReflectionException {
  MBeanAttributeInfo[] mBeanAttributeInfos = mBeanInfo.getAttributes();
  for (MBeanAttributeInfo mBeanAttributeInfo : mBeanAttributeInfos) {
   if (StringUtils.equals(attribute, mBeanAttributeInfo.getName())) {
    if (mBeanAttributeInfo.isReadable()) {
     return invokeGetter(attribute, mBeanAttributeInfo);
    } else {
     return null;
    }
   }
  }
  return null;
 }

 Object invokeGetter(String attribute, MBeanAttributeInfo mBeanAttributeInfo) {
  try {
   Method method = null;
   if (mBeanAttributeInfo.isIs()) {
    method = this.proxy.getClass().getMethod("is" + StringUtils.capitalize(attribute), new Class[0]);
    return method.invoke(this.proxy, new Object[0]);
   } else {
    method = this.proxy.getClass().getMethod("get" + StringUtils.capitalize(attribute), new Class[0]);
    return method.invoke(this.proxy, new Object[0]);
   }
  } catch (Exception e) {
   LOGGER.error("unable to get remote attribute info {}: {}", attribute, e);
  }
  return null;
 }

 @Override
 public void setAttribute(Attribute attribute) throws AttributeNotFoundException, InvalidAttributeValueException, MBeanException, ReflectionException {
  MBeanAttributeInfo[] mBeanAttributeInfos = mBeanInfo.getAttributes();
  for (MBeanAttributeInfo mBeanAttributeInfo : mBeanAttributeInfos) {
   if (StringUtils.equals(attribute.getName(), mBeanAttributeInfo.getName())) {
    if (mBeanAttributeInfo.isWritable()) {
     invokeSetter(attribute, mBeanAttributeInfo);
    } else {
     return;
    }
   }
  }
  return;
 }

 void invokeSetter(Attribute attribute, MBeanAttributeInfo mBeanAttributeInfo) {
  try {
   Method method = null;
   if (mBeanAttributeInfo.isIs()) {
    method = this.proxy.getClass().getMethod("set" + StringUtils.capitalize(attribute.getName()), boolean.class);
    method.invoke(this.proxy, attribute.getValue());
   } else {
    method = this.proxy.getClass().getMethod("set" + StringUtils.capitalize(attribute.getName()), attribute.getValue().getClass());
    method.invoke(this.proxy, attribute.getValue());
   }
  } catch (Exception e) {
   LOGGER.error("unable to set remote attribute info {}: {}", attribute, e);
  }
 }

 @Override
 public AttributeList getAttributes(String[] attributes) {
  AttributeList result = new AttributeList();
  for (String attribute : attributes) {
   Attribute currentAttribute;
   try {
    currentAttribute = new Attribute(attribute, getAttribute(attribute));
    result.add(currentAttribute);
   } catch (Exception e) {
    LOGGER.error("unable to get remote attribute info {}: {}", attribute, e);
   }
  }
  return result;
 }

 @Override
 public AttributeList setAttributes(AttributeList attributes) {
  AttributeList result = new AttributeList();
  for (int i = 0; i < attributes.size(); i++) {
   Attribute attribute = (Attribute) attributes.get(i);
   try {
    setAttribute(attribute);
    result.add(attribute);
   } catch (Exception e) {
    LOGGER.error("unable to set remote attribute {}: {}", attribute.getName(), e);
   }
  }
  return result;
 }

 @Override
 public Object invoke(String actionName, Object[] params, String[] signature) throws MBeanException, ReflectionException {
  Class[] paramTypes = null;
  if (signature != null) {
   paramTypes = new Class[signature.length];
   for (int i = 0; i < signature.length; ++i) {
    paramTypes[i] = signature[i].getClass();
   }
  }

  try {
   Method method = this.proxy.getClass().getMethod(actionName, paramTypes);
   return method.invoke(this.proxy, params);
  } catch (Exception e) {
   LOGGER.error("unable to invoke {}: {}", actionName, e);
  }
  return null;
 }

 @Override
 public MBeanInfo getMBeanInfo() {
  return this.mBeanInfo;
 }
}

On voit donc que le processus n'est pas vraiment compliqué. Pour le cas des MXBeans, cela est un peu plus sioux... mais globalement pas compliqué non plus ;-)

En effet, plusieurs cas se présentent :

Pour les MXBeans de types (type au sens propriété JMX) Compilation, ClassLoading, Memory, OperationSystem, Runtime et Threading, cela ne pose pas de problèmes puisque la spécification JMX nous dit qu'il n'y a qu'un seul MBean de ce type dans le MBeanServer pour domaine java.lang. Dans ce cas, il suffit juste d'instancier un proxy dynamique du MXBean lui-même et de l'enregistrer avec le "bon" ObjectName.
par contre, pour les MXBeans de types MemoryPool, GarbageCollector et MemoryManager, vu qu'il peut y en avoir plusieurs, une recherche est effectuée (en limitant la recherche aux MBeans voulus bien sûr...) sur le MBeanServer distant afin d'obtenir (mais également d'instancier) le bon type de proxy dynamique mais également les bonnes propriétés sous lequel il est enregistré.

final private static Map<String, Class<?>> MXBEAN_MAP = new HashMap<String, Class<?>>();
 static {
  MXBEAN_MAP.put(ManagementFactory.COMPILATION_MXBEAN_NAME, CompilationMXBean.class);
  MXBEAN_MAP.put(ManagementFactory.CLASS_LOADING_MXBEAN_NAME, ClassLoadingMXBean.class);
  MXBEAN_MAP.put(ManagementFactory.MEMORY_MXBEAN_NAME, MemoryMXBean.class);
  MXBEAN_MAP.put(ManagementFactory.OPERATING_SYSTEM_MXBEAN_NAME, OperatingSystemMXBean.class);
  MXBEAN_MAP.put(ManagementFactory.RUNTIME_MXBEAN_NAME, RuntimeMXBean.class);
  MXBEAN_MAP.put(ManagementFactory.THREAD_MXBEAN_NAME, ThreadMXBean.class);
  MXBEAN_MAP.put("java.util.logging:type=Logging", LoggingMXBean.class);
 }

 public RemoteMXBeanHandler() {
 }

 public Object getRemoteMBean(final MBeanServerConnection mBeanServerConnection, final MBeanInfo mBeanInfo, final ObjectName distantObjectName)
   throws Exception {
  if (Boolean.parseBoolean((String) mBeanInfo.getDescriptor().getFieldValue("mxbean"))) {
   LOGGER.debug("current mxBeanInfo : {}", mBeanInfo);
   Object proxy = getMxBeanProxy(mBeanServerConnection, mBeanInfo, distantObjectName);
   return proxy;
  }
  return null;
 }

 private Object getMxBeanProxy(final MBeanServerConnection mBeanServerConnection, final MBeanInfo mBeanInfo, final ObjectName distantObjectName)
   throws IOException {
  String distantName = distantObjectName.toString();
  int index = distantName.indexOf(",");
  String substring = distantName.substring(0, (index != -1) ? index : distantName.length());
  Class<?> mBeanClass = MXBEAN_MAP.get(substring);
  if (mBeanClass != null) {
   return ManagementFactory.newPlatformMXBeanProxy(mBeanServerConnection, distantName, mBeanClass);
  } else if (!StringUtils.equals(ManagementFactory.MEMORY_POOL_MXBEAN_DOMAIN_TYPE, substring)
    && !StringUtils.equals(ManagementFactory.GARBAGE_COLLECTOR_MXBEAN_DOMAIN_TYPE, substring)
    && !StringUtils.equals(ManagementFactory.MEMORY_MANAGER_MXBEAN_DOMAIN_TYPE, substring)
    && !StringUtils.contains(substring, "com.sun.management")) {
   return ManagementFactory.newPlatformMXBeanProxy(mBeanServerConnection, ManagementFactory.RUNTIME_MXBEAN_NAME, RuntimeMXBean.class);
  } else {
   return null;
  }
 }

 private void handleSpecificMXBean(final MBeanServerConnection mBeanServerConnection) throws Exception {
  // cf. http://download.oracle.com/javase/6/docs/api/

  // traitement particulier pour les MXBeans de type MemoryPoolMXBean
  registerOtherMxBean(mBeanServerConnection, ManagementFactory.MEMORY_POOL_MXBEAN_DOMAIN_TYPE, MemoryPoolMXBean.class);
  // traitement particulier pour les MXBeans de type MemoryManagerMXBean
  registerOtherMxBean(mBeanServerConnection, ManagementFactory.MEMORY_MANAGER_MXBEAN_DOMAIN_TYPE, MemoryManagerMXBean.class);
  // traitement particulier pour les MXBeans de type GarbageCollector
  registerOtherMxBean(mBeanServerConnection, ManagementFactory.GARBAGE_COLLECTOR_MXBEAN_DOMAIN_TYPE, GarbageCollectorMXBean.class);

  // traitement particulier pour les MXBeans de type Hotspot
  registerOtherMxBean(mBeanServerConnection, "com.sun.management:type=HotSpotDiagnostic", HotSpotDiagnosticMXBean.class);
 }

 private void registerOtherMxBean(final MBeanServerConnection mBeanServerConnection, String type, Class<?> clazz) throws Exception {
  final ObjectName requestedObjectName = new ObjectName(type + ",*");
  final Set<ObjectName> objectNames = mBeanServerConnection.queryNames(requestedObjectName, null);
  for (ObjectName objectName : objectNames) {
   final Object proxy = ManagementFactory.newPlatformMXBeanProxy(mBeanServerConnection, objectName.getCanonicalName(), clazz);
   final ObjectName newObjectName = new ObjectName("remote:instance=" + address + ", " + "subdomain=" + objectName.getDomain() + ", "
     + objectName.getKeyPropertyListString());
   mbeanServer.registerMBean(proxy, newObjectName);
  }
 }

Pour le cas particulier du MXBean HotspotDiagnostic, je vous laisse le soin de jeter un oeil sur le code... ;-)

Désenregistrement d'une instance (et donc de ses MBeans associés)

Bien entendu, si une instance venait à disparaitre, il est nécessaire de désenregistrer ses MBeans pour chaque instance de l'application encore présente.

Là encore, la principe est ultra-simple puisqu'il suffit de récupérer l'ensemble des MBeans qui se trouvent dans le domaine JMX "remote" (qui pour rappel est le domaine utilisé pour enregistrer tous nos proxy) avec la "bonne" propriété (à savoir la propriété "instance" qui doit valoir la valeur de l'adresse de l'instance à supprimer) et de les désenregistrer du MBeanServer local.

void handleRemove() throws Exception {
  final ObjectName queryObjectName = new ObjectName(DOMAIN_REMOTE + ":instance=" + address + ",*");
  final Set<ObjectName> objectNames = mbeanServer.queryNames(queryObjectName, null);
  for (ObjectName objectName : objectNames) {
   LOGGER.debug("remove from mBeanServer objectName : {}", objectName);
   mbeanServer.unregisterMBean(objectName);
  }
 }

Conclusion

On a vu tout au long de cette article comment il était possible d'utiliser JMX coté client (on récupère des MBeans distants) mais également coté serveur (on créé des MBeans). Bien sûr, la couche JGroups n'est qu'un prétexte mais je trouvais intéressant de pouvoir s'appuyer sur ce dernier pour être notifié de changement dans le système. Si je suis motivé, j'intégrerais peut être une implémentation NoSQL pour stocker et partager les JMXConnector ou un truc du genre... ;-)

Par contre, je n'ai pas testé le comportement dans le cas où des notifications seraient émises... en outre, si un service de Relation JMX était utilisé, je pense que cela pourrait poser quelques soucis...

A noter que je suis tombé tout récemment sur une autre solution (que je n'ai pas testé) qui permet d'aggréger des informations JMX au sein d'un même serveur MBeanServer. La cible n'est pas tout à fait identique mais peut être suffisante pour la plupart des cas... par contre, il faut aimer Spring... ;-)

Pour aller plus loin...

Site officiel de JGroups : http://www.jgroups.org/
Wiki de JGroups : http://community.jboss.org/wiki/JGroups

Site de la JSR 3 - Java Management Extensions (JMX) Specification : http://www.jcp.org/en/jsr/detail?id=3
Site de la JSR 160 - Java Management Extensions (JMX) Remote API : http://jcp.org/en/jsr/detail?id=160
Site officiel d'Oracle sur JMX : http://www.oracle.com/technetwork/java/javase/tech/docs-jsp-135989.html

Pour les gouverner tous - partie 2/3

2011-02-20T18:44:00.002+01:00

Cet article fait suite à mon article précédent et a pour objectif de présenter un petit POC (Proof Of Concept) simplicime mettant en oeuvre JGroups en version 2.11.0.GA (la dernière version stable à ce jour). Le principe est de montrer comment il est possible d'utiliser JGroups pour permettre à plusieurs instances d'une même application de se partager les valeurs d'une donnée. Enfin, pour être plus précis, cet objet partagé ne le sera pas vraiment (ndlr : partagé) par toutes les instances mais il s'agira plutôt de permettre à chaque nouvelle instance de récupérer la valeur d'une donnée auprès des autres instance déjà présentes dans le système. En outre, les autres instances déjà présentes devront recevoir directement la valeur de la donnée de la nouvelle instance.

L'autre raison d'être de cet article permettra d'introduire la couche protocolaire utilisée par mon petit POC qui permet de rendre distribuable un agent JMX dans une architecture distribuée.

Spécification des besoins/pré-requis

Ce projet s'appuiera sur les pré-requis suivant :

slf4j/logback pour la partie log
maven 3 (ou 2 au choix) pour la partie build
et... JGroups dans sa version 2.11.0.GA ;-)

Coté tests unitaires, je m'excuse préalablement auprès de vous, mais il n'y en aura pas... et cela pour deux raisons que je vous laisse choisir :

je suis flemmard ;-) mais surtout, je n'ai pas envie de mocker la terre entière.
ce petit programme est plus une utilisation basique de JGroups et, le produit fonctionnant bien, je ne vois pas l'intérêt de le retester. En outre, ici, il est plus intéressant de tester de manière intégrée que de manière unitaire en raison de l'aspect distribué de l'application.

Comme je l'ai mentionné précédemment dans l'introduction, le but de cet article est simple : une application dispose de plusieurs instances qui se trouvent sur des JVM distinctes (il peut donc s'agir d'instances exécutées sur une ou plusieurs machines).

Si une nouvelle instance est démarrée, elle doit pouvoir demander à toutes les autres instances de l'application la valeur d'une donnée X afin, par exemple, de connaître leur état.
De plus, toutes les instances déjà existantes dans le système doivent pouvoir être notifiées de l'arrivée d'une nouvelle instance et, par la même occasion, recevoir sa valeur courante de la donnée X.
Enfin, si une instance disparait du sytème (arrêt, ...), toutes les instances doivent automatiquement supprimer en leur sein la valeur de la donnée de l'instance incriminée.

Coté configuration de JGroups, cet article s'appuiera sur une configuration par défaut, c'est à dire une configuration en UDP.

Architecture de l'application

Comme vous pouvez vous en douter, l'architecture de l'application sera simple puisque JGroups fournit nativement de nombreuses possibilités. Aussi, je ne présenterai pas de super conception.

Par contre, si les termes ReceiverAdapter, MembershipListener ou View ne vous parlent pas, je vous renverrai :

soit, à mon article sur JGroups ;-)
soit (mieux), à la documentation officielle de ce dernier.

Notre application sera composée de trois parties :

La partie donnée : la classe Data représentera la donnée à faire transiter. Il s'agira d'un simple POJO qui sera, bien sûr, sérialisable.
La partie notification de changement de l'infrastructure (ie. arrivé ou arrêt d'une instance dans le système) : la classe ChangeInfraListener qui implémentera l'interface MembershipListener et donc la méthode viewAccepted() call-backé par JGroups pour notifier d'un changement au niveau d'une des ses vues.
La partie qui aura à sa charge l'exposition de la donnée représentée par la classe Data et qui aura initialisera l'application : la classe JGroupsClient qui étendra la classe ReceiverAdapter afin de permettre aux autres instances d'interargir avec.

Coté canaux, l'application en utilisera un seul canal : le canal "channel" qui sera utilisé pour être être notifié de changement d'état sur la vue (il sera donc connecté à la classe implémentant l'interface MembershipListener (ie. ChangeInfraListener) et qui sera également utilisé pour la communication point à point entre les différentes instances : pour rappel, à un membre d'une vue est associée une adresse unique et une vue contient l'ensemble des membres de cette dernière.

A noter que pour la récupération de la donnée au démarrage d'une instance, il aurait également été possible d'implémenter les méthodes getState() et setState() (en combinaison de l'utilisation de la méthode connect(<String> , <Address>, <String>, <long>) sur l'instance de Channel utilisée). Cependant, il était, quand même nécessaire d'implémenter la méthode viewAccepted() afin d'être notifié du démarrage ou de l'arrêt d'une instances dans le système et cela aurait été redondant avec les notifications reçues (en effet, récupérer l'état des autres instances des membres de la vue ne dispense pas de recevoir l'état de la vue via la méthode viewAccepted()). Aussi, je n'ai pas utilisé cette fonctionnalité de JGroups.

Diagramme de séquence lors de la connexion d'une nouvelle instance de l'application au système, coté nouvelle instance mais aussi coté instances déjà présentes dans le système :

Mise en oeuvre

A noter que le code écrit ici ne contiendra pas les imports par souci de lisibilité.

La classe JGroupsClient

Commençons donc par la mise en oeuvre de la classe JGroupsClient :

package com.jetoile.jgroups.sample;
public class JGroupsClient extends ReceiverAdapter {

    final static private Logger LOGGER = LoggerFactory.getLogger(JGroupsClient.class);

    final private Data data = new Data();
    private RpcDispatcher rpcDispatcher;
    private Channel channel;

    public JGroupsClient(final String data) {
        this.data.setData(data);
    }

    public void stop() throws IOException {
        this.channel.close();
    }

    public void start() throws ChannelException {
        this.channel = new JChannel("default-udp.xml");

        final ChangeInfraListener changeSetListener = new ChangeInfraListener(channel);
        rpcDispatcher = new RpcDispatcher(this.channel, null, changeSetListener, this);
        changeSetListener.setRpcDispatcher(rpcDispatcher);
        this.channel.connect("privateChannel");
        this.data.setAddress(this.channel.getAddress());
    }

    public Data getData() {
        return this.data;
    }
}

Dans cette classe, on observe donc que l'on a :

la méthode start() qui a à sa charge la partie connexion à JGroups,
la méthode getData() qui correspond à la méthode exposée utilisée pour transmettre la valeur de la donnée aux autres instances.

La classe ChangeInfraListener

Pour la classe ChangeInfraListener, nous aurons :

package com.jetoile.jgroups.sample;

public class ChangeInfraListener implements MembershipListener {

    final static private Logger LOGGER = LoggerFactory.getLogger(ChangeInfraListener.class);

    final private Map<Address, String> dataCache = new HashMap<Address, String>();

    final private Channel privateChannel;

    private RpcDispatcher rpcDispatcher;

    public ChangeInfraListener(final Channel privateChannel) {
        this.privateChannel = privateChannel;
    }

    public void setRpcDispatcher(RpcDispatcher rpcDispatcher) {
        this.rpcDispatcher = rpcDispatcher;
    }

    @Override
    public void viewAccepted(View new_view) {
        // when a new member is up
        List<Address> newAddresses = getNewAddresses(new_view.getMembers());

        newAddresses.remove(privateChannel.getAddress());

        List<Address> ads = new ArrayList<Address>();
        for (Address ad : newAddresses) {
            if (!dataCache.containsKey(ad)) {
                ads.add(ad);
            }
        }

        if (!ads.isEmpty()) {
            MethodCall methodCall = new MethodCall("getData", new Object[] {}, new Class[] {});
            LOGGER.debug("invoke remote getData on: {}", ads);

            RspList resps = rpcDispatcher.callRemoteMethods(ads, methodCall, RequestOptions.SYNC);
            LOGGER.debug("after invoke getData - nb result {}", resps.numReceived());

            if (resps.numReceived() == 0) {
                LOGGER.debug("retry...");
                resps = rpcDispatcher.callRemoteMethods(ads, methodCall, RequestOptions.SYNC);
            }

            for (Object resp : resps.getResults()) {
                Data data = (Data) resp;
                LOGGER.debug("new data: {}", data);
                dataCache.put(data.getAddress(), data.getData());
            }
        }

        List<Address> olds = getObsoleteAddresses(new_view.getMembers());
        for (Address old : olds) {
            LOGGER.debug("remove data: {}", old);
            dataCache.remove(old);
        }
    }

    @Override
    public void suspect(Address suspected_mbr) {
        // NOTHING TO DO
    }

    @Override
    public void block() {
        // NOTHING TO DO
    }

    List<Address> getNewAddresses(Vector<Address> newMembers) {
        List<Address> result = new ArrayList<Address>();
        for (Address address : newMembers) {
            if (!this.dataCache.containsKey(address)) {
                result.add(address);
            }
        }
        return result;
    }

    List<Address> getObsoleteAddresses(Vector<Address> newMembers) {
        List<Address> result = new ArrayList<Address>();
        for (Address address : this.dataCache.keySet()) {
            if (!newMembers.contains(address)) {
                result.add(address);
            }
        }
        return result;
    }
}

Dans cette classe, on observe que la méthode viewAccepted() (qui est la méthode call-backé par JGroups lors d'une modification de la vue (ie. lors de la connexion ou de la déconnexion d'un autre membre du groupe)), invoque, si un nouveau membre est apparu, l'appel de la méthode distante getData() sur la nouvelle instance en question.

Il est intéressant de noter l'utilisation qui est faite de la classe RequestOptions mais également le fait que les méthode block() et suspect() n'ont pas été spécifiées dans notre cas d'utilisation.

La classe Data

Enfin, la classe Data qui sera utilisée est la suivante (par souci de lisibilité, les méthodes equals() et hashCode() ne sont pas détaillées ici) :

package com.jetoile.jgroups.sample;

public class Data implements Serializable {
 private Address address;
 private String data;

 public Data() {
 }

 public Address getAddress() {
  return address;
 }

 public void setAddress(final Address address) {
  this.address = address;
 }

 public String getData() {
  return data;
 }

 public void setData(String data) {
  this.data = data;
 }

 @Override
 public int hashCode() {
  // cf. gitHub
  return 0;
 }

 @Override
 public boolean equals(Object obj) {
  // cf. gitHub
  return true;
 }

 @Override
 public String toString() {
  return "Data [address=" + address + ", data=" + data + "]";
 }
}

Cette classe, comme on peut le remarquer, n'a rien de particulier, si ce n'est qu'elle est sérialisable.

Ainsi, on peut voir que l'implémentation est très simple (je ne commenterai donc pas ce qui est fait ici...).

Exécution et utilisation

L'exécution, quant à elle, pourra se faire avec une classe de type :

package com.jetoile.jgroups.sample.sample;

public class JGroupsClientTest {

 public static void main(String[] args) throws ChannelException {
  JGroupsClient jgroupsClient = new JGroupsClient("toto");
  jgroupsClient.start();
 }
}

A noter que si les différentes instances venaient à ne pas se voir, cela peut provenir d'un souci avec la configuration réseau et qu'il est possible de palier à ce problème en forçant l'utilisation d'adresse IPV4 avec l'option JVM suivante :

-Djava.net.preferIPv4Stack=true

Conclusion

On a vu ici que permettre la communication d'instances d'une application de manière distribuée était aisée avec JGroups. Bien sûr (et comme je l'ai fait remarqué précédemment), la notion de tuning de JGroups (ie. la configuration de la couche protocolaire - cf. mon article précédent) n'a pas été abordée, mais cela doit être fait en fonction des besoins de l'infrastructure (trafic réseau, firewall, sécurité, ...) et je laisse donc ce point à la convenance de chacun ;-).

Ici se clôture donc la partie JGroups de notre petit POC jmanager4all qui nous a permis de voir comment JGroups répondait à notre besoin mais également comment il allait être utilisé par la suite.

Le prochain article s'attaquera donc à la partie interopérabilité avec JMX.

A oui... j'oubliais... le code de se petit POC se trouve sur GitHub : https://github.com/jetoile/jgroups-sample

Pour les gouverner tous - partie 1/3

2011-01-31T22:24:00.001+01:00

Pour ceux qui l'auraient manqués (comment ça? Personne ne me suit... :( ), j'ai annoncé dans un post précédent que j'avais ouvert un compte sur GitHub pour hoster du code. Bien sûr, il y avait une petite idée derrière... ;-)

En fait, l'idée est partie d'un constat assez simple : sur différent projet, à chaque fois que j'ai voulu mettre en place JMX, ce qui m'a toujours profondément attristé était de ne pas pouvoir regrouper l'ensemble des informations des MBeans à un même endroit, c'est-à-dire, qu'il me fallait me demander où se trouvait tel ou tel MBean dans mon système alors que j'aurais aimé pouvoir me connecter sur n'importe quelle instance de mon système et y trouver tous les MBeans présents dans mon système. Enfin, pour être plus précis, j'aurais aimé pouvoir me connecter à n'importe quelle JVM qui hébergeait mon application et avoir accès à tous les serveurs JMX.

Bien sûr, me direz-vous, il existe des solutions comme Hyperic qui permettent d'agréger toutes les informations et d'offrir une solution à mon problème. Cependant, cela ne répondait pas à une des problématiques que j'ai pu avoir il y a quelques temps : dans le cas où il ne doit pas y avoir de serveurs dans mon système (même passif), une telle solution n'est pas envisageable. En effet, dans l'architecture de cette application, tous les noeuds de mon système étaient au même niveau hiérarchique afin d'éviter d'avoir un single point of failure. Aussi, introduire un manageur pour administrer mon système n'était pas envisageable. En outre, un autre des pré-requis de ce projet était qu'il n'y avait pas de connaissance préalable de où tournait mon application (au sens scalabilité du terme) : tout poste était susceptible de démarrer l'application sans qu'un serveur centralisé n'en ait connaissance.

Aussi, vous l'aurez compris, l'idée est, ici, de proposer une ébauche de solution pour répondre à la problématique précédemment citée : pour n'importe quelle application susceptible d'être exécutée de manière distributée, être capable d'avoir sur chacune la connaissance (connaissance au sens supervision et administration et non au sens applicatif du terme...) de l'état de mes autres instances.

En outre, cette petite mise en oeuvre était également un bon prétexte pour utiliser JGroups et JMX et montrer comment il était possible de les utiliser.

La problématique étant posée, je vous propose donc une petite boite à outils permettant de faire cela de manière simple : en démarrant son application et en positionnant un agent sur la JVM, elle permet de remonter dans le serveur JMX courant tous les MBeans se trouvant sur les autres serveurs JMX (modulo qu'ils aient été démarrés par une JVM où l'agent aurait ếté mis).

Pour ce faire, un premier choix a été de m'appuyer sur JGroups pour connaitre et être informé de l'état de mon système : je n'avais pas envie de gérer toutes les problématiques de Heartbeat & co. et j'ai donc décidé de déléguer à JGroups cette problématique. En outre, cela permettait une plus grande configuration de la couche de découverte et de surveillance de mon système puisque JGroups possédait déjà une grande facilité de configuration.

La série d'articles qui suivra expliquera donc comment cela fonctionne et sur quoi je me suis appuyé pour le faire.

Elle sera découpée en deux parties :

La première partie fournira une sorte de pseudo exemple d'utilisation de JGroups en proposant une solution permettant lors de l'utilisation d'une application distribuée de récupérer et de conserver localement l'état d'un objet distant dans une sorte de cache tout en supprimant cet objet si l'application distante est arrêtée.
La deuxième partie ajoutera l'utilisation de JMX pour permettre la récupération des MBeans distants ainsi que leurs enregistrement dans le MBeanServer courant.

Ouverture d'un compte GitHub

2011-01-30T20:37:00.001+01:00

Voilà, ça fait quelques jours que je travaille sur un petit projet perso.

Aussi, afin de pouvoir le hoster, je me suis créé un compte sur GitHub : https://github.com/jetoile.

Pour toutes informations sur Git, je vous renvoie sur le site : http://blog.gitfr.net/

De mon coté, je continue mon petit projet que je documenterai via de nouveaux articles d'ici peu.

Rester à l'écoute ;-)

Petites astuces avec JMX

2011-01-23T12:31:00.003+01:00

Ce rapide article fournit un petit retour d'expérience de quelques galères que j'ai pu avoir avec JMX (Java Management eXtension), galères certes stupides mais qui pourront peut être servir à d'autres... ;-)
Sera donc abordé deux points :

Erreur lors de l'arrêt de tomcat configuré avec JMX
Impossibilité de se connecter à l'agent JMX

Message d'erreur lors de l'arrêt d'Apache Tomcat?

Cas d'usage

Les options permettant d'activer JMX sur la JVM ont été passées via la variable JAVA_OPTS ou autre (via le catalina.sh par exemple).

Le démarrage de Tomcat s'effectue sans problème mais lors de son arrêt, une erreur apparaît et tomcat refuse de s'arrêter c'est-à-dire que son processus tourne toujours en tâche de fond.

Exemple de variable JAVA_OPTS :

export JAVA_OPTS="$JAVA_OPTS \
-Dcom.sun.management.jmxremote \
-Dcom.sun.management.jmxremote.port=18080 \
-Dcom.sun.management.jmxremote.authenticate=false \
-Dcom.sun.management.jmxremote.ssl=false"

Message affiché sur la console lors du démarrage de Tomcat :

khanh@khanh-vaio:/opt/apache-tomcat-6.0.20/bin$ ./startup.sh
Using CATALINA_BASE:   /opt/apache-tomcat-6.0.20
Using CATALINA_TMPDIR:  /opt/apache-tomcat-6.0.20
Using CATALINA_HOME:  /opt/apache-tomcat-6.0.20/temp
Using JRE_HOME:     /usr/lib/jvm/java-6-sun/jre

Message affiché sur la console lors de l'arrêt de Tomcat :

khanh@khanh-vaio:/opt/apache-tomcat-6.0.20/bin$ ./shutdown.sh
Using CATALINA_BASE:   /opt/apache-tomcat-6.0.20
Using CATALINA_TMPDIR:  /opt/apache-tomcat-6.0.20
Using CATALINA_HOME:   /opt/apache-tomcat-6.0.20/temp
Using JRE_HOME:     /usr/lib/jvm/java-6-sun/jre
Erreur: Exception envoyée par l'agent : java.rmi.server.ExportException: Port already in use: 18080; nested exception is: 
        java.net.BindException: Address already in use

Explication

En fait, cette erreur se produit lors de l'arrêt de Tomcat car le script shutdown.sh (ou catalina.sh stop) relance un processus java qui tente alors de démarrer un serveur RMI qui est utilisé par JMX. Bien sûr, ce port étant déjà utilisé par le processus java que l'on tente d'arrêter, cela échoue.

Proposition pour résoudre le problème

~~Ne pas positionner les options pour activer JMX sur la variable système JAVA_OPTS au risque de ne pas pouvoir démarrer plusieurs processus Java.~~
~~Si c'est le script catalina.sh qui positionne la variable JAVA_OPTS, ne pas la positionner dans tous les cas mais seulement dans le cas où l'argument start est passé au script.~~
~~Positionner la variable JAVA_OPTS dans le script startup.sh.~~
Utiliser la variable CATALINA_OPTS qui n'est utilisée que quand les options run et start sont passées"

CATALINA_OPTS (Optional) Java runtime options used when the "start", or "run" command is executed.

Problème de connexion?

Cas d'usage

Une jconsole ou une jvisualvm qui n'arrive pas à se connecter à un programme ou une connexion au connecteur d'un agent JMX qui échoue avec une exception.

Chose d'autant plus étonnante qu'avec une connexion réseau, il n'y a pas de problèmes alors qu'en mode hors-ligne, impossible d'avoir accès à l'agent JMX.

Exemple d'exception lors de la tentative de connexion à l'agent JMX distant :

java.lang.NullPointerException
at javax.management.remote.rmi.RMIConnector.connect(RMIConnector.java:281)
at javax.management.remote.rmi.RMIConnector.connect(RMIConnector.java:227)
at com.blogspot.jetoile.jgroups.connector.ConnectorStubListener.update(ConnectorStubListener.java:47)
at com.blogspot.jetoile.jgroups.connector.ConnectorStubManager.put(ConnectorStubManager.java:46)
[...]
at com.blogspot.jetoile.jgroups.connector.TestJMXServerTest.main(TestJMXServerTest.java:34)

Fenêtre d'erreur de la jconsole :

Fenêtre d'erreur de jvisualvm : "Data not available because JMX connection to the JMX agent could not be established." :

Analyse

Après de multiples tentatives pour comprendre, j'ai tenté un changement de jre pour voir si cela ne pouvait pas venir d'une anomalie (si j'avais un problème de connexion en mode hors-ligne, ce n'était pas pour rien puisque j'étais effectivement hors-ligne et, par conséquent, je devais me débrouiller par moi-même... ;-) ).

Ainsi, en passant d'une jre hotspot vers une openjdk, j'ai obtenu une stacktrace beaucoup plus complète puisqu'elle m'a clairement indiquée la source du problème :

ERROR c.b.j.j.c.ConnectorStubListener - ConnectorStubListener update: {}
java.rmi.ConnectIOException: Exception creating connection to: 192.168.xxx.xxx; nested exception is:
java.net.NoRouteToHostException: Network is unreachable
at sun.rmi.transport.tcp.TCPEndpoint.newSocket(TCPEndpoint.java:632) ~[na:1.6.0_20]
at sun.rmi.transport.tcp.TCPChannel.createConnection(TCPChannel.java:216) ~[na:1.6.0_20]
at sun.rmi.transport.tcp.TCPChannel.newConnection(TCPChannel.java:202) ~[na:1.6.0_20]
at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:128) ~[na:1.6.0_20]
at javax.management.remote.rmi.RMIServerImpl_Stub.newClient(Unknown Source) ~[na:1.6.0_20]
at javax.management.remote.rmi.RMIConnector.getConnection(RMIConnector.java:2343) ~[na:1.6.0_20]
at javax.management.remote.rmi.RMIConnector.connect(RMIConnector.java:296) ~[na:1.6.0_20]
at javax.management.remote.rmi.RMIConnector.connect(RMIConnector.java:244) ~[na:1.6.0_20]
at com.blogspot.jetoile.jgroups.connector.ConnectorStubListener.update(ConnectorStubListener.java:47) ~[classes/:na]
at com.blogspot.jetoile.jgroups.connector.ConnectorStubManager.put(ConnectorStubManager.java:46) [classes/:na]
...
at com.blogspot.jetoile.jgroups.connector.JMXServer.start(JMXServer.java:152) [classes/:na]
at com.blogspot.jetoile.jgroups.connector.TestJMXServerTest2.main(TestJMXServerTest2.java:34) [test-classes/:na]


Caused by: java.net.NoRouteToHostException: Network is unreachable
at java.net.PlainSocketImpl.socketConnect(Native Method) ~[na:1.6.0_20]
at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:310) ~[na:1.6.0_20]
at java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:176) ~[na:1.6.0_20]
at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:163) ~[na:1.6.0_20]
at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:384) ~[na:1.6.0_20]
at java.net.Socket.connect(Socket.java:546) ~[na:1.6.0_20]
at java.net.Socket.connect(Socket.java:495) ~[na:1.6.0_20]
at java.net.Socket.(Socket.java:392) ~[na:1.6.0_20]
at java.net.Socket.(Socket.java:206) ~[na:1.6.0_20]
at sun.rmi.transport.proxy.RMIDirectSocketFactory.createSocket(RMIDirectSocketFactory.java:40) ~[na:1.6.0_20]
at sun.rmi.transport.proxy.RMIMasterSocketFactory.createSocket(RMIMasterSocketFactory.java:146) ~[na:1.6.0_20]
at sun.rmi.transport.tcp.TCPEndpoint.newSocket(TCPEndpoint.java:613) ~[na:1.6.0_20]
... 34 common frames omitted

Explication

En fait, mon problème venait du fait que mon fichier hosts était incorrect (je vous avais prévenu que c'était une erreur stupide : n'importe qui aurait pensé à vérifier sa configuration réseau... ! ;-) ).

En effet, la couche logicielle gérant mes connexions réseaux sur mon ordinateur a tendance à ajouter dans mon fichier /etc/hosts mon adresse réseau. Cependant, lorsque je coupe mon wifi, mon ordinateur passe en mode hors-ligne sans modifier mon fichier hosts, ce qui corrompt ma configuration réseau.

Proposition pour résoudre le problème

Corriger son fichier hosts et vérifier sa configuration réseau

A noter que dans mon cas, le fait d'avoir changer de jre m'a permis d'obtenir une stacktrace beaucoup plus complète et précise. Aussi, dans un moment de désespoir et en dernier recours, il peut être intéressant de changer de jre ;-).

JGroups : tour d'horizon

2010-12-28T17:05:00.006+01:00

Actuellement, le besoin de rendre les systèmes ou les applications interopérables est indéniable. Pour ce faire, de nombreuses technologies ont vues le jour. Il peut s'agir des MOM (Message-Oriented Middleware), des protocoles de communication entre les applications clientes et serveurs (REST, Soap, RMI, ...), de solutions propriétaires utilisées pour permettre la communication entre les serveurs pour des problématiques de réplication ou de synchronisation ou même de solutions basées sur le paradigme NoSQL.

Cependant, il est important de ne pas oublier que nos couches basses restent les protocoles TCP ou UDP et que répondre par un grand concept tel que MOM, réplication de serveurs ou cache distribué sur une problématique ne permet pas de savoir ce qui se trame derrière...

Un produit souvent méconnu est utilisé en interne pour les problématiques de communication entre serveurs et même si, à ce jour, je ne connais pas d'implémentations de MOM qui l'utilise, il pourrait être un très bon candidat pour ces dernières en interne. Il s'agit de JGroups.

Aussi, cet article va tenter de donner un rapide tour d'horizon sur JGroups en présentant ses concepts. Il s'appuiera sur sa version stable courante, à savoir la version 2.11.0.
A noter que ce tour d'horizon s'appuie très fortement sur le manuel de référence de JGroups.

Cet article suivra le plan suivant :

Présentation des APIs de JGroups

Les interfaces

La classe JChannel

Les blocs de construction

Un peu d'histoire...

Créé par Bela Ban, JGroups a vu le jour suite à son travail universitaire dans les équipe de Ken Birman sur le framework Ensemble qui, en 1998-1999, était un prototype pour la troisième génération de communication de groupes. Ensemble faisait suite à Horus (écrit par Robbert VanRenesse) qui faisait lui-même suite à ISIS (écrit par Keb Birman) et était écrit en OCaml. Ensemble proposant une interface pour s'interfacer avec Java mais s'appuyant sur son coeur, cela a été le début de JGroups (enfin pour être plus précis le début de JChannel puis de la partie ProtocolStack) qui avait pour objectif de fournir une solution full Java de Ensemble.

Ainsi, JGroups a pris son essor en 2000 avec le départ de Bela Ban du pôle de recherche de l'université de Cornell pour enfin être utilisé par JBoss dès 2002 avec, entre autre JBossCache.

Présentation des concepts

La communication entre groupes utilise les termes de groupes et de membres qui font partis intégrantes des groupes. En fait, un membre peut être vu comme un noeud et un groupe comme un cluster.

En fait, un noeud est un processus qui réside sur une machine hôte et un cluster est constitué d'un ou de plusieurs noeuds, sachant que plusieurs noeuds peuvent résider sur le même hôte et qu'ils peuvent appartenir à un ou plusieurs clusters.

JGroups est un framework permettant la communication fiable entre groupes et permets aux processus :

de rejoindre un groupe,
d'envoyer des messages à tout ou partie des membres du groupe,
et de recevoir les messages des membres du groupe.

En outre, JGroups permet de garder de notifier les membres de chaque groupe lors de l'arrivé d'un nouveau membre ou d'un départ ou arrêt brutal de l'un d'eux.

Un groupe est identifié par son nom et n'a pas besoin d'être créé explicitement puisqu'il est créé automatiquement.

En fait, l'architecture de JGroups s'articule autour de trois points :

les canaux (channel) utilisés par les applications pour leurs permettre de prendre part au groupe de communication fiable,
les blocs de construction (building blocks) qui sont des couches au dessus des canaux qui permettent d'abstraire ces derniers de la pile de protocoles à utiliser,
la pile de protocoles qui implémentent les propriétés d'un canal donné.

En fait, un canal est connecté à une pile (stack) de protocoles et lorsqu'une application émet un message, le canal le transmet au travers de cette pile pour effectuer séquentiellement des traitements jusqu'à la couche réseau. De manière similaire, pour qu'une application reçoive un message, ce dernier doit repasser dans cette pile de protocole (dans l'ordre inverse des traitements qu'il a subi lors de son émission) jusqu'à arriver à canal qui gère la file des messages jusqu'à leurs consommations par l'application.

Il est à noter que lorsqu'une application se connecte à un canal, la pile de protocole est démarrée et que lorsqu'elle se déconnecte, cette même pile est arrêtée. Quand le canal est fermé, la pile est détruite permettant ainsi de libérer ses ressources.

Canal (Channel)

Pour joindre un groupe et émettre des messages, un processus doit créer un canal et s'y connecter en utilisant le nom du groupe puisque tous les canaux qui possèdent le même nom forment un même groupe.

Une fois connecté, un membre peut émettre (resp. recevoir) des messages aux (resp. des) autres membres du groupe.

Il quitte le groupe en se déconnectant du canal permettant ainsi sa réutilisation. Cependant, un canal ne gère qu'un seul client simultanément.

Le client a également la possibilité de signaler qu'il ne désire plus utiliser un canal en le fermant. Dans ce cas, le canal ne peut plus être utilisé.

Chaque canal dispose d'une adresse unique et est toujours connu des autres membres de son groupe : une liste d'adresse des membres peut être récupérée d'un canal et est appelé vue (view).

Un processus peut alors sélectionner une adresse dans cette liste et émettre un message à destination de l'unique membre associé à cette adresse (mais également à lui-même puisqu'il appartient à la vue) ou émettre un message à tous les membre de la vue (et donc au groupe).

Pour gérer les vues :

lorsqu'un membre rejoint le groupe ou qu'il s'arrête (déconnexion ou détection de crash), JGroups envoie une nouvelle vue à tous les membres du groupes.
lorsqu'un membre est suspecté comme ayant potentiellement crashé, un message de suspicion est émis à destination de tous les membres non fautif.

Ainsi, un canal peut recevoir trois types de messages ;

les messages normaux (ie. un message émis par une application),
les messages de vues lors de l'ajout ou du retrait d'un de ses membres,
les messages de suspicion.

Bien sûr, un client peut choisir s'il accepte de recevoir les messages de types vue ou suspicion.

En fait, les canaux sont similaires à des sockets BSD ; les messages sont stockés dans le canal jusqu'à temps qu'ils soient consommés par un client (approche pull). Dans le cas où il n'y a pas de messages, le client est bloqué. Cependant, JGroups propose également la notion de push pour recevoir les messages en se basant sur la notion de callback (ou, du point de vue client, de Listener). Il est à noter que le fonctionnement en mode pull tend à être supprimé en version 3 de JGroups : il est donc déconseillé de l'utiliser.

Afin de positionner les propriétés sur un canal, JGroups s'appuie sur une configuration XML.

Bloc de construction (Building Blocks)

Le canal est un concept simple qui permet de fournir la fonctionnalité basique d'un groupe de communication en proposant une douzaine de méthodes qui permettent la communication entre applications via la transmission de messages asynchrones sur le même modèle que UDP. Ainsi, par exemple, le canal de base ne gère pas l'ordonnancement des messages et il est alors à la charge de l'application de réordonnancer les messages. En outre, le fonctionnement en mode pull nécessite généralement au client d'avoir à gérer un thread pour éviter de bloquer l'application lorsqu'il attend un message.

Ainsi, JGroups propose la notion de blocs de construction (Building Blocks) qui offre une API plus sophistiquée et qui s'appuie, en interne, sur les canaux.

Cela permet aux applications de communiquer en utilisant ces derniers en offrant une plus grande facilité d'utilisation du groupe de communication (par exemple, certains blocks permettent de gérer nativement les identifiants des corrélations).

Pile de protocoles (Protocol Stack)

La pile de protocoles contient de nombreuses couches de protocoles qui sont bidirectionnels. Tous les messages émis et reçus par le canal doivent passer à travers ces protocoles qui peuvent :

modifier,
réordonnancer,
supprimer ou laisser passer un message,
ajouter un entête au message,
découper le message en messages plus petit,
réaggréger un ensemble de messages,
...

La composition de la pile de protocoles (ie. ses couches) est déterminée par le créateur du canal via un fichier XML qui définit et paramètres les différentes couches à utiliser en lui associant un nom.

Cette séparation des concepts permet ainsi d'abstraire l'application, qui utilise un canal, de comment le message est émis et reçu.

Si aucune pile de protocoles n'est fournie lors de la création du canal, alors c'est sa configuration par défaut qui est utilisé.

Entête (Header)

Un entête (Header) est un ensemble d'informations personnalisables qui peut être ajouté à chaque message.

Il est à noter que JGroups utilise cette fonctionnalité dans de nombreux cas de figures comme, par exemple, pour savoir connaitre l'ordonnancement d'envoi des messages (via les entêtes NAKACK et UNICAST).

Evénement (Event)

Les évènements (Event) permettent à JGroups de savoir quels protocoles peuvent communiquer avec quel autre. Ainsi, contrairement aux messages qui transitent au travers du réseau entre les membres d'un groupe, les évènements transitent au travers la pile.

Présentation générale des APIs de JGroups

Les interfaces

JGroups propose un certain nombre d'interfaces principales sur lesquelles s'appuient les différentes implémentations :

MessageListener
MembershipListener
ChannelListener
Receiver
ReceiverAdapter

MessageListener

L'interface MessageListener permet d'être notifier lors de la réception d'un message lorsque le mode de fonctionnement est de type push.

Pour ce faire, la méthode receive(Message msg) est invoquée. Les méthodes getState() et setState() permettent, quant à elles, de récupérer l'état du groupe.

MembershipListener

L'interface MembershipListener permet d'être notifiée lorsqu'une nouvelle vue, un message de suspicion ou un évènement de bloc est reçu.

Dans la plupart des cas, c'est la méthode viewAccepted() qui est invoquée puisqu'elle notifie lorsqu'un nouveau membre a rejoint le groupe ou que l'un d'entre eux s'est déconnecté ou s'est arrêté brutalement. La méthode suspect() permet d'être informé lorsqu'un membre du groupe est suspecté de s'être arrêté brutalement mais qu'il n'a pas encore été exclu. La méthode block() est invoquée pour indiqué que le membre courant est sur le point d'être d'être exclu des membres qui ont le droit d'émettre des messages.

ChannelListener

L'interface ChannelListener est utilisée comme interface de callback lorsque l'application souhaite recevoir des informations sur les changements d'état du canal (fermeture, déconnexion ou ouverture).

Receiver

L'interface Receiver peut être utilisée pour recevoir des messages et les changements de vue dans le mode push. A noter que cette interface est marquée comme dépréciée et sera supprimé en version 3. L'utilisation de MessageListener et MembershipListener est préconisée.

ReceiverAdapter

Cette classe permet de fournir une implémentation par défaut de l'interface Receiver en ne permettant d'avoir à implémenter que les méthodes nécessaires (dont la méthode receive()).

L'interface Address

Chaque membre d'un groupe dispose d'une adresse qui l'identifie de manière unique. Cette adresse est représentée par l'interface Address qui require une implémentation concrète afin de fournir ses méthodes de comparaison, de trie et afin de permettre de différencier une adresse de type multicast.

Cependant, une implémentation de l'interface Address ne doit jamais être utilisée directement et l'interface Address doit être vue comme une couche d'abstraction lui permettant d'identifier le noeud dans le cluster. Ses implémentations sont généralement générées par la couche la plus basse du protocole (ie. UDP ou TCP).

Puisque l'adresse identifie de manière unique un canal et plus précisément un membre du groupe, elle peut être utilisée pour émettre des message.

Ainsi, par exemple, dans le cas de JChannel, l'adresse, qui est implémentée par la classe IpAddress, correspond à l'IP de l'hôte sur laquelle se trouve le membre et de son port sur lequel sont reçus les messages.

La classe Message

Les échanges de données émis entre les membres se fait au travers de messages qui sont représentés par la classe Message. Un message peut être émis, par un membre, aussi bien à un membre ou à tous les membres du groupe du canal.

Il est composé de cinq parties :

L'adresse de destination : si elle vaut null, le message est émis à tous les membre du groupe courant.
L'adresse de l'émetteur : ce champ est optionnel mais sera renseigné par le protocole de transport avant que le message n'atteigne la couche réseau.
Les drapeaux (flags) qui est codé sur un octet et qui peut valoir l'une des valeurs suivantes : OOB, LOW_PRIO ou HIGH_PRIO.
Le contenu (payload) : codé sous forme de buffers d'octets, la classe Message doit contenir les méthodes permettant de sérialiser et désérialiser l'information transmise.
Les entêtes (headers) qui représentent les informations additionnelles au contenu.

La classe View

Une vue représente la liste des membres d'un groupe à un instant donné. Elle consiste en un objet de type ViewId qui représente de manière unique la vue ainsi que la liste de ses membres.

Les vues sont gérées automatiquement par la couche de protocoles lorsqu'un nouveau membre rejoint le groupe ou qu'un membre le quitte. Tous les membres d'un groupe voient la même séquence de vues qui sont ordonnées.

Ainsi, généralement, le premier membre d'une vue est le coordinateur (son rôle consiste à émettre les nouvelles vues aux autres membres du groupe). Cela permet, si les membres du groupes changent, de déduire le coordinateur facilement sans avoir à contacter les autres membres du groupe.

A noter que lorsqu'une application est notifiée que le groupe a changé (ie. qu'une nouvelle vue a été reçue), la vue est déjà à sa disposition dans le canal.

La classe ViewId

La classe ViewId est utilisée pour numéroter les vues et consiste en l'adresse du créateur de la vue et en son numéro de séquence.

La classe MergeView

Lorsqu'un groupe se retrouve découpé en sous-groupe (par exemple, lors d'un partitionnement du réseau puis de son ré-aggrégement), les vues peuvent nécessiter un merge.

Dans ce cas, un objet de type MergeView qui étend la classe View est reçu par l'application. Cette classe contient, en plus de View, la liste des vues qui ont été mergés.

Ainsi, par exemple, si un groupe est décrit par la vue V1:(p,q,r,s,t), qu'il subit un découpage en deux sous-groupe V2:(p,q,r) et V2:(s,t), et que sa vue mergée est v3:(p,q,r,s,t), alors l'objet MergegView contiendra la liste des deux vues suivantes : v2:(p,q,r) et v2:(s,t).

La classe JChannel

Afin de pouvoir joindre un groupe et émettre des messages (ou en recevoir), un processus doit créer un canal. Un canal peut s'assimiler à une Socket. Quand le client se connecte à un canal, il doit donner le nom du groupe qu'il veut rejoindre. En effet, un canal est (dans son mode connecté) toujours associé à un groupe donné. La pile de protocoles a alors à sa charge de vérifier que le canal se joint au groupe du même nom, résultant un nouvelle vue à installer sur chaque membre du groupe.

Si aucun membre existe, le groupe est créé.

A noter que lors de sa création, un canal est dans un état déconnecté. Pour qu'il puisse commencer à traiter des opérations, il doit être dans un état connecté.

Les blocs de construction (Building blocks)

Les blocs de construction sont les couches qui se trouvent au dessus des canaux. La plupart ne nécessite pas d'un canal mais seulement d'implémenter l'interface Transport (qui est également implémentée par la classe Channel). Cela leurs permet de fonctionner pour n'importe quel type de transport qui implémente cette interface. Les blocs de construction peuvent donc être utilisés à la place des canaux si cela est nécessaire. Ainsi, alors que les canaux peuvent être vus comme des sortes de sockets, les blocs de construction peuvent bénéficier d'une interface beaucoup plus sophistiquée.

Dans la suite, seuls les blocs de construction les plus importants seront décrits (à noter que le bloc de construction PushPullAdapter étant déprécié, il ne sera pas non plus décrit).

MessageDispatcher

Les canaux sont de simple patron pour émettre et recevoir des messages de manière asynchrone. Cependant, il peut être nécessaire de disposer d'un moyen de communiquer de manière synchrone.

Le MessageDispatcher offre cette possibilité en fournissant la possibilité d'émettre un message (ou requête) en positionnant un identifiant de corrélation afin de pouvoir associer la réponse avec la requête.

Il offre également la possibilité de recevoir un message en mode push.

Pour l'utiliser, il doit être créé associé avec un canal et peut être utilisé coté émetteur ou récepteur.

S'il est utilisé du coté serveur, alors à chaque requête reçu, la méthode handle() provenant de l'interface RequestHandler est invoquée.

Cette méthode retourne le message (qui doit être sérialisable) ou lève une exception qui sont transmises au client.

S'il est utilisé du coté client, il est possible d'utiliser deux méthodes :

castMessage() qui permet de requêter un ensemble de destinataires (dans ce cas, si le destinataire est positionné sur l'entête du message, il sera écrasé) et qui renvoie un objet de type RspList (qui implémente l'interface Map)
sendMessage() qui permet de requêter un seul destinataire (dans ce cas, le destinataire doit être positionné sur l'entête du message)

Ces deux méthodes peuvent positionner un certain nombre d'options lors de l'émission du message encapsuler dans un objet de type RequestOptions tels que :

un timeout qui permet d'indiquer le temps qu'il faut attendre la réponse.
le type de requête à émettre :

dès qu'une réponse arrive, la méthode castMessage() rend la main au programme (GroupRequest.GET_FIRST)
attend la réponse de chaque destinataire avant de rendre la main au programme (GroupRequest.GET_ALL)
attend la majorité des réponses (GroupRequest.GET_MAJORITY)
attend la majorité absolue des réponses (GroupRequest.GET_ABS_MAJORITY)
n'attend aucune réponse (GroupRequest.GET_NONE)

un filtre pour les réponses attendues à l'aide d'un objet de type RspFilter

A noter que si un membre destinataire se déconnecte du canal (dans le cas d'un arrêt brutal par exemple), alors l'objet RspList retourner par la méthode castMessage() contiendra une réponse indiquée comme en échec.

RpcDispatcher

La classe RpcDispatcher est dérivée de MessageDispatcher et permet donc au programmeur d'invoquer des méthodes distantes sur un ou tous les membres du groupe et, optionnellement, attendre leurs réponses. Cependant, contrairement à l'utilisation d'un MessageDispatcher, l'utilisation d'un RpcDispatcher est plus simple pour un besoin de type requête/réponse puisqu'il ne nécessite pas d'avoir à implémenter l'interface RequestHandler (et donc la méthode handle()).

En effet, il est possible d'indiquer lors de l'émission des requêtes (qui se fait à l'aide des méthodes callRemoteMethod() et callRemoteMethods()) quelles seront les méthodes (ainsi que leurs paramètres) qui seront invoqués lors de la réception des réponses.

Les autres paramètres de ces méthodes sont similaires à la méthode castMessage() de la classe MessageDispatcher.

De plus, il est à noter qu'il est possible d'utiliser les méthodes callRemoteMethodWithFuture() et callRemoteMethodsWithFuture() qui, comme leur nom l'indique, permettent de ne pas bloquer l'application lors de l'appel à des méthodes.

ReplicatedHashMap

La classe ReplicatedHashMap a été écrite comme une classe de démonstration afin de montrer comme les états pouvaient être partagés entre les différents noeuds du cluster. Aussi, elle n'a pas été entièrement testée et n'a pas pour objectif d'être utilisée en production.

Une ReplicatedHashMap utilise une HashMap concurrente en interne et permet de créer différentes instances d'objets de type HashMap dans différents processus. Toutes ces instances possèdent exactement le même état. Lorsqu'une instance de ReplicatedHashMap est créée, un nom de groupe permet de déterminer quel groupe de ReplicatedHashMap est rejoint et la nouvelle instance interroge alors les autres membres existants pour connaitre l'état courant, le met à jour et se démarre.

Les modifications de la ReplicatedHashMap (méthodes put(), clear() ou remove()) sont propagées de manière ordonné dans tout le groupe alors que les lectures (méthode get()) sont faites sur la copie locale.

NotificationBus

La classe NotificationBus permet d'émettre et de recevoir des notifications. Ainsi, cela permet à une application de maintenir un cache local répliqué avec toutes les autres instances. La classe NotificationBus s'appuie sur un canal en interne.

En fait, le bloc de construction NotificationBus s'apparente à JMS dans son mode publish/subscribe. Cependant, il peut également être utilisé pour faire du point à point en précisant l'adresse du destinataire.

Liste des protocoles

Ce paragraphe fournit à titre indicatif une liste non exhaustive de protocoles fournies par JGroups. Pour plus d'informations sur la configuration de chacun, il est conseillé de se référer à la documentation officielle et/ou au wiki dont est issu ce paragraphe.

Catégorie	Nom	Description
Transport	UDP	UDP utilise le protocole multicast IP pour émettre des messages à tous les membres du groupe et des datagrams UDP pour les messages unicast (ie. à destination de membres particuliers). Quand il et démarré, il ouvre un socket multicast et unicast : le socket unicast est utilisé pour émettre et recevoir les messages unicast alors que le socket multicast pour les messages multicast. L'adresse du canal est l'adresse et le port du socket unicast. Une pile de protocoles utilisant UDP comme protocole de transport est généralement utilisé avec les groupes dont les membres s'exécute sur le même hôte ou de manière distribué sur le LAN. Il est nécessaire de s'assurer que le multicast IP est supporté entre les sous-réseau, ce qui n'est souvent pas le cas. Dans ce dernier cas de figure, il est préférable d'utiliser le protocole de transport TCP.
	TCP	TCP permet d'indiquer à JGroups qu'il doit s'appuyer sur le protocole de transport TCP pour émettre des messages à travers les membres du groupe. Dans ce cas, les membres du groupe créé un réseau de connexions TCP.
	TCP_NIO	TCP_NIO est une implémentation de TCP ne bloquant pas les I/O. Cependant, il n'est pas conseillé de l'utiliser en production mais d'utiliser plutôt le protocole TCP.
	TUNNEL	TUNNEL est un protocole de transport qui fonctionne en ouvrant une connexion TCP sur un routeur de message (tel que le Gossip Router). Tous les membres d'un groupe utilisant le protocole TUNNEL doivent être connectés au même routeur qui a pour rôle de transmettre les messages. Il peut être utilisé dans le cas où des firewalls sont en place.
Découverte	PING	Le protocole PING permet de récupérer les membres du groupe. Il est utilisé pour détecter le coordinateur (le membre le plus vieux) soit en utilisant une requête PING multicast à l'adresse IP MCAST, soit en se connectant au GossipRouteur : chaque membre du groupe répond alors avec un paquet {C, A} où C est l'adresse du coordinateur et A est sa propre adresse. Cela permet de déterminer le coordinateur en fonction des réponses, permettant ainsi d'émettre une requête de type JOIN au coordinateur. Si personne ne répond alors on considère qu'il s'agit du premier membre du groupe. A noter que, contrairement à TCPPING, PING permet une découverte dynamique et n'a donc pas besoin d'avoir la connaissance des autres membres du groupe.
	TCPPING	Le protocole TCPPING permet de récupérer les membres initiaux du groupe en contactant directement (ie. en point-à-point) les autres membres du groupe suite à la réception d'un message de type FIND_INITIAL_MBRS émit par le protocole GSM. Les réponses permettent de déterminer qui est le coordinateur du groupe. A noter que, si le noeud courant est le serveur (ie. après avoir reçu un message de type BECOME_SERVER), alors il répondra aux requêtes de type TCPPING avec un message de type TCPPING. TCPPING requière une configuration statique qui permet de savoir à l'avance où trouver les autres membre du groupe. Pour permettre une découverte dynamique des autres membres avec une pile de protocole qui s'appuie sur TCP, il est possible d'utiliser soit le protocole MPING (qui utilise un découverte multicast), soit le protocole TCPGOSSIP (qui contacte le GossipRouteur pour obtenir les membres initiaux).
	TCPGOSSIP	Le protocole TCPGOSSIP permet de récupérer les membres initiaux du groupe (utilisé par le protocole GMS et initié lors de la réception d'un message de type FIND_INITIAL_MBRS). Cela s'effectue en contactant le ou les GossipRouteur qui doivent se trouver à des adresses/ports connus. Les réponses reçues doivent permettre de déterminer le coordinateur qui doit être contacté dans le cas où le noeud courant souhaite rejoindre le groupe. A noter que, si le noeud courant est le serveur (ie. après avoir reçu un message de type BECOME_SERVER), alors il répondra aux requêtes de type TCPGOSSIP avec un message de type TCPGOSSIP.
	MPING	MPING (pour Multicast PING) utilise les IP multicast pour déterminer les membres initiaux du groupe. Il peut être utilisé avec tous les types de transport mais il s'applique plus généralement avec le protocole TCP.
	S3_PING	S3_PING utilise le protocole S3 d'Amazon pour déterminer les membres du groupe. Il a été conçu spécialement pour les membres qui s'exécute sur Amazon EC2 qui ne supporte pas les échanges multicast.
Merge	MERGE2	Les protocoles MERGE et MERGE2 permettent, dans le cas d'une scission du groupe (par exemple dans le cas d'un partitionnement réseau), de fusionner les sous-groupes en un seul. Il est seulement exécuté par le coordinateur du groupe (ie. le membre le plus ancien du groupe) qui rappelle périodiquement sa présence par un message muticast. Si un autre coordinateur du même groupe reçoit le message émis par un autre coordinateur, cela signifie qu'il doit engager un processus de fusion. A noter que si une fusion des sous-groupe {A, B} et {C, D, E} a lieu et donne {A, B, C, D, E}, l'état n'est pas fusionner mais laisse à l'application le soin de le faire.
Détection d'échec	FD	Le protocole FD (pour Failure Detection) s'appuie sur des messages de heartbeat. Si aucune réponse n'est reçu dans un délai imparti, le membre est déclaré comme suspect et sera exclu par le protocole GSM. Si le protocole FD_SOCK est utilisé, alors aucun message de heartbeat n'est émis mais un socket TCP est créé et un membre est déclaré mort quand le socket est fermé.
	FD_ALL	FD_ALL permet la détection d'échec en s'appuyant sur un simple protocole de heartbeat : chaque membre diffuse (multicast) périodiquement un message de type heartbeat. Chaque membre devant maintenir la table de tous les membres, dès qu'un message n'est pas reçu d'un des membres dans un délai imparti, il est considéré comme suspect.
	FD_PING	FD_PING utilise un script ou une commande qui reçoit comme paramètre l'hôte à pinger et qui doit renvoyer l'entier 0 en cas de succès et 1 sinon. A noter que la commande par défaut est /sbin/ping (resp. ping.exe).
	FD_ICMPL	FD_ICMPL utilise en interne la méthode InetAddress.isReachable() afin de déterminer si l'hôte donné est présent ou pas. A noter qu'il est préférable, avant d'utiliser ce protocole, de s'assurer au préalable du mode de fonctionnement de cette méthode pour le système d'exploitation cible.
	FD_SOCK	Le protocole FD_SOCK s'appuie sur une topologie en anneau au niveau des sockets TCP créé entre les membres du groupe. Ainsi, par exemple, le membre B est suspecté par son voisin A s'il observe une fermeture du socket TCP. Par contre, c'est au membre B de prévenir son voisin dans le cas d'un départ du groupe volontaire. Cependant, dans le cas de l'interruption d'un serveur et/ou arrêt brutal d'un switch (et donc une non fermeture du socket TCP), ce protocole est inefficace. Aussi, il est conseillé de l'utiliser conjointement avec le protocole de FD (qui s'appuie sur un fonctionnement en heartbeat).
	VERIFY_SUSPECT	Le protocole VERIFY_SUSPECT vérifie l'état d'un membre suspect en lui envoyant un ping. A noter qu'il doit être utilisé entre les couches FD et GMS sur la pile de protocole.
Messages fiables	pbcast.NAKACK	Le protocole pbcast.NAKACK permet de s'assurer de la fiabilité de réception des messages en utilisant une file de message de type FIFO conjointement à des ack. Ainsi, par exemple, si le noeud a reçu les messages P:1, P:3, P:4, alors il demandera une retransmission du message 2.
	pbcast.STABLE	Le protocole pbcast.STABLE permet de calculer les messages émis qui sont dans un état stable, c'est-à-dire qui ont été reçus par tous les membres. Cela permet au protocole NAKACK de supprimer les messages qui sont considérés comme ayant été reçu par tous les membres du groupe.
	UNICAST	Le protocole UNICAST fournit un protocole unicast fiable d'émission en mode FIFO.
Fragmentation	FRAG	Le protocole FRAG permet de fragmenter les messages trop gros lors de l'émission et de les ré-assembler lors de la réception. Ce protocole fonctionne aussi bien pour les messages émis en multicast ou en unicast. Il sérialise chaque message afin de le morceler, et cela, quel que soit son type (même s'il s'agit d'octets) afin de pouvoir prendre en compte avec précision la taille de l'entête et les propriétés du message.
	FRAG2	Le protocole FRAG2 permet, tout comme le protocole FRAG, de fragmenter les messages. Cependant, il offre un autre algorithme lui permettant de ne pas avoir à sérialiser les messages pour les découper. A noter que le protocole FRAG2 est préférable au protocole FRAG.
Gestion des membres du groupe	pbcast.GMS	Le protocole pbcast.GMS permet de gérer le départ ou l'enregistrement des membres dans le groupe. Il a également à sa charge de gérer les membres suspects et de les exclure du groupe. En fait, c'est lui qui émet les vues à tous les autres membres du groupe quand un changement se produit.
	VIEW_SYNC	Le protocole VIEW_SYNC permet aux membres du groupe de s'échanger périodiquement leurs vues et, si une incohérence entre vue est constatée, alors cela permet au protocole pbcast.GMS de mettre à jour la vue "officielle". En fait, ce protocole est le pendant du coordinateur mais au niveau des noeuds et garanti, en cas d'anomalie sur le coordinateur pendant une dissémination des vues, une consistance des vues.
Contrôle de flux	FC	Le protocole FC (Flow Control) permet de gérer le flux des messages. En effet, si l'émetteur émet plus vite que les destinataires ne peuvent consommer les messages, alors il y a risque de contension et c'est pourquoi les émetteurs ne doivent pas émettre les messages plus vite que leur capacité à être absorbés par le système. Pour ce faire, un émetteur possède N crédits pour chaque membres. Quand il émet un message, il décrémente le nombre d'octets émis au crédit du récepteur. Quand le crédit d'un récepteur est inférieur que ce que requière le message à émettre, l"émetteur se bloque et attend que l'émetteur dispose de plus de crédits. Le récepteur décrémente également le nombre d'octets reçu et émet son nombre de crédit à l'émetteur quand il est en dessous d'un certain seuil.
	SFC	Le protocole SFC correspond à une version simplifiée du protocole FC qui peut entraîner une surconsommation chez le récepteur lorsqu'il existe de la latence dans la couche de transport. En fait, ce protocole s'appuie sur un nombre d'octet maximal de crédits (configurable) qui est vérifié coté émetteur et récepteur. Il se marrie très bien avec le protocole pbcast.STABLE qui permet de "nettoyer" les messages déjà traités.
Transfert d'état	pbcast .STATE_TRANSFER	Le protocole pbcast.STATE_TRANSFER permet à un nouveau membre de récupérer l'état du groupe du coordinateur. Il fonctionne comme suit : le nouveau membre demande au coordinateur l'état Le coordinateur vérifie deux choses : un digest et l'état de l'application, le digest étant un vecteur contenant le plus haut et le plus bas numéro de séquence des messages reçu pour chaque membre Les messages dans le digest font déjà parti de l'état du groupe et ne doivent pas être reçus Le coordinateur émet l'état et le digest au membre arrivant Le membre arrivant positionne son état et positionne son digest avec celui reçu permettant ainsi de savoir les messages qui n'ont pas encore été reçu
	pbcast .STREAMING _STATE_TRANSFER	Le protocole pbcast.STREAMING_STATE_TRANSFER permet de pallier aux problèmes de gros messages non traités par le protocole pbcast.STATE_TRANSFER. Il permet de gérer des états de plus d'un gigaoctet.
Synchronisation virtuelle	pbcast.FLUSH	Le protocole FLUSH, comme son nom l'indique, force les membres du groupe à flusher leurs messages en cours plutôt que de les bloquer. Il peut être utilisé dans les cas suivants : Transfert d'état ; quand un membre demande l'état, le coordinateur indique à tous les membres d'arrêter d'émettre des message et attends leur réponse. Lorsque le nouveau membre a reçu toutes les informations requises, le coordinateur indique alors à tous les membres qu'ils peuvent reprendre leurs activités Changement du vue (c'est-à-dire opération de join) : avant d'installer une nouvelle vue, l'opération de flush permet de s'assurer que tous les messages émis dans la vue précédente ont été traités
Authentification et cryptage	AUTH	Le protocole AUTH est utilisé pour le couche d'authentification de JGroups en permettant de déterminer si un noeud est autorisé à rejoindre un groupe. AUTH s'appuie sur le protocole GMS et écoute les messages de type JOIN REQUEST : quand un message de type JOIN REQUEST est reçu, il cherche l'objet AuthHeader dans lequel doit se trouver une implémentation de la classe AuthToken. AuthToken est une classe abstraite dont les implémentations doivent fournir le mécanisme d'authentification. JGroups fournit des implémentations basiques telles que : SimpleToken, MD5Token et X50Token. Ces implémentations encrypte un chaîne de caractère se trouvant dans la configuration de JGroups et la passe au message JOIN REQUEST. Quand l'authentification est réussie, le message est passé à la pile qui s'occupe du protocole GMS, sinon, un message de type JOIN RESPONSE contenant un message d'erreur est renvoyé au noeud. Le client lève alors une exception de type SecurityException.
	ENCRYPT	Le protocole ENCRYPT permet de crypter les messages. Par défaut, il n'encrypte que le corps du message (ie. que tous les entêtes, les adresses des destinataires et de la source ne sont pas cryptés par défaut).
Synchronisation	BARRIER	Le protocole BARRIER peut être utilisé pour suspendre les messages à émettre.

Conclusion

Comme nous avons pu le voir, JGroups présente une API pour le développeur qui est très agréable à utiliser.

Cependant, la configuration des canaux peut s'avérer très ardue car elle est demande une bonne connaissance de la couche réseau mais aussi de ce qui est ciblé :

Est-il acceptable de faire du multicast IP sur notre réseau? A défaut, l'utilisation de TCP est-elle suffisante?
Faut-il crypter les messages?
Faut-il que les messages émis sur le canal X soient ordonnancés?
Comment veut-on s'assurer que les messages soient bien transmis?
...

Pour moi, c'est ce type de questions qu'il est important de se poser afin de configurer les différents canaux de JGroups. En outre, par défaut, JGroups peut s'avérer très bavard (notion de ping, signalisation en interne sur un merge, ...) et, là encore, plutôt que de faire hurler votre administrateur réseau, essayer de voir avec lui ce qui est acceptable.

Ainsi JGroups s'adresse aux personnes qui veulent avoir la main sur les couches basses (contrairement à JMS qui a tendance à être plus abstrait sur les couches basses puisque cela dépend du provider choisi).

Pour aller plus loin...

Site officiel de JGroups : http://www.jgroups.org/
Wiki de JGroups : http://community.jboss.org/wiki/JGroups

JMX pour les nuls... - Les connecteurs - Partie 8

2010-12-20T08:00:00.005+01:00

Ce huitième et dernier article sur JMX clôture cette petite série de posts sur JMX (cf. introduction, partie 1 portant sur les généralités, partie 2 portant sur les différents MBeans et le concept de Notification, partie 3 sur les agents JMX, partie 4 sur les classes de base, partie 5 sur le MBeanServer, partie 6 sur le chargement dynamique des MBeans et partie 7 sur les services JMX). Il abordera succinctement la notion de connecteur.

Table des matières

JMX, qu'est ce que c'est?

Composants JMX

Spécifications

JMX Instrumentation

MBean

Les Connecteurs

La spécification JMX défnit la notion de connecteurs : un connecteur est attaché à l'API JMX d'un MBean Server et le rend accessible de clients Java distants, le connecteur client possèdant une interface similaire à celle du MBean Server.

Un connecteur est donc constitué d'une partie cliente et d'une partie serveur :

Le connecteur serveur est attaché au MBean Server et écoute les requêtes de connexion des clients
Le connecteur client a pour rôle de trouver le server et d'étable une connexion avec ce dernier. Un connecteur client se trouve généralement dans une JVM différente du connecteur serveur et s'exécutera même généralement sur une machine différente.

Il est à noter que contrairement à un connecteur serveur, le connecteur client ne pourra se connecter qu'à un et un seul connecteur serveur (mais une application cliente pourra posséder plusieurs connecteurs clients).

JMX permet d'avoir de multiples connecteurs qui peuvent s'appuyer sur différents protocoles de communication entre le client et le serveur. Cependant, il définit le protocole standard et obligatoire sur tous serveurs JMX s'appuyant sur RMI (Remote Method Invocation) et le protocole optionel s'appuyant sur des sockets TCP et appelé JMXMP (JMX Messaging Protocol).

Les connecteurs distinguent deux notions distinctes qui sont la session et la connexion. Un connecteur client voit une session qui peut, tout au long de son cycle de vie de la session, avoir plusieurs connexions successives à un connecteur serveur. Il est à noter que, dans certains cas, il est possible d'avoir une connexion par requête (comme cela peut être le cas avec le protocole UDP ou JMS).

Une session possède un état sur le client mais pas nécessairement sur le connecteur serveur. Un connecteur, ne possède, quant à lui, pas forcément d'état.

Pour se connecter au connecteur serveur, le connecteur client peut utiliser une adresse du type "service:jmx:jmxmp://host1:9876". Si la requête de connexion aboutie, le point d'accès client du connecteur client est retourné en réponse.

Du point de vue de la connexion cliente, le code de l'utilisateur peut obtenir un objet qui implémente l'interface MBeanServerConnection. Cette interface étant similaire à l'interface MBeanServer, il devient transparent pour le code de l'application cliente d'interagir avec un MBean Server ne se trouvant pas dans la même JVM.

En fait, l'interface MBeanServerConnection est étendue par l'interface MBeanServer et contient donc toutes les méthodes principales sauf celles qui n'ont de sens que pour une utilisation locale.

Lors de l'enregistrement d'un écouteur auprès du MBeanServerConnection, le connecteur s'assure de la transmission de la notification de la partie serveur du connecteur à la partie cliente, puis à l'écouteur.
Les détails de la mise en œuvre de la transmission de la notification sont dépendants du protocole.

Lors de l'utilisation d'un filtre de notifications, le filtrage des notifications reçues peut être effectué soit par la partie cliente du connecteur, soit par le MBean Server suite à la transmission du filtre.
Il est, bien sûr, à noter que le filtrage des notifications coté serveur évite la transmission des notifications sur le réseau.
Cependant, il est conseillé de rendre les filtres indépendants de leur lieu d'exécution (pour rappel, l'interface NotificationFilter étend l'interface Serializable).

Toutes les implémentations des connecteurs coté serveur doivent posséder un buffer de notifications qui correspond à la liste de toutes notifications émises par les MBeans à destination du MBean Server. Il est à noter que les connecteurs doivent supporter les requêtes concurrentes pour des raisons évidentes. Concernant l'adresse du serveur connecteur, il est conseillé, pour la générer, de passer par la classe JMXServiceURL.

Afin de créer la partie cliente d'un connecteur, il existe deux possibilités :

si l'adresse du serveur est connue, la méthode connect(JMXServiceURL) de la classe statique JMXConnectorFactory peut être utilisée,
sinon, il est possible d'interroger le serveur pour obtenir un stub de JMXConnector.

Du point de vue de la connexion serveur, la connexion serveur est représentée par une sous-classe de JMXConnectorServer qui peut être obtenue :

soit à l'aide de la classe statique JMXConnectorServerFactory en lui indiquant le paramètre de type JMXServiceURL qui lui permet de connaitre les classes à instancier,
soit en instanciant directement la sous-classe de JMXConnectorServer.

Le connecteur serveur doit être attaché à un MBean Server (ce qui ne signifie pas qu'il doit s'enregistré en son sein) et doit être actif pour être utilisable. Il peut être attaché auprès du MBean Server de deux manières :

Le MBean Server auquel est attaché le connecteur serveur lui est spécifié lors de sa construction
Le connecteur serveur est enregistré auprès du MBean Server comme s'il s'agissait d'un MBean

Exemple de création et d'attachement d'un connecteur serveur auprès d'un MBean Server

MBeanServer mbs = MBeanServerFactory.createMBeanServer();
JMXServiceURL addr = new JMXServiceURL("jmxmp", null, 0);
JMXConnectorServer cs = JMXConnectorServerFactory.newJMXConnectorServer(addr, null, mbs);
cs.start();

Exemple de création et d'enregistrement d'un connecteur serveur dans un MBean Server

MBeanServer mbs = MBeanServerFactory.createMBeanServer();
JMXServiceURL addr = new JMXServiceURL("jmxmp", null, 0);
JMXConnectorServer cs = JMXConnectorServerFactory.newJMXConnectorServer(addr, null, null);
ObjectName csName = new ObjectName(":type=cserver,name=mycserver");
mbs.registerMBean(cs, csName);
cs.start();

JMX définit également comment un agent peut publier son serveur de connexion dans une infrastructure de recherche et de découverte ; ce qui permet à l'API cliente distante de savoir où trouver un serveur et ainsi de pouvoir si connecter. Cela couvre :

SLP (Service Location Protocol) en décrivant comme un agent enregistre le service URL d'un connecteur serveur avec SLP
Jini en décrivant comment un agent enregistre un stub du connecteur serveur dans le service de recherche Jini
JNDI (Java Naming and Directory Interface) en décrivant un agent enregistre le service URL d'un connecteur dans un annuaire LDAP

Un connecteur client peut spécifier un class loader par défaut lorsqu'il effectue sa connexion au serveur. Ce class loader est alors utilisé lors de la déserialisation des objets reçus du serveur que ce soit les valeurs retournées, les exceptions ou les notifications.
Le class loader par défaut est positionné par la valeur de l'attribut jmx.remote.default.class.loader définie par l'environnement JMXConnector, sinon, il s'agit du class loader du contexte.

Le class loader utilisé par le connecteur serveur pour déserialiser les paramètres reçus par le connecteur client est dépendant de l'opération : en effet, parfois, il peut s'agir de celui du MBean cible (si les types de paramètres ne sont pas définis par l'API JMX), parfois, de celui configuré pendant la création du connecteur server (s'il est prévu de l'utiliser dans une application de gestion particulière qui peut définir ses propres sous classes de types de paramètres de MBean ou NotificationFilter).
Le connecteur serveur possède un class loader par défaut qui est déterminé lors de son démarrage comme suit :

Si l'attribut jmx.remote.default.class.loader de l'environnement existe, sa valeur détermine le class loader à utiliser
Si l'attribut jmx.remote.default.class.loader.name de l'environnement existe, sa valeur détermine l'ObjectName du MBean à utiliser comme class loader par défaut. Cette fonctionnalité permet à un connecteur serveur d'être créé avec un class loader qui est un m-let dans le même MBean Server
Sinon, c'est le class loader du thread contextuel qui est utilisé

Pour plus d'informations sur l'utilisation de class loader étendu, il est recommandé de se référer au chapitre 13.11 Class Loading de la spécification JMX.

Afin d'éviter les difficultés avec le fonctionnement des class loader Java, il est conseillé de n'utiliser que les types standards Java ou fournis par l'API JMX ou les Open MBeans qui permettent des structures plus complexes. De même, pour les notifications, il est préconisé de n'utiliser que les notifcations suivantes :

NotificationFilterSupport
MBeanServerNotificationFilter
AttributeChangeNotificationFilter

Le connecteur serveur est, en outre, capable d'authentifier le client distant. Par exemple, pour le connecteur RMI, cela est fait fournissant une implémentation de l'interface JMXAuthenticator lors de la création du connecteur serveur. Dans le cas du connecteur JMXMP, cela est fait via SASL. Dans ces deux cas, le résultat de l'authentification renvoie un Subject JAAS qui représente l'identité authentifiée. Les requêtes alors reçues du client sont exécutées en utilisant cette identité. Avec JAAS, il est possible de définir les permissions liées à une identité. En particulié, il est possible de restreindre l'accès aux opérations du MBean Server en utilisant la classe MBeanPermission. Bien sûr, pour que cela fonctionne, il est nécessaire d'avoir un SecurityManager. Dans le cas où le connecteur serveur ne supporte pas l'authentification ou qu'il n'est pas configuré, les requêtes clientes sont exécutées en utilisant la même identité que celle qui a été créée avec le connecteur serveur. Comme alternative à JAAS, il est possible de controler l'accès aux opérations du MBean Server en utilisant un MBeanServerForwarder. Cet objet est une implémentation de l'interface MBeanServer et transmet les méthodes à un autre objet MBeanServer mais en ajoutant des opérations avant et après la transmission. Cela permet, en l'occurrence d'y faire des controles d'accès. Pour ajouter un MBeanServerForwarder, la méthode setMBeanServerForwarder peut être utilisée. De plus, pour chaque connexion à un connecteur serveur, au moins un Subject authentifié est néccessaire. Cela signifie que si un client effectue des opérations qui nécessitent plusieurs identités, des connexions différentes doivent être établies. Cependant, il est possible aux connecteurs (tels que les connecteurs RMI et JMXMP) d'utiliser la notion de délégation de Subject. Pour ce faire, avec chaque requête, le client spécifie un Subject. La requête est alors exécutée en utilisant une identité pour chaque requête si cela est possible. La permission a utilisé doit alors être de type SubjectDelegationPermission. Dans ce cas, pour chaque Subject délégué, le client obtient un MBeanServerConnection du JMXConnector pour un Subject authentifié. Les requêtes utilisées par le MBeanServerConnection sont émises avec un Subject délégué. Il est, de plus, à noter que ces objets de type MBeanServerConnection peuvent être obtenus du même JMXConnector et peuvent être utilisés simultanément. Ainsi, pour résumer, il est possible de configurer les permissions d'un connecteur serveur de deux manières :

toutes les permissions pour les opérations de chaque client distant doivent être configurées,
un SubjectDelegationPermission pour chaque Principal utilisé par les clients distants doit être configuré.

Le connecteur RMI est le seul connecteur qui doit être présent dans les implémentations de JMX. Il utilise l'infrastructure RMI (Remote Method Invocation) pour la communication entre le client et le serveur.
RMI définit deux couches de transport standard :

Java Remote Method Protocol (JRMP) qui est le protocole de transport par défaut
Internet Inter-ORB Protocol (IIOP) qui est le protocole défini par CORBA et qui permet l'interopérabilité avec un autre langage de programmation

Pour chaque serveur de connexion RMI, un objet distant implémentant l'interface distante RMIServer existe. Un client voulant communiquer avec le connecteur serveur doit obtenir une référence distante (ou stub) connecté à cet objet distant. Via RMI, chaque méthode appelée sur un stub sera transféré à l'objet distant. Ainsi, le client possédant un stub sur l'objet RMIServer pourra appeler obtenir le même résultat que s'il avait appelé l'objet du serveur.
De plus, il existe un objet distant pour chaque connexion cliente qui permet de créer un nouvel objet distant qui implémente l'interface distante RMIConnection.
Enfin, il est à noter que le code de l'utilisateur n'interagit généralement pas directement avec les objets du RMIServer ou du RMIConnection : en général, le stub RMIServer est obtenu au travers d'un objet RMIConnector qui implémente l'interface JMXConnector.
L'obtention de cet objet RMIConnector peut être fait de trois manières :

En fournissant un JMXServiceURL au JMXConnectorFactory qui spécifie le protocol RMI ou IIOP.
En obtenant le stub JMXConnector de " quelque part " (annuaire LDAP, Service de lookup JNDI, …).
En obtenant un stub RMIServer de " quelque part " et qui peut être utilisé comme paramètre du constructeur de RMIConnector.

Les notions de sécurité et de versionnement sont également décrites dans le spécification JMX (et plus particulièrement la JSR160). Cependant, ce document n'abordera pas ces points.

La spécification JMX (et plus précisément la JSR160) décrit comment implémenter un connecteur générique en précisant comment configurer par plugin son protocole de transport ainsi que la manière dont il encapsule les objets transitant du client au serveur et plus particulièrement sa gestion du classloader du MBean cible.
Cependant, ce document n'abordera pas ces points. Aussi, pour plus d'informations, il est conseillé de se référer à la JSR160 ou aux chapitres 15 - Generic Connector et 16 - Defining a new transport des spécifications agrégées JMX.

Le connecteur JMXMP est une configuration particulière du connecteur générique où le protocole de transport s’appuie sur TCP et l’encapsulation des objets est la sérialisation native Java.

La spécification JMX ne spécifie pas comment trouver l'adresse d'un serveur de connecteurs attaché à un agent connu ou comment découvrir les agents présents dans le système ainsi que ce qu'ils proposent. Cependant, la JSR160 propose trois infrastructures permettant de répondre à ces besoins :

SLP (Service Location Protocol)
JINI
JNDI (Java Naming and Discovery Interface) utilisé au travers un annuaire LDAP

Bien sûr, les APIs pour utiliser ces différentes technologies diffèrent cependant, les principes généraux restent identiques :

L'agent créé un ou plusieurs serveurs de connecteurs
Pour chacun des connecteurs à exposer, il expose soit le JMXServiceURL (dans le cas de SLP ou JNDI), soit le stub JMXConnector (dans le cas de JINI ou JNDI) qu'il enregistre dans le service de recherche (en spécifiant au besoin d'autres méta-données)
Le client interroge le service de recherche pour obtenir un ou plusieurs JMXServiceURL ou stub JMXConnector
Le client utilise soit le factory JMXConnectorFactory pour obtenir un JMXConnector connecté au serveur s'il possède un JMXServiceURL, soit se connecte directement au serveur en utilisant le stub JMXConnector

Ce document ne fournira pas plus d'informations sur ces points. Aussi, pour plus d'informations, il est conseillé de se référer à la JSR160 ou au chapitres 17 - Bindings to lookup services des spécifications agrégées JMX.

Le mot de la fin

Voilà, ce dernier article met fin à cette série. Si vous avez réussi à tenir jusque là et à tout lire, félicitation! Maintenant, vous devriez avoir (enfin, j'espère) une vision plus précise sur ce que contiennent les spécifications JMX. Bien sûr, cette série n'était qu'un condensée (qui vaut ce qu'il vaut) permettant de comprendre les concepts sans pour autant lire les 290 pages de spécification et ne se veut pas être suffisante pour tout maîtriser.

JMX pour les nuls... - Les services JMX - Partie 7

2010-12-13T08:00:00.005+01:00

Ce septième et avant dernier article sur JMX (cf. introduction, partie 1 portant sur les généralités, partie 2 portant sur les différents MBeans et le concept de Notification, partie 3 sur les agents JMX, partie 4 sur les classes de base, partie 5 sur le MBeanServer et partie 6 sur le chargement dynamique des MBeans) abordera les différents types de services JMX.

Table des matières

JMX, qu'est ce que c'est?

Composants JMX

Spécifications

JMX Instrumentation

MBean

Les Connecteurs

Le MBean Server propose, par défaut, un ensemble de fonctionnalités qui se présente sous forme de services JMX (ie. de MBeans), à savoir :

Service Monitoring
Service Timer
Service de relation
Service de sécurité

Service Monitoring

Il existe une famille de MBeans de monitoring qui se présentent qui permettent de scrupter les variations au cours du temps de la valeur des attributs des autres MBeans et qui permet d'émettre des notifications à intervalle régulier. Ils sont aussi classifiés comme des services de monitoring.

En fait, un service de monitoring (et donc un MBean de monitoring) permet d'observer la valeur d'un attribut donné présent dans un ou plusieurs MBeans (on dit qu'il s'agit alors du MBean observé) à un intervalle à régulier. Cette valeur peut être indifféremment la valeur d'un attribut ou la valeur contenue dans la valeur d'un attribut s'il est de type complexe. Pour chaque MBean observé, le moniteur interpole une seconde valeur qui est appelé le pas dérivé (derived gauge) et qui correspond, soit à la valeur observée, soit à la différence entre deux valeurs numériques obtenues consécutivement.

Un type de notification spécifique est alors émis à chaque service de monitoring lorsque le pas dérivé répond à un ou un ensemble de conditions (ou lorsque certaines erreurs se produisent) qui peuvent être initialisées lors de l'initialisation du moniteur ou dynamiquement au travers de l'interface d'administration du MBean moniteur.

Il existe trois types de moniteurs :

CounterMonitor qui permet de scrupter des valeurs de type entier (Byte, Integer, Short, Long) et qui se comporte comme un compteur :

les valeurs ne peuvent être inférieures strictement à 0,
les valeurs ne peuvent qu'être incrémentées,
les valeurs peuvent être tournantes (dans ce cas un modulo doit être défini).

GaugeMonitor qui permet de scrupter des valeurs de types entier ou flottantes (Float, Double) et qui se comporte comme un pas
StringMonitor qui permet de scrupter des valeurs de type String.

Tous ces moniteurs doivent étendre la classe abstraite Monitor alors que les types des valeurs surveillées doivent être supportés par le type de moniteur utilisé. Cependant, il est à noter que le moniteur vérifie le type de la valeur de l'instance retournée et non le te type de l'attribué déclaré dans les méta-données du MBean observé.

Pour les notifications, une sous classe spécifique de Notification est définie pour être utilisée par tous les services de monitoring. Il s'agit de la classe MonitorNotification.

Ainsi, elle est utilisée pour rapporter les cas suivants :

Une condition de déclenchement d'un moniteur est détectée (par exemple, si le seuil d'une valeur est atteinte)
Une erreur s'est produite durant la scrutation d'un attribut (par exemple, si un MBean est désenregistré)

La figure suivante représente tous les types de notifications qui peuvent être générées par un service Monitor.

Service Timer

Le service Timer permet de déclencher des notifications à des dates et heures spécifiques ou à intervalles réguliers. Les notifications sont émises à tous les objets déclarés comme étant interessés par les notifications émises par le timer (patron Observer).

Le service Timer est un MBean qui peut être managé en permettant, entre autre, aux applications de modifier la configuration de son ordonnanceur (scheduler).

En fait, la classe Timer gère une liste de notifications datées qui sont émises quand leur date et heure arrivent. Les méthodes de cette classe permettent d'ajouter et de supprimer des notifications de sa liste. En fait, les types de notifications sont fournis par l'utilisateur avec la date et optionnellement la fréquence et le nombre de répétitions.

Pour les notifications, une sous classe spécifique de Notification est définie pour être utilisée par le service Timer. Il s'agit de la classe TimerNotification.

Ainsi, elle est utilisée pour rapporter les cas suivants :

Les notifications ne sont déclenchées qu'une seule fois
Les notifications sont répétées à une période définie et/ou un nombre d'occurrences

Ces paramètres sont définis lorsque la notification est ajoutée à la liste de notifications du timer. En outre, à chacune des notifications émises est associée un identifiant unique.

Si la notification ajoutée au service Timer possède une date antérieure à la date courante, alors la méthode addNotification se comporte comme si la date indiquée était la date courante.

Si la date d'émission d'une notification est mise à jour alors qu'elle est déjà existante, alors aucune notification de mise à jour n'est émise.

Le service Timer MBean est un émetteur standard de notifications (qui possèdent un type et une date définis dans la liste de notifications ajoutées à l'aide de la méthode addNotification()). Tous les écouteurs d'un MBean Timer donnés reçoivent toutes les notifications. Les écouteurs interessés par un type de notifications Timer particulier doivent spécifier un objet filtre lors de leur enregistrement.

Lorsqu'un timer est actif et que la date d'une notification de type Timer arrive à son terme, le service Timer émet cette notification en fournissant son type, message, données utilisateurs ainsi que l'identifiant de la notification. S'il s'agit d'une notification périodique disposant d'un nombre d'occurrence, il est décrémenté.

Enfin, si la notification n'a plus besoin d'être émise (notification non récurente ou notification périodique disposant d'un nombre d'émission prédéfini), elle est supprimée de la liste des notifications.

Si une notification dispose d'une date d'émission antérieure à son démarrage, il est possible de l'émettre ou de l'ignorer à l'aide de la méthode sendPastNotification(). Par défaut, la valeur de cet attribut est mise à false.

Service Relation

JMX définit un modèle de relation entre les MBeans. Une relation est définie par l'utilisateur et se présente comme une association n-aire entre les MBeans.

Pour ce faire, JMX propose un ensemble de classes à utiliser pour décrire les relations, ainsi qu'un service qui permet de centraliser toutes les opérations de mise en relation.

Toutes les relations permettent d'associer un type de relations (qui fournit des informations sur les rôles qu'il contient comme la multiplicité) avec le nom de classe du MBean qui satisfait le rôle.

Le service de relations permet également de chercher un MBean au travers de ses relations.

Il est garant de la consistance des relations en vérifiant les opérations et le désenregistrement des MBean afin de s'assurer que les relations sont toujours conformes. Si une relation n'est plus valide, elle est supprimée du service de relations même si ses MBeans membres restent présents.

Une relation est composée de rôles nommés qui disposent d'une liste de MBeans associés à ce rôle. Cette liste doit être consistante avec les informations de multiplicité ainsi qu'avec les classes des MBean qui représentent ce rôle.

Un ensemble de définition de rôles constitue un type de relation.

Un type de relation est un patron pour toutes les instances de relations qui associent les MBeans représentant ses rôles.

Par la suite, le terme de relation signifiera une instance spécique d'une relation associant des MBeans existants aux rôles dans un type de relations défini.

Le tableau ci-dessous décrit les concepts nécessaires à la compréhension du modèle de relations défini par JMX :

Concept	Description
Role information	Décrit un des rôles dans une relation. L'information sur un rôle est composée du nom du rôle, de sa multiplicité, du nom de la classe qui participe à ce rôle, d'une propriété en lecture-seule sur les permissions et d'une description.
Relation type	Méta-donnée d'une relation, composée d'un ensemble de Role information. Permet de décrire les rôles qu'une relation satisfait et permet de servir de patron pour créer et maintenir des relations.
Relation	Association courante entre des MBeans qui satisfont une relation donnéee. Une relation peut avoir des propriétés et méthodes qui ne s'appliquent qu'à ses MBeans.
Role Value	Liste de MBeans qui satisfont un rôle donné dans une relation.
Unresolved Role	Résultat d'un accès illégal d'une opération sur un rôle. Contient la raison du refus de l'opération.
Support Classes	Classes internes utilisées pour représenter des types de relations et des instances de relations.
Relation Service	MBean qui peut accéder et maintenir la consistance de tous les types de relations et toutes les instances de relations dans un agent JMX. Fournit des opérations pour trouver un MBean et ses rôles dans une relation.

En JMX, le type de relation est un ensemble statique de rôles. Les types de relations peuvent être définis à l'exécution mais, une fois défini, ces rôles et informations sur les rôles ne peuvent être modifiés.

Exemple de relations :

Dans cet exemple, des livres (Books) et les propriétaires (Owner) représente des rôles :

Books représente le nombre de livres que possède la classe d'un MBean donnée.
Owner représente un propriétaire de livres d'une autre classe d'un MBean.

Un type de relations (Personal Library) peut être défini comme étant la notion d'appartenance de livres.

En fait, le service de relations empêche la création de types de relations invalides, de relations invalides ou la modifiation de valeurs de rôles invalides.

Quand une relation est supprimée du service de relations, ses MBeans membres ne sont pas impactés.

Quand un type de relation est supprimé, toutes les relations référencées sont au préalable supprimées. Cependant, c'est à l'appelant de gérer la consistance lors de la suppression d'un type de relations.

En outre, puisque les relations ne sont définies qu'au niveau des MBeans enregistrés, en supprimer un de l'annuaire est susceptible de modifier la relation. Le service de relations écoute, pour tous les MBean, le server de notifications qui indique quand un membre d'une relation est désenregistré. Le MBean correspondant est alors supprimé de tous rôles où il se trouve. Dans le cas où la nouvelle cardinalité du rôle n'est pas consistante avec son type de relation, alors la relation est supprimée du service de relation.

Le service de relations émet des notifications après l'exécution d'opérations qui modifient une instance de relations (création, mise à jour ou suppression). Cette notification fournit des informations sur la modification comme l'identifiant de la relation et la nouvelle valeur d'un rôle.

De plus, il est à noter qu'il existe deux types de relations et relations :

Les types de relations et relations internes : les types de relations et leurs instances sont créés par le service de relations et ne sont accessibles qu'aux travers ses opéraitons.
Les types de relations et relations externes : les types de relations et leurs instances sont instanciés en dehors du service de relations puis lui sont ajoutés. Dans ce cas, ils peuvent être accessibles directement et, en l'occurrence, peuvent être enregistré comme des MBeans. Il est cependant à noter que ces types de relation sont immuables et qu'elles ne doivent pas être modifiées une fois enregistré dans le service de relation.

En raison de la complexité de ce service, pour plus d'informations, il est préférable de se référer aux chapitres 11.2 Relation Service Classes, 11.3 Interfaces and Support Classes et 11.4 Role Description Classes des spécifications agrégées JMX.

Service Securité

Un MBean Server JMX peut avoir accès à des informations sensibles et peut être susceptible d'exposer des opérations sensibles. Pour ce faire, JMX propose un mécanisme d'accès à de telles opérations en s'appuyant sur le modèle de sécurité de Java : il est possible de définir des permissions qui permettent de contrôler l'accès au MBean Server et à ses opérations.

La sécurisation du MBean Server s'appuyant sur le modèle standard de sécurité Java, il est nécessaire de disposer du gestionnaire de sécurité Java (security manager). La méthode statique System.getSecurityManager() permet de le vérifier.

Pour rappel, le modèle de sécurité de Java s'appuie sur le principe de permissions : pour qu'une opération soit invocable, l'appelant doit posséder la/les permissions.
En effet, à un point donné de l'exécution d'un programme correspond un ensemble de permissions appliqué à l'exécution d'un thread.
En fait, une opération est autorisée si le thread qui l'invoque dispose des permissions nécessaires.

Les permissions sont des objets java qui étendent la classe Permission.

En fait, JMX défini, par défaut, sa propre permission MBeanServerPermission qui peut être configurée comme suit :

MBeanServerPermission qui prend en paramètre de son constructeur une chaine de caractère représentant la liste des opérations autorisées sur le MBeanServer (ex : MBeanServerPermission("createMBeanServer") qui permet de controler l'accès aux méthodes MBeanServerFactory.createMBeanServer )
MBeanPermission qui prend en paramètre deux chaines de caractères :

la première représente la cible et peut être composée du nom canonique de la classe ou d'une expression régulière, du membre (c'est-à-dire le nom de l'attribut ou de l'opération qui doit être accédé), et de l'ObjetName du MBean cible.

Exemples de cible :

com.example.Resource#Name[com.example.main:type=resource]
com.example.Resource#*[com.example.main:type=resource]
*#Name[com.example.main:type=resource]

la deuxième représente l'action une ou plusieurs méthodes du MBean Server parmi les suivantes :

addNotificationListener
getAttribute
getClassLoader
getClassLoaderFor
getClassLoaderRepository
getMBeanInfo
getObjectInstance
instantiate
invoke
isInstanceOf
queryMBeans
queryNames
registerMBean
removeNotificationListener
setAttribute
unregisterMBean

Les opérations suivantes ne sont pas soumises à la sécurisation du MBean Server :

isRegistered
getMBeanCount
getDefaultDomain

De plus, JMX propose la permission MBeanTrustPermission qui permet de faire confiance à un certain utilisateur ou code source signé. Si le signataire ou le code source possède cette permission, le MBean est considéré comme étant de confiance. Seuls les MBeans de confiance peuvent alors être enregistrés dans le MBean Server.

Une permission MBeanTrustPermission est configurée soit avec la valeur "register", soit avec la valeur "*" qui signifient toutes deux la même chose dans la version courante de la version JMX.

Ainsi, utilisé en complément de la permission MBeanPermission, la permission MBeanTrustPermission permet une gestion de la sécurité plus fine sur l'enregistrement des MBeans : la permission MBeanPermission vérifie qui enregistre alors que la permission MBeanTrustPermission vérifie ce qui est enregistré.

Exemples de fichier de policy :

grant {
    permission javax.management.MBeanPermission "*", "*";
};

grant codeBase "file:${user.dir}${/}appl1.jar" {
    permission javax.management.MBeanPermission "", "getClassLoaderRepository";
};

grant codeBase "file:${user.dir}${/}appl2.jar" {
    permission javax.management.MBeanPermission "[d1:*]", "isInstanceOf, getObjectInstance";
};

grant codeBase "file:${user.dir}${/}appl3.jar" {
    permission javax.management.MBeanServerPermission "findMBeanServer";
    permission javax.management.MBeanPermission "JMImplementation:*", "queryNames";
};

grant {
    permission javax.management.MBeanTrustPermission "register";
};

grant signedBy "Gorey" {
    permission javax.management.MBeanTrustPermission "register";
};

JMX pour les nuls... - Chargement dynamique de MBeans - Partie 6

2010-12-06T08:00:00.004+01:00

Cet article toujours dans la lignée de ma petite série d'articles sur JMX (cf. introduction, partie 1 portant sur les généralités, partie 2 portant sur les différents MBeans et le concept de Notification, partie 3 sur les agents JMX, partie 4 sur les classes de base et partie 5 sur le MBeanServer) sera plus accès sur les capacités de chargement dynamique des MBeans. Cependant, il n'abordera que succinctement cette partie car il est nécessaire d'avoir une très bonne connaissance du fonctionnement du classloader et qu'un simple article ne saurait l'aborder comme il se doit.

Table des matières

JMX, qu'est ce que c'est?

Composants JMX

Spécifications

JMX Instrumentation

MBean

Les Connecteurs

JMX propose un service de chargement dynamique de MBeans qui s'appuie sur les fonctionnalités du classloader Java pour récupérer et instancier les MBeans qui peuvent utilisés indifféremment des classes Java ou des librairies natives. Cette fonctionnalité existe car lorsque le serveur JMX est démarré, il peut ne pas avoir connaissance de tous les MBeans et devoir en télécharger. Pour ce faire, un service particulier chargé de gérer des applets de management (m-let) est utilisé pour instancier les MBeans obtenus d'une URL distante sur le réseau. En fait, le service de m-let permet d'instancier et d'enregistrer des MBeans dans le MBean Server en chargeant un fichier texte, dont la localisation est spécifiée par une URL, qui contient les informations des MBeans à obtenir. Quand ce fichier texte est chargé, toutes les classes spécifiés par le tag MLET sont téléchargées et une instance de chaque MBean spécifié est crée et enregistré. Le service de m-let étant lui-même un MBean enregistré dans le MBean Server, il peut être utilisé par d'autres MBeans, par d'autres applications ou par d'autres applications d'administration et de supervision distantes.

Le fonctionnement des m-let est similaire à celui de Java Web Start.

La classe MLet étend la classe URLClassLoader, ce qui implique qu'il s'agit également d'un classe loader.

Dans le cas générique, l'appel à la méthode getMBeansFromURL() du service de m-let permet de :

télécharger le fichier texte contenant le descriptif des MBeans (un MBean par tag MLET),
télécharger les classes nécessaires,
charger les classes dans le classe loader du MBean Server,
instancier les MBeans,
enregistrer les MBeans instanciés préalablement,
renvoyer les instances des MBeans.

Dans le cas où le MBean contient de méthodes natives et que des librairies natives sont chargées en utilisant la méthode System.loadLibrary, alors la méthode findLibrary du classe loader du m-let est appelé pour trouver la librairie. Cette méthode surcharge celle de la classe ClassLoader et, si la librairie est trouvée, copie cette dernière à l'emplacement retourné par la méthode getLibraryDirectory de la classe MLet.

Le MBean Server maintient une liste de classe loader dans le repository de classe loader (aussi appelé default loader Repository).

Ce classe loader Repository est utilisé dans les méthodes createMBean et instantiate de l'interface MBean Server : le repository loader repository est utilisé pour trouver et charger les classes.

Si un m-let ne trouve pas les classe à l'URL, il essaie de chargeer les classes du classe loader repository.

Dans le cas où plusieurs MBean Server sont présent dans une même JVM, ils disposent chacun de leurs propres classe loader repository qui sont indépendants les uns des autres.

L'ordre des classes loader dans le repository est important : quand une classe est chargée dans le repository, chaque classe loader est interrogé pour charger la classe. Si un loader réussi à charger la classe alors la recherche s'arrête, sinon (s'il lève une exception ClassNotFoundException) la recherche continue jusqu'à ce qu'il n'y en ait plus (dans ce cas l'exception ClassNotFoundException est levée).

Le premier loader dans la classe loader repository est celui qui a chargé l'implémentation du MBean Server. Se trouve ensuite les loaders des MBeans, l'ordre des loaders étant celui du chargement des MBeans.

Ainsi, on aura, par exemple :

Un MBean m1 apparait avant le MBean m2 si la méthode createMBean ou registerMBean qui a enregistrée m1 s'est terminé avant le démarrage de l'opération qui a enregistré m2. Si la méthode d'enregistrement de m2 a démarré avant la fin de la méthode d'enregistrement de m1, alors l'ordre des loaders est indéterminé.

Un m-let est un classe loader et, comme l'indique le comportement d'un classe loader standard, il charge une classe en utilisant la méthode loadClass :

En premier lieu, il envoie une requête au classe loader parent pour charger la classe (le classe loader parent est celui spécifié lors le m-let est créé (par défaut le classe loader système)), puis, dans un second temps, si le classe loader parent n'a pas pu charger la classe, le m-let tente de la charger dans sa liste d'URL. Enfin, si ces deux essais se soldent par un échec, le m-let tente de charger la classe dans le classe loader repository (dans ce cas, il est dit qu'il délègue au classe loader repository).

Si ces trois tentatives échouent, l'exception ClassNotFoundException est levée.

Pour avoir d'autres informations sur le chargement de classe ainsi que sur les problèmes qui peuvent apparaitre, voir les chapitres 8.4 The Class Loader Repository et 8.5 Using the Correct Class Loader for Parameters des spécifications JMX.