Est-ce que nos outils de packaging actuels peuvent déployer nos applications?

Dans cet article, je souhaite comparer l’automatisation du déploiement au plus connu des processus automatiques du développement logiciel : le packaging de l’application. En simplifiant, le processus de packaging part du code source pour le transformer en code exécutable. La façon la plus simple pour créer ce code est d’utiliser un script shell qui lance le compilateur, mais ce processus a beaucoup mûri. Grâce à des outils comme Make, cité précédemment, mais aussi à Ant et Maven, l’utilisateur peut spécifier de manière très détaillée tout le processus. Prenons l’exemple de Maven, la plupart des projets n’ont plus besoin de scripter quoique soit. Le fichier POM décrit les composants du projet, les plugins utilisés, et la façon de packager l’application. Et en ce moment même, de nouveaux outils font leur apparition, comme Gradle, qui offre encore un peu plus de flexibilité.

Mais ces outils nous permettent-ils de faire du déploiement automatique? Dans un billet précédent, mon collègue Robert van Loghem a expliqué en quoi le déploiement est un processus complexe qui inclut un certain nombre d’étapes comme l’installation des EAR/WAR, la configuration des datasources et le redémarrage des serveurs.
Bien que Wikipedia inclut la fonction de déploiement vers des systèmes en production, lorsqu’il définit l’automatisation du packaging, les outils actuels n’ont pas intégré ces concepts de packages de déploiement (i.e. les livrables), les environnements cibles (test, recette, production, etc.) ou la modification des valeurs selon l’environnement. En réalité, ils n’ont pas de connaissances liées aux middlewares sur lesquels on déploie et ne proposeront certainement jamais des scenarii de déploiement. Au final, ce qu’offrent ces outils, c’est le moyen de scripter, bien connu des développeurs, et de stocker ces scripts avec les sources à installer. Cela amène irrémédiablement à de nombreux scripts « maison » pour automatiser les déploiements.

Mais ce n’est pas tellement surprenant. Dans Wikipedia, les pré-requis d’un système d’automatisation ne mentionnent pas le Déploiement. Un système de déploiement automatique a pour objectif de déployer du code exécutable sur un environnement cible, alors que le système d’automatisation du packaging ne fait que produire ce code exécutable.

Les pré-requis nécessaires pour que notre outil déploie

Voici une liste de pré-requis que devrait satisfaire un outil de déploiement automatique :

• Avoir nativement les concepts de base du déploiement : packages, environnements, lien entre les middlewares, etc.
• Support inclus pour les middlewares principaux avec une possibilité de l’étendre.
• Support inclus pour les scenarii courants de déploiement avec un moyen de les personnaliser.
• Proposer une séparation des rôles : les développeurs livrent le projet, un groupe d’administrateur définit les environnements et un autre groupe déploie l’application, etc.
• Supporter une charge croissante d’environnements avec plusieurs applications et de nombreux utilisateurs.
• Être capable de faire des déploiements multi-plateformes : des environnements complexes peuvent s’étendre sur de multiples systèmes d’opération et versions.

Les outils d’automatisation de packaging ne répondent pas à ces pré-requis et vouloir les étendre ne fera que complexifier leur utilisation sans pour autant faciliter convenablement les déploiements.
Cela explique l’émergence d’outils de déploiement automatique, qui ont dépassé les anciens outils de scripts « maison ».

Que l’on soit bien d’accord, les outils de déploiement automatique ne remplacent pas les outils d’automatisation des packages. Mais les deux ont leur place dans le paysage des livraisons d’applications. Les outils de packaging produisent le code exécutable et les outils de déploiements s’assurent de rendre ce code disponible pour les utilisateurs finaux !

Dans le prochain article de cette série, nous expliquerons en quoi le déploiement automatique est différent du mécanisme de gestion des livraisons de nouvelles versions.

Mais voilà, comme on l’avait rapidement suggéré précédemment, il existe un scénario légèrement plus compliqué que celui décrit ci-dessus ; il s’agit du cas de mise à jour d’une application vers une nouvelle version. Bien que le déploiement initial d’une application soit forcément important, un certain nombre de raisons me fait penser que le déploiement d’une nouvelle version l’est encore plus.

Livrer une nouvelle version est plus important que le premier déploiement !

Voici quelques raisons qui peuvent vous convaincre de porter plus d’attention à une nouvelle livraison:

• Les mises à jour sont plus fréquentes qu’un déploiement initial. ;-)
• Les mises à jour en production ont lieu alors que les utilisateurs sont déjà en train d’utiliser l’application ; il est préférable que cette dernière reste accessible pendant le déploiement ou, au pire, que la coupure soit la plus brève possible.
• Si une mise à jour échoue, l’ancienne version doit toujours être réinstallable.
• Et le fait qu’une mise à jour soit « routinière », peut tromper la vigilance des différentes personnes, responsables du déploiement. Il faut se méfier de l’excès de confiance. Lorsqu’une application est déployée pour la première fois, chacun est très attentif : les développeurs, les administrateurs des différents composants, les architectes, les responsables de projet, les utilisateurs, etc. Donc, quand un problème arrive, il est traité très rapidement. En revanche, si on souhaite déployer la version 2.1.54 un vendredi après-midi, c’est là que tout peut aller de travers.

En résumé, la mise à jour d’une application est complexe, et être concentré permet de diminuer les risques d’échec.

A présent, partons du scénario initial lorsque l’application est déployée. Ce scénario comprenait un fichier EAR, quelques fichiers statiques (images, css, etc.) et des scripts SQL.
Comment allons-nous mettre à jour cette application pour passer en v1.1 ? Pour simplifier, nous imaginons qu’il n’y a pas eu de changements sur le schéma de base de données entre v1.0 et v1.1.
Deux solutions sont possibles : soit nous mettons à jour juste ce qui est nécessaire, il s’agit alors d’un déploiement incrémental, soit nous supprimons la totalité de v1.0 et déployons proprement v1.1, et dans ce cas on fait un redéploiement complet.

Etapes nécessaires à chaque scénario

Si on choisit de simplement mettre à jour, voici les tâches à accomplir :

1. Supprimer le contenu statique v1.0 du serveur web.
2. Arrêter l’application v1.0.
3. Supprimer l’application v1.0.
4. Déployer l’application v1.1 à partir du fichier EAR.
5. Démarrer l’application v1.1.
6. Copier le contenu statique v1.1 sur le serveur web.

Et un redéploiement complet ressemble à ceci :

1. Arrêter le serveur web.
2. Supprimer le contenu statique v1.0 du serveur web.
3. Supprimer la configuration v1.0 du serveur web.
4. Arrêter le serveur d’applications.
5. Supprimer l’application v1.0.
6. Supprimer la configuration du serveur d’applications nécessaire à v1.0 (source de données, queues, etc.).
7. Créer la configuration du serveur d’applications pour v1.1.
8. Déployer l’application v1.1 à partir du fichier EAR.
9. Démarrer le serveur d’applications.
10. Créer la configuration v1.1 du serveur web.
11. Copier le contenu statique v1.1 sur le serveur web.
12. Démarrer le serveur web.

Si on compare les deux scénarii, on note aisément le nombre de différences :

• Le serveur web est arrêté au début et démarré seulement à la toute fin (étape 1 et 12).
• La configuration du serveur web est supprimée avant d’être recréée (étape 3 et 10).
• Au lieu de simplement arrêter puis démarrer l’application, le serveur d’applications complet est arrêté et démarré (étape 4 et 9).
• La configuration du serveur d’applications est elle aussi supprimée puis recréée (étape 6 et 7).

En supprimant puis recréant la configuration du serveur web et du serveur d’applications, nous avons la certitude de connaitre exactement le résultat qu’on obtiendra. En effet, si des changements ont eu lieu dans la configuration qui n’ont pas été notés, ils seront supprimés et non recréés. Pour ce faire, il faut arrêter les serveurs avant de les redémarrer à la toute fin du déploiement. Par contre, cela rend l’application indisponible, mais vous savez de toutes façons qu’il faudra bientôt mettre en place un cluster pour avoir une haute disponibilité, n’est-ce pas ? ;-)

L’autre point intéressant de ce scénario se trouve entre les étapes 7 et 12. Vous aurez certainement noté qu’elles correspondent exactement au scénario du déploiement initial de votre application. La petite différence se situe au niveau des étapes de création du schéma de la base de données. On peut enfin noter que les étapes 1 à 6 permettent de désinstaller complètement l’application.

Résumons maintenant les avantages et inconvénients des deux scénarii.

Du pour et du contre

Dans le cas du déploiement incrémental, on peut retenir les points suivants :

• Pour : Le déploiement incrémental s’exécute très vite car il fait le strict minimum.
• Contre : Le déploiement incrémental laisse éventuellement des traces de modifications manuelles. Ce point est problématique car la configuration a pu être changée de manière « magique » et sûrement non documentée pour que l’application fonctionne. Si vous décidez de migrer sur un autre serveur, vous oublierez probablement ces petites retouches. Et par-dessus tout, nous pouvons imaginer que si cela a été fait sur un des serveurs, et bien … je vous laisse compléter la phrase. :-)
• Pour : Le déploiement incrémental ne touche pas aux systèmes qui sont normalement OK. Mais encore une fois, si vous craignez de toucher votre système parce que ça pourrait ne plus fonctionner du tout, vous avez du travail. Il faut avoir suffisamment confiance dans les composants de votre environnement pour ne pas avoir peur de faire un changement, de redémarrer le serveur et enfin de prier pour que ça re-fonctionne correctement.
• Contre : Il est plus difficile de faire un retour arrière avec un déploiement incrémental. Pour chaque déploiement incrémental, il est nécessaire de décrire le scénario de retour arrière. En effet, comme le précédent déploiement était aussi incrémental, on ne peut donc pas le relancer. Sans scénario de retour arrière, la seule façon de revenir à v1.3 est de faire un déploiement « propre » de v1.0 est de déployer successivement v1.1, v1.2 et enfin v1.3.

A présent, voyons un peu ce que le redéploiement complet apporte comme solutions mais aussi comme difficultés :

• Pour : Le redéploiement complet efface toutes modifications manuelles, ne laissant que la configuration « bien » documentée en place.
• Pour : Le redéploiement complet est reproductible et prévisible. Grâce aux procédures qui sont systématiquement les mêmes, il n’y a aucune importance à connaitre ni la partie du produit qui a changé, ni l’état actuel de l’environnement cible. Ca sera toujours le même résultat.
• Pour : Le redéploiement complet permet d’avoir une stratégie de retour arrière extrêmement simple. Quand le déploiement d’une nouvelle version échoue, ou que la nouvelle application ne fonctionne pas, il suffit de déployer la version précédente.
• Contre : Conserver l’application disponible pendant le déroulement d’un redéploiement complet est une affaire plus délicate que pour un déploiement incrémental. Pour avoir une application en haute disponibilité, il est indispensable de configurer un cluster.
• Contre : Un redéploiement complet peut s’exécuter lentement si l’environnement cible n’est pas assez rapide, car le nombre d’opérations de configuration est important.

Déploiement incrémental, plus sûr que le redéploiement complet ?

Pour ma part, même si le redéploiement complet est parfois plus difficile et plus long à mettre en œuvre, le fait qu’il soit prévisible et reproductible est un avantage décisif qui fait passer les inconvénients au second plan. Le déploiement incrémental peut sembler être une approche plus simple et plus rapide pour déployer des mises à jour, mais vous sacrifiez ce qui est essentiel pour un scénario de déploiement, le processus de retour arrière. L’unique cas où le déploiement incrémental est indispensable, c’est lorsqu’on met à jour une base de données. Dans tous les autres, il est recommandé d’utiliser le redéploiement complet pour appliquer des changements.

Traduction libre du billet « Incremental deployments vs. full redeployments » publié par Vincent Partington sur blog.xebia.com.

Plus d’excuse pour ne pas l’essayer : la nouvelle version de Deployit, solution d’automatisation des déploiements J2EE vient de sortir. Les deux principales nouveautés sont :

• le support du serveur Tomcat : déploiement des archives de type WAR directement ou à travers l’application Manager et la création des DataSources JDBC dans le context.
• l’exécution de scripts SQL lors du déploiement.

Les autres serveurs d’application n’ont pas été oubliés.

• Oracle Weblogic : gestion plus complète des services JMS
• IBM WebSphere : support indifférent d’Apache ou d’IHS, possibilité d’indiquer l’ordre de chargement pour les EAR et WAR, des déploiements accélérés en gardant ouverte la connexion vers wsadmin

et coté système d’exploitation, support du protocole telnet/smb pour les machines de type Windows.

Retrouvez toutes ces nouvelles fonctionnalités dans Deployit Personal Edition. Cette version gratuite possède toutes les fonctionnalités de la version Enterprise, exception faite des aspects sécurité. Elle inclut une licence permettant à un utilisateur unique et identifié d’utiliser l’outil, sans limitations. Deployit Personal Edition inclut en standard des plugins pour Tomcat, IBM WebSphere AS, Oracle WebLogic Server et JBoss AS. Cette version peut être téléchargée gratuitement avec sa documentation et des tutoriels permettant de comprendre son fonctionnement. Cliquer sur le lien suivant : http://www.xebialabs.com/deployit-personal-edition-request. ]]> http://blog.xebia.fr/2010/03/19/deployit-1-2-2-supporte-maintenant-tomcat/feed/ 0 http://blog.xebia.fr/2010/02/04/just-deployit/ http://blog.xebia.fr/2010/02/04/just-deployit/#comments Thu, 04 Feb 2010 13:31:23 +0000 Xebia France http://blog.xebia.fr/?p=3981 Le 1er février dernier, XebiaLabs a mis en ligne une version dite « Personnelle » de « Deployit », sa solution d’automatisation des déploiements J2EE.

Cette version est gratuite et possède toutes les fonctionnalités de la version Enterprise, exception faite des aspects sécurité. Elle inclut une licence permettant à un utilisateur unique et identifié d’utiliser l’outil, sans limitations. Deployit Personal Edition inclut en standard des plugins pour IBM WebSphere AS, Oracle WebLogic Server et JBoss AS. Cette version peut être téléchargée gratuitement avec sa documentation et des tutoriels permettant de comprendre son fonctionnement.

Par ailleurs, avec Deployit Personal Edition, vous avez tout à disposition pour développer vos propres plugins : la documentation de l’API de plugin, les tutoriels et le code source des plugins existants. Enfin, en plus du support technique fourni via le web, notre équipe support peut être contactée gratuitement pendant 90 jours !

Si Deployit Personal Edition permet de bénéficier des avantages de Deployit (y compris en Production), il conviendra d’opter pour la version Enterprise incluant ses fonctionnalités de sécurité, son support technique complet et sa licence multi-utilisateurs dans le cadre d’un environnement plus complexe d’Entreprise.

Deployit Personal Edition peut être obtenue en cliquant sur le lien suivant : http://www.xebialabs.com/deployit-personal-edition-request.

Chez XebiaLabs, nous nous y connaissons en déploiement automatique d’applications Java EE. L’une des choses les plus surprenantes réside dans le fait que «les fournisseurs de serveurs d’application ne semblent pas faire partie des personnes qui maitrisent le mieux le déploiement d’applications».

Dans un article précédent, nous avons décrit ce que nous considérons comme le déploiement d’application J2EE global. Et force est de constater que:

• Déployer va bien au delà d’un simple déploiement d’un EAR ou d’un WAR.
• La plupart des applications ont également besoin d’autres artéfacts comme par exemple du contenu statique pour le serveur web ou encore des fichiers de configuration, utilisés par le code java, au démarrage.
• Il faut également configurer des ressources JEE comme des Datasources JDBC ou des composants JMS (Queues, Topics, Servers).
• A ceci s’ajoute, bien entendu, la configuration du middleware lui-même: création et configuration de clusters de serveurs d’application ou de virtual hosts d’un serveur Apache.
• L’ordre d’exécution des tâches est important afin de réduire (voire de prévenir) la coupure de service de l’application pendant le déploiement et d’en augmenter la vitesse.

Alors posons nous la question. Que nous proposent les fournisseurs de serveurs d’application dans ce domaine ?

Oracle WebLogic Server

Oracle WebLogic Server propose un concept de ‘Deployment’: c’est la chose que vous créez quand vous déployez un EAR, un WAR ou un EJB Jar. Sic ! Vous pouvez l’adapter à l’environnement en fournissant un plan de déploiement. Cependant, rien n’est proposé pour regrouper plusieurs artéfacts JEE dans un seul déploiement ou inclure la création de ressources JEE telle qu’une Datasource.

Dans WebLogic, il y a le concept de ‘SubDeployement’ mais étrangement il n’est pas corrélé à un déploiement. C’est un mécanisme utilisé pour cibler des parties d’un module JMS vers des serveurs JMS ou des serveurs WebLogic. L’artifice proposé par les modules JMS semble destiné seulement à regrouper des ressources JMS. Sans doute qu’un jour un développeur l’a initialement appelé Déploiement sans se souvenir que le concept existait déjà dans WebLogic et il l’a alors renommé SubDeployement. Bien sûr, tout ceci n’est que supputation!

WebLogic propose un grand nombre d’API pour le déploiement: l’historique weblogic.Deployer en ligne de commande, la tâche ANT wldeploy et le WebLogic Scripting Tools, WLST pour les intimes, basé sur Python. Ce dernier est, je pense, le plus complet. Grâce à sa représentation sous forme de système de fichier de la hiérarchie des MBeans, il fournit un moyen très intuitif d’accéder à l’information.

JBoss Application Server

Le déploiement dans JBoss est géré par le Virtual Deployment Framework. C’est un framework basé sur des MBeans qui permet à différents artéfacts (EARs, WARs, EJB JARs, RARs, SARs …) et à différentes ressources (sources de données, paramètres JMS …) d’être déployés sur JBoss. Tout ceci est géré par leurs deployers.

Cependant, la plupart des gens n’invoque pas ces deployers, ni même ‘twiddle‘. Ils préfèrent simplement déposer leurs artéfacts dans le répertoire deploy/ de leur serveur d’application Jboss, puis attendre que le Deployment Scanner le détecte. Ils vérifient ensuite dans le fichier de log que le déploiement est terminé.

Le souci avec cette méthode : le déploiement n’est pas une opération atomique. Quand on automatise un déploiement, on ne veut redémarrer le serveur web qu’après un déploiement réussi du nouveau WAR. Mais écrire un bout de code qui analyse les logs du serveur à la recherche d’un mot clé est tout simplement moche. Une alternative serait de positionner la propriété ScanEnabled du DeploymentScanner à false d’invoquer manuellement le deployer. Non seulement cela complexifie le code, mais il faut également prévoir la copie des fichiers dans le répertoire deploy du serveur JBoss.

Ainsi, il s’avère qu’avec JBoss Application Server, il est difficile d’intégrer des déploiements vers ses serveurs dans un scénario de déploiement plus global. RedHat doit corriger ce problème au plus vite pour que JBoss soit réellement prêt pour les entreprises.

IBM WebSphere Application Server

Et pour le gros monstre JEE de chez ‘Big Blue’ ? Il offre une façon polyvalente et transactionnelle pour déployer des applications et des ressources. Globalement, le langage de script wsadmin permet de contrôler tous les aspects de WebSphere. Par exemple, vous pouvez synchroniser des nœuds explicitement et l’invocation de la méthode (par Jython ou JACL) pour déployer l’application ne rendra la main que lorsque l’opération sera réalisée. Le côté négatif est qu’il est beaucoup plus lent que l’outil similaire WLST proposé par WebLogic (les nombreuses copies de documents XML à travers SOAP doivent y être pour quelque chose) et les API proposées sont plutôt complexes à manipuler (qui peut donner la différences entre un containment path, un configuration id et un object name?)

Bien que WAS ne propose pas de mécanismes pour regrouper les différents artéfacts et ressources liés à un même déploiement, sa nature transactionnelle permet de commiter les différents changements de configuration en une fois. Il peut même gérer la configuration des instances des serveurs IBM HTTP Server ou Apache HTTP Server .

Malgré une vitesse de déploiement lente, rien ne vaut la fiabilité des déploiements de WebSphere !

Conclusion

Les serveurs d’application fournissent chacun un niveau de support différent pour prendre en charge les déploiements des applications d’entreprise. Bien sûr, ils offrent tous le déploiement basique des artéfacts Java EE mais aucun d’entre eux ne propose de regrouper différents artéfacts en un seul déploiement ou de lier des ressources Java EE à ces artéfacts. WebLogic Server est le seul qui essaye de regrouper des ressources (JMS Modules et SubDeployment). Mais ces abstractions ne couvrent qu’une petite partie de toute l’étendue du déploiement Java EE.

La répétition et la prédiction sont très importantes pour une stratégie de déploiement réussie, ce qui peut expliquer la prévisibilité de WebSphere sur le marché. Et finalement, une bonne API est nécessaire pour automatiser votre processus de déploiement: WebLogic et WebSphere l’offrent, JBoss a un sérieux manque dans ce domaine (même avec twiddle !)

Les consultants de Xebia et l’ensemble des développeurs chez XebiaLabs ont quasiment tous écrit dans leurs expériences passées des tonnes de scripts pour automatiser des déploiements et ont dû batailler sur ces questions encore et encore. Nous avons développé Deployit afin de prendre en charge ces différences entre serveurs d’applications et parce que nous croyons que l’automatisation des déploiements est de la plus haute importance du fait du nombre croissant de déploiements dans les entreprises.

–
Traduction libre du billet «Do application server vendors really understand deployment? » publié par Vincent Partington.

Michel, qui a l’habitude de ce genre d’exclamation vis-à-vis de l’organisation des réseaux d’entreprise, explique calmement que toutes les requêtes partant d’un navigateur doivent d’abord passer par un serveur HTTP avant d’être redirigées vers le serveur d’applications. « Il est donc aussi nécessaire de configurer Apache ! », dit-il. « Mais je développe une application Java, j’ai juste besoin de déployer sur un serveur d’applications et hop, terminé ! » répondez vous. Et Michel d’expliquer sur un ton très sérieux : « Écoute fiston, appuyer sur le bouton de déploiement de ta console d’administration est juste une petite étape parmi toutes celles qui permettent de réaliser un vrai déploiement. »

Rendre l’application accessible à l’utilisateur final

Avant de parler des différentes étapes du déploiement, il est important de comprendre quel est l’objectif d’un déploiement. De façon élémentaire, le but d’un déploiement est de « rendre une application, dans une version donnée, disponible pour les utilisateurs finaux ». En d’autres termes, l’utilisateur ouvre son navigateur, tape www.app.com et voit l’application fonctionner.

Alors, que faut-il faire pour qu’une application fonctionne? Pour comprendre les composantes du déploiement, le plus simple est de suivre la requête depuis le navigateur de l’utilisateur à travers tous les composants matériels et logiciels par lesquels elle transite.
« La destination de la requête est tout d’abord résolue en s’adressant à un serveur DNS (ou à un mécanisme équivalent). La requête est alors routée vers sa destination ; elle est filtrée par un premier firewall, arrive sur le serveur HTTP chargé de la répartition de charge, traverse un nouveau firewall, atteint le serveur d’applications puis enfin l’application à proprement parler, exécutée sur le serveur, qui elle-même interroge une base de données pour récupérer les informations demandées par l’utilisateur. »
Sur cet exemple simple, il y a au moins 5 composants en action pour rendre disponible l’application ; nous devons non seulement configurer ces 5 composants mais aussi y placer certaines données et s’assurer au besoin qu’ils (re-)démarrent dans un ordre correct.

Voici typiquement les étapes nécessaires au premier déploiement d’une telle application sur un environnement de production :

• (a) Exécuter les ordres SQL de création de tables sur la base de données
• (b) Configurer la source de données JDBC dans le serveur d’applications
• (c) Configurer les ports HTTP et les Virtual Hosts dans le serveur d’applications pour que l’application soit accessible par les requêtes HTTP
• (d) Installer l’application sur le serveur d’applications
• (e) Démarrer l’application
• (f) Configurer le firewall, en ouvrant les ports utiles à la communication entre le serveur HTTP et le serveur d’applications
• (g) Configurer le serveur HTTP, pour router vers le serveur d’applications les requêtes arrivant sur www.app.com et qui ne se terminent pas, par exemple, par .js, .html, .jpg
• (h) Déposer le contenu HTML statique (fichiers js, fichiers css, images, etc.) sur le serveur HTTP
• (i) (re-)Démarrer le serveur HTTP pour prendre en compte la nouvelle configuration
• (j) Configurer le firewall externe, pour permettre les accès de www.app.com vers le bon serveur HTTP

Bien sûr, dans un environnement plus complexe, on ajoute quelques étapes à la liste. Par exemple, dans un environnement clusterisé avec haute disponibilité, tout doit être fait au moins deux fois. Pour les déploiements de versions ultérieures de la même application, certaines étapes pourront de surcroît être négligées.

Des tâches nombreuses et variées

Les étapes décrites dans la section précédentes permettent de « mettre à disposition des utilisateurs » une application à l’architecture élémentaire. D’une façon plus générale, on peut distinguer plusieurs grandes catégories d’opérations à réaliser pour finaliser un déploiement :

• Installer l’application (Étape d)
  C’est la partie principale du déploiement, où la logique métier est installée sur le serveur, le plus souvent sous la forme d’un fichier EAR ou WAR.
• Configurer les ressources externes (Étape b)
  L’application peut avoir besoin d’interagir avec d’autres systèmes, comme une base de données, un mainframe ou un middleware de message. Les ressources externes sont le plus souvent utilisées par l’application pour obtenir ou diffuser des données. L’accès à ces ressources est généralement configuré au niveau du serveur d’applications.
• Configurer les composants intermédiaires (Étape a, c, f, g, h, j)
  Ce sont les composants qui permettent d’atteindre l’application, et de l’exécuter (par exemple, un cluster de serveurs d’applications, des instances de serveurs HTTP, des firewalls, etc.).
• Démarrer/Arrêter les composants (Étape e, i)
  Pour s’assurer que chaque composant fonctionne correctement, il peut être nécessaire de le (re-)démarrer.
• Et respecter l’ordre dans les points précédents

Pour être sûr que l’application démarre correctement, sans erreurs, un certain ordre doit être maintenu. Exemple : Si vous installez l’application (Étape d) et la démarrez avant d’avoir configuré la source de données (Étape b), l’application risque de ne pas se lancer correctement. Ceci devient encore plus important lorsque vous déployez une nouvelle version de votre application dans un environnement clusterisé.

Il y a une catégorie supplémentaire pour les organisations qui valident leurs applications successivement sur plusieurs environnements (Développement, Test, Intégration, Production) :

• Configurer l’application installée sur des environnements différents
  Un déploiement doit assurer la configuration spécifique à l’environnement. Exemple : Quand vous installez une application sur l’environnement de développement, il faut récupérer les données de la base de développement. De la même façon, pour l’environnement de tests, il est nécessaire d’avoir les données de tests et ainsi de suite.

L’EAR, la partie émergée de l’iceberg

Beaucoup pensent qu’installer un EAR sur un serveur d’applications équivaut à déployer l’application. Bien sûr, le bouton dans la console d’administration indique : « Déployer l’application », mais il ne s’agit que de la partie concernant le serveur d’applications à proprement parler ; cette vision étroite du déploiement n’est généralement opérationnelle que sur un environnement simplifié, comme celui de développement ou sur le poste de travail du développeur. Dès qu’une application doit être installée sur un environnement plus complexe, cette vision ne suffit plus et il devient nécessaire de réaliser un grand nombre d’opérations complémentaires pour véritablement « mettre l’application à disposition des utilisateurs ».

Parce que de ce point de vue le déploiement n’est pas une opération triviale, beaucoup cherchent à l’automatiser.
Exécuter manuellement toutes les étapes est en effet à la fois complexe et risqué, particulièrement sur les environnements les plus critiques. Et ce, d’autant plus que, souvent, les responsabilités et les gouvernances de chaque module de l’infrastructure reposent entre les mains de personnes, d’équipes, voire de départements différents.
Malheureusement, cet effort d’automatisation aboutit souvent à un ou plusieurs jeux de scripts à la gouvernance floue et dont le coût de maintenance semble souvent prohibitif. Les solutions du marché n’abordent souvent qu’un sous-ensemble de la problématique (on pense à Phurnace ou BuildForge, qui restent concentrés sur le serveur d’applications, ou à d’autres solutions qui sont souvent de simples ordonnanceurs de scripts).
Avec les serveurs d’intégration continue, on peut mettre en œuvre des déploiements automatiques, qui permettent de tester la chaîne complète de la compilation jusqu’aux tests de charge (cf. Build Pipelines). Et si l’on veut aller encore plus loin, c’est-à-dire déployer automatiquement sur l’environnement de production, on peut se pencher sur le logiciel DeployIt, développé par mes collègues Hollandais.

Je parlerai, plus en détail, dans un prochain article du déploiement automatique et nous pourrons déterminer par nous-même si c’est une solution « Insane » comme le pense le livre blanc Enterprise CI Maturity Model de la société anthillpro ou une solution réelle pour améliorer la fiabilité comme le pense DeployIt.

Intervenants :

• M. Guillaume Bodet, Directeur Technique, Xebia

Informations utiles :

• Adresse : L’Atelier – 14, Rue Bergère – 75009 Paris
• Date : Jeudi 8 Octobre 2009 à 9h00
• Durée : 2H00
• Inscription: http://www.atelier.fr/inscriptionEvenement.php?artid=38668

Erreurs humaines, interventions « pompier », manque de prédictibilité, complexité des guides et procédures de mise en production, manque d’évolutivité des scripts, frictions entre les départements Etudes et Production, mises à jour des middleware et des applicatifs coûteuses sont autant de maux que rencontrent les utilisateurs des technologies Java/J2EE.

Fort de nos 8 ans d’expérience dans la conception, la mise en place et la gestion d’applications et d’infrastructures basées sur Java/J2EE chez plus de 200 clients en Europe, Xebia a créé DeployIT, une offre logicielle, exclusivement dédiée aux déploiements Java/J2EE.

DeployIT permet de sécuriser et de réduire les coûts des déploiements des applications et des infrastructures Java/J2EE, jugés de plus en plus périlleux, coûteux et aléatoires.

Xebia Labs propose donc une plateforme logicielle incluant les spécificités des applications et infrastructures Java/J2EE, adossée à une approche méthodologique éprouvée, offrant les avantages suivants :

• Réduction des risques d’échecs des déploiements liés aux trop nombreuses interventions humaines.
• Réduction des coûts liés au développement et à la maintenance de scripts coûteux et hétérogènes.
• Suppression des interventions « pompier » des équipes de développement pour aider les cellules d’exploitation à mettre en production.
• Réduction du Time to Market des nouvelles applications ainsi que de leurs évolutions fonctionnelles.
• Standardisation autour d’un outil commun des départements Etudes et Production.
• Garantie des SLA par une professionnalisation de la filière de déploiement.

Pour avoir plus d’informations sur cette solution, n’hésitez pas à contacter Luc Legardeur au 01 42 91 27 93 ou par mail : llegardeur@xebia.fr.

Une conférence est l’occasion de discuter avec les ingénieurs des difficultés que nous rencontrons à utiliser leurs produits. J’ai profité de ma participation à SpringOne 2009 pour échanger avec Mark Thomas sur le suivi de l’adresse IP des internautes dans les logs d’audit d’applications web. Mark Thomas est des principaux committer du projet Tomcat et de SpringSource tc Server.

Le problème se présente lorsqu’un serveur Tomcat est précédé d’un reverse proxy (e.g. mod_proxy, Squid Cache, etc) ou d’un load balancer (Nortel Alteon, F5 Big-IP, etc) : La méthode HttpServletRequest.getRemoteAddr() ne retourne plus l’adresse IP de l’internaute mais celle du composant réseau qui précède le serveur Tomcat.

Cette perte d’information a été compensée par les reverse-proxy en ajoutant un header http X-Forwarded-For à toutes les requêtes qu’ils font transiter. Bien que ce header ne soit pas standard (son nom commence d’ailleurs par « X- »), il est devenu un standard de facto utilisé par la très grande majorité des reverse proxy et load balancers (paramètre xforward=enable pour les Alteon d’après Command Reference ; propriété Insert XForwarded For de la GUI du profile http ou règle when HTTP_REQUEST { HTTP::header insert "X-Forwarded-For" [IP::client_addr] } pour les Big-IP d’après F5 Dev Central : Using « X-Forwarded-For » in Apache or PHP ).

Cependant, les implémentations de l’API Servlet ne sont pas tenues de prendre en compte ce paramètre dans la méthode request.getRemoteAddr() dont la javadoc stipule bien Returns the Internet Protocol (IP) address of the client or last proxy that sent the request. . Tomcat est d’ailleurs autant concerné que ses concurrents Websphere ou Weblogic, pour ne citer qu’eux.

Toutes les couches sont impactées : l’Access Log Tomcat dont les patterns common et combined utilisent le remote host name (%h) et les frameworks de sécurité et d’audit comme Spring Security (cf WebAuthenticationDetails.getRemoteAddress()) ou CAS Inskektr ClientInfo).

Access Log Tomcat et Apache Httpd : modification du pattern de log

Pour corriger l’access log Tomcat, il est possible de configurer l’utilisation du header X-Forwarded-For plutôt que de l’ip distante dans le pattern de log (pratique relativement bien documenté).

...
<Valve className="org.apache.catalina.valves.AccessLogValve" directory="logs" prefix="localhost_access_log."
       suffix=".txt" pattern="%{X-Forwarded-For}i %l %u %t %r %s %b" resolveHosts="false" />
...

Si les serveurs Apache Httpd sont précédés d’un load balancer, la modification est très similaire, mod_log_config permet de définir les informations affichées dans l’accès log. On modifie la pattern de log pour utiliser le header http X-Forwarded-For ( %{X-Forwarded-For}i ) plutôt que le remote host ( %h) :

LogFormat "%{X-Forwarded-For}i %l %u %t "%r" %>s %b" common
CustomLog logs/access_log common

La prise en compte du header X-Forwarded-For dans Apache Httpd sera bientôt simplifiée avec la récente introduction dans le trunk du module mod_remoteip qui permettra de prendre en compte ce header avec une simple configuration RemoteIPHeader X-Forwarded-For ; il ne sera plus nécessaire de manipuler le pattern des logs.

Frameworks Java : extension des applications ou du moteur de servlet

S’il est simple de prendre en compte le paramètre X-Forwarded-For dans les access log Tomcat et Apache Httpd, il est sensiblement plus complexe de l’intégrer dans les frameworks de sécurité et d’audit. Ces briques sont souvent des librairies tierces et modifier leur code est fastidieux voire impossible si elles sont ‘close source’. Il est donc nécessaire de se placer en amont de ces frameworks pour modifier le comportement de la méthode ServletRequest.getRemoteAddr().

Servlet API : XForwardedForFilter

La première solution est de développer un Servlet Filter que l’on déploie dans chaque web application.

• Avantage : Simple à implémenter grâce aux interfaces Filter, HttpServletRequest et à l’HttpServletRequestWrapper qui est destiné à faciliter ce type de développement, ce Filter est utilisable aussi bien avec Tomcat qu’avec Glassfish, JBoss, Jetty, WebSphere, Weblogic ou tout autre moteur de servlet.
• Inconvénient : lourd à déployer sur toutes les web applications.
• Exemple d’implémentation: XForwardedFilter (XForwardedFilter.java) gère les headers X-Forwarded-For et X-Forwarded-Proto

Pour installer cette solution :

1. Télécharger xebia-servlet-extras-1.0.2.jar, compiler XForwardedForFilter.java et déployer le jar sous WEB_APP_HOME/WEB-INF/lib ou ajouter la dépendance maven fr.xebia.web.extras:xebia-servlet-extras:1.0.2 à votre pom.xml (doc).
2. Déclarer dans web.xml le filter XForwardedFilter :

...
   <filter>
      <filter-name>XForwardedForFilter</filter-name>
      <filter-class>fr.xebia.servlet.filter.XForwardedFilter</filter-class>
   </filter>
   <filter-mapping>
      <filter-name>XForwardedFilter</filter-name>
      <url-pattern>/*</url-pattern>
      <dispatcher>REQUEST</dispatcher>
   </filter-mapping>
   ...

1. Tester le résultat avec x-forwarded-for_as_remote-addr.jsp, le résultat devrait ressembler à x-forwarded-for_as_remote-addr.jpeg.

Extension Tomcat : RemoteIpValve

La deuxième solution est d’ajouter une extension au serveur Tomcat pour en modifier le comportement ; il ne s’agit plus alors de Servlet Filter et d’HttpServletRequest mais de Valve et de Request :

• Avantage : solution centralisée gérée par l’administrateur Tomcat sans intrusion dans les web applications. Cette solution permet de traiter dans le même temps l’AccessLogValve.
• Inconvénient : intégré à Tomcat seulement depuis la version 6.0.24 ; pour les version antérieures, il faut déployer un jar additionnel.
• Exemple d’implémentation : RemoteIpValve.java gère les headers X-Forwarded-For et X-Forwarded-Proto
• RemoteIpValve.java a été intégré au projet Tomcat Bug 47330 – proposal : port of mod_remoteip in Tomcat as RemoteIpValve et est documentée sur GoogleCode : RemoteIpValve

Pour installer cette RemoteIpValve :

1. Pour les versions de Tomcat antérieures à la 6.0.24, télécharger xebia-tomcat-extras-1.0.0.jar, compiler RemoteIpValve.java et déployer le jar sous TOMCAT_HOME/lib.
2. Déclarer la RemoteIpValve dans server.xml :

...
   <Valve className="org.apache.catalina.connector.RemoteIpValve" />
   <Valve className="org.apache.catalina.valves.AccessLogValve" directory="logs" prefix="localhost_access_log."
      suffix=".txt" pattern="common" resolveHosts="false" />
   ...

1. Tester le résultat avec x-forwarded-for_as_remote-addr.jsp, le résultat devrait ressembler à x-forwarded-for_as_remote-addr.jpeg.

Mark Thomas reconnaît l’intérêt de faciliter le développement d’extensions pour Tomcat et la tâche devrait grandement se simplifier avec le projet Convert current Tomcat valves to Servlet Filters for The Apache Software Foundation du Google Summer of Code 2009. Cette évolution ouvre la perspective de développer des filtres d’infrastructure similaires aux modules écrits en C pour Httpd mais avec la souplesse du langage Java.

Pour aller plus loin

• Apache Httpd mod_proxy : Reverse Proxy Request Headers
• Squid Cache : forwarded_for configuration parameter
• Xebia-france Google Code : RemoteIpValve

2009/05/17 : Ajout des paramètres de configuration des Alteon et BIG-IP pour activer l’insertion du header x-forwarded-for
2009/07/12 : Mise à jour du paragraphe sur la Valve tomcat pour utiliser la RemoteIpValve
2009/07/17 : Mise à jour du paragraphe sur le servlet filter XForwardedFilter
2009/10/13 : Montée de version de xebia-servlet-extras en version 1.0.1 pour corriger le bug soulevé par Alexandre Victoor
2009/11/08 : Ajout de la remarque préliminaire : la valve et le filtre ont été intégrés dans le projet Tomcat.
2010/01/24 : Mise à jour de l’article pour prendre en compte la disponibilité de la RemoteIpValve dans la distribution standard Tomcat depuis la version 6.0.24.
2010/01/31 : Montée de version de xebia-servlet-extras en version 1.0.2 pour corriger Issue 4 – XForwardedFilter : request.secure and request.scheme are not forced to « false » and « http » if X-Forwarded-Proto=http.

Tout d’abord, nous ferons un point sur les problèmes posés par la gestion des bases de données, puis nous verrons comment Liquibase, outils de refactorisation, peut nous aider à les surmonter.
Nous continuerons par la description de ses caractéristiques et fonctionnalités principales et par les différents moyens de l’exécuter.
Un petit exercice pour se familiariser avec cet outil viendra conclure ce billet.

Problèmes posés par la gestion des bases de données

Lorsqu’un projet démarre, on se demande souvent si l’on doit installer une base de données par développeur ou une base commune pour tous.
Sur des projets de taille réduite, une base peut suffire et une personne est désignée pour centraliser les changements et éviter ainsi des problèmes de redondance, d’incohérence, etc. Mais dans ce cas-là, dès qu’un changement est effectué, tout le monde doit impérativement mettre à jour le modèle objet sinon il court le risque de ne plus pouvoir lancer l’application. Par ailleurs, les jeux de tests de chaque développeur peuvent « se télescoper » ce qui peut faire perdre beaucoup de temps.
Sur des projets plus importants, il est préférable d’avoir une base par développeur, ce qui cause d’autres difficultés, telles que les répercutions des changements d’un développeur à l’autre ou encore une intégration plus laborieuse.
Se pose aussi la question suivante : comment va-t-on tracer les changements successifs ? Le plus courant reste d’écrire un fichier d’update SQL mais ce n’est pas fait systématiquement pendant les développements et ça manque de structure (au sens XML) et ça pas de signification propre. Par exemple, rien ne permet rapidement de différencier dans un script, le code qui applique les changements de celui qui les rollback (à part les commentaires !); ou les actions comme « Renommer » se traduisent par un DROP COLUMN / ADD COLUMN, ce qui fait perdre le sens de l’action.
Cette dernière question amène à s’en poser d’autres :

• comment versionner les changements effectués sur une base de données ?
• comment appliquer les changements ? Entre développeurs, mais aussi lorsqu’on passe en intégration, puis en recette, etc. Pour le moment, cette étape prend du temps, que ce soit en amont si on décide de packager correctement les changements, ou en aval lorsqu’il s’agit de dérouler les scripts.

Voilà en quelques phrases les multiples difficultés rencontrées lorsqu’on souhaite refactoriser une base de données.
Regardons à présent ce qu’un outil comme Liquibase peut faire pour nous accompagner dans ce travail délicat.

Refactorisation de bases de données avec Liquibase

Liquibase est un outil qui peut s’intégrer dans un projet (Ant, Maven, etc.) ou se lancer en mode standalone directement en ligne de commande (jar).
Son objectif est de faciliter les modifications apportées à une base de données. Il est particulièrement pratique dans des projets ayant adoptés une méthodologie Agile, car les changements sont nombreux, fréquents et importants.
Le développeur enregistre dans un fichier XML (changelogs.xml), les différentes refactorisations qu’il souhaite effectuer (création d’une nouvelle table, renommage d’un champ, insertion de données, etc.). Ensuite, il suffit de lancer Liquibase en lui donnant les paramètres de connexion à la base de données et le fichier changelogs.xml. Liquibase applique ces modifications et les trace dans une table.
Les fichiers changelogs.xml sont versionnés dans le gestionnaire de sources, et sont considérés comme n’importe quelle autre ressource du projet. La base de données est alors complètement intégrée au cycle de développement.

Après cette brève présentation de Liquibase, intéressons-nous aux caractéristiques principales de cet outil.

Caractéristiques et fonctionnalités principales

Liquibase est Open Source diffusé sous licence LGPL. Ce projet Open Source est actif, la dernière version (1.8.1) est sortie en octobre 2008 et sa road map montre qu’il veut aller encore plus loin. Il supporte un grand nombre de bases de données (> 10) et propose plus de 30 refactorisations possibles. Et pour certaines, il sait même faire un roll back (Ex: renommer une colonne).
Les changements peuvent être regroupés dans un changeset, ce qui permet de conserver un sens et une cohérence aux modifications.
On peut également n’exécuter des changements que sous certaines conditions, ou selon un certain profil d’exécution (utile pour les jeux de tests par exemple).

On peut noter également que Liquibase n’est pas juste « braqué » vers la refactorisation de la base de données, il offre d’autres fonctionnalit

Les 10 commandements des logs applicatives

Tout au long du cycle de vie d’une application J2EE, il est nécessaire de posséder des traces de qualité :

• durant le développement, afin de suivre l’exécution pas à pas et de détecter d’éventuelles anomalies.
• durant la recette, afin de corréler anomalies fonctionnelles et exécution du programme.
• durant l’exploitation, afin de surveiller la « bonne santé » de l’application.

Mais obtenir des traces de qualité n’est pas un exercice trivial. C’est pourquoi nous vous proposons nos 10 commandements des logs.

Lire cet article »

Simplifiez votre configuration Spring 2.5 avec les annotations

Spring 2.5 est sorti depuis le 19 novembre 2007 comme nous l’annoncions, il y a quelques temps, dans notre revue de presse. Vous avez comme moi sagement mis à jour vos poms Maven2 vers la dernière release de Spring (normalement et la plupart du temps compatible avec les versions 2.0.x).

Mais avez-vous vraiment profité des nouveautés de cette version en terme de configuration ?

Lire cet article »

Programmation concurrente : notions fondamentales

Jouer avec les Threads n’est pas trivial. En informatique de gestion, cette difficulté est heureusement masquée par les serveurs d’application et les API spécifiques. La plupart du temps, ils permettent aux développeurs de s’abstraire de ces contraintes et de se concentrer sur le code métier, moins technique. Il arrive pourtant qu’il faille se relever les manches. Certains besoins vous ont certainement déjà poussé à faire communiquer 2 Threads.
Si le développement n’est pas facile, le debug peut devenir une calamité ! La programmation concurrente ne soulève pourtant que 3 types majeurs de problèmes. Faites le sondage autour de vous, les développeurs associent trop rapidement le mot clé synchronize au multithreading sans en comprendre véritablement le fonctionnement. Demandez-leur ensuite de vous décrire l’utilité du mot clé volatile …

Cet article revient sur les grands principes de la programmation concurrente.

Lire cet article »

• durant le développement, afin de suivre l’exécution pas à pas et de détecter d’éventuelles anomalies.
• durant la recette, afin de corréler anomalies fonctionnelles et exécution du programme.
• durant l’exploitation, afin de surveiller la « bonne santé » de l’application.

Mais obtenir des traces de qualité n’est pas un exercice trivial. C’est pourquoi nous vous proposons nos 10 commandements des logs.

Une application J2EE possède de nombreux types de logs :

• Des logs purement techniques, ponctuelles, générées automatiquement ou à la demande comme les dumps (ThreadDump, MemoryDump…).
• Des logs provenant de l’environnement d’exécution : logs Système (journaux d’évènements serveur…), logs du serveur applicatif et logs générées par les librairies tierces utilisées par l’application.
• Les logs générées par le code développé pour l’application, que nous désignerons comme logs applicatives, sur lesquelles l’équipe projet a la main.

Nous traiterons quasi exclusivement de ces dernières dans cet article.

Les 10 commandements

1. Les logs sont un outil collaboratif issu d’un processus itératif.
2. Les logs sont une brique applicative intégrée à l’environnement d’exécution de l’application.
3. Les logs sont paramétrées en fonction des besoins.
4. Les logs doivent avoir un impact minimal sur les performances globales de l’application.
5. Les logs ne doivent pas occasionner de perte d’information.
6. Une utilisation correcte du logger est la première source d’information.
7. L’utilisation du framework de logs doit être simplifiée.
8. Une log efficace doit remplacer le debugger.
9. Le framework mis en place doit servir exclusivement à produire des logs applicatives.
10. Les logs permettent de décrire le comportement aux frontières de l’application.

Entrons dans le détail

1 – Les logs sont un outil collaboratif issu d’un processus itératif

Les messages de logs sont destinés à tous les acteurs du projet.
Il est essentiel de garder à l’esprit, lors de de tout développement, qu’une application est vouée à être développée, puis testée, puis exploitée (et éventuellement corrigée). Les logs doivent prendre en compte ces 3 phases de la vie du projet, et permettre à tous les acteurs intervenant lors de ces différentes phases de pouvoir interagir efficacement.
C’est pourquoi chaque méthode devrait au minimum contenir des traces de niveau INFO, WARN et ERROR, chaque niveau ciblant un des acteurs intervenant sur l’application.
De plus, il est difficile de réaliser une ‘bonne’ log du premier coup. La pertinence de celle-ci sera renforcée par des échanges constants entre exploitation et développement (ciblage spécifique d’un problème de performance, anomalie non remontée initialement…).
Chaque correction d’anomalie devrait entrainer l’ajout de traces de niveau DEBUG, qui permettront un diagnostic plus fin en cas de nouvelle occurrence.

2 – Les logs sont une brique applicative intégrée à l’environnement d’exécution de l’application

C’est pourquoi il est essentiel de choisir un framework de logs bien intégré dans le middleware utilisé en production.
Ce framework doit pouvoir être utilisé et paramétré aisément pour obtenir des traces de l’ensemble des composants du système, que ce soit de la part de librairies embarquées tierces comme des systèmes ‘contenants’ (serveur d’application par exemple).
Par exemple, Jakarta Commons Logging est délicat à utiliser avec Websphere.

3 – Les logs sont paramétrées en fonction des besoins

L’écriture d’une log a un coût qu’il ne faut pas négliger. Les performances d’une application en production ne doivent pas être plombées par la génération de lignes de log inutiles. Et il est inenvisageable de demander à chaque développeur d’effacer systématiquement les logs qu’il ajoute (si ces logs ont été utiles à un moment de la vie du projet, il y a de grandes chances qu’elles puissent resservir plus tard).
Il est donc impératif de choisir un framework de logs facilement administrable autant en développement qu’en production :

Pour le développement :

• Une configuration de logs par défaut quand on fait un checkout du code (typiquement un fichier log4j.properties dans le classpath configuré au niveau WARN qui redirige vers System.out).
• La possibilité de modifier à chaud la configuration des logs lors de l’éxécution de l’application dans l’IDE (typiquement un configureAndWatch sur classpath:log4j.properties).

Pour l’exploitation :

• Une configuration par fichiers, séparée du WAR, ce qui permet de livrer / modifier l’application indépendamment de sa configuration (et vice et versa).
• Des mécanismes de reconfiguration à chaud par modification de fichier et/ou par API (JMX).

On se doit d’exploiter au maximum les différents Appenders.
Le système d’Appender fourni avec les principaux framework de log permet de gérer finement la persistence de la trace : elle peut être éphémère, par exemple dans une sortie Console, ou bien être archivée périodiquement, en utilisant un système de DailyRollingFileAppender.
Une bonne connaissance des Appenders est essentielle dans la gestion à long terme de la log, aussi bien en terme de performance (utilisation des Loggers asynchrones en utilisant JMS) qu’en terme d’espace disque (configurer correctement les FileAppenders afin que les fichiers restent exploitables).

4 – Les logs doivent avoir un impact minimal sur les performances globales de l’application

La majorité des frameworks de log disposent de méthodes conditionnelles de type log.is<Priority>Enabled(). Conditionner l’écriture de la log par ces méthodes permet d’économiser des ressources précieuses lors du runtime (construction d’une aggrégation de chaînes de caractères par exemple). La méthode log.<Priority>(String) effectue bien entendu le même test, mais après la résolution des paramètres.

Evitez :

log.debug("Entrée dans la méthode doIt(), avec param1[" + param1 + "], param2 [" + param2 + "]");

Préférez :

if(log.isDebugEnabled() {
   log.debug("Entrée dans la méthode doIt(), avec param1[" + param1 + "], param2 [" + param2 + "]");
}

5 – Les logs ne doivent pas occasionner de perte d’information

Ce commandement s’applique plus particulièrement aux logs des exceptions.
Il est primordial de qualifier le plus finement possible les exceptions tracées.
C’est pourquoi on privilégiera systématiquement les méthodes Logger#error(java.lang.Object message, java.lang.Throwable t) à Logger#error(java.lang.Object message) , afin de ne pas perdre les informations exposées par la stackTrace.
De plus, on explicitera au maximum le contexte d’exécution dans le message.

Evitez :

...
} catch (UnknownUserException exception) {
   log.error("Une exception s'est produite :" + exception);
   ...
}
...

Préférez :

...
catch (UnknownUserException exception) {
   log.error("L'utilisateur [" + user :"] n'a pas été trouvé dans l'annuaire ["+ myLdap + "]", exception);
...
}
...

NB : le traitement des exceptions fera l’objet d’un prochain article.

6 – Une utilisation correcte du logger est la première source d’information

Chaque niveau de log a ses spécificités. Bien définir l’utilisation de chacun de ces niveaux permet de s’affranchir du risque de logger trop, ou trop peu, aux différentes étapes du cycle de vie de l’application. Utiliser des niveaux de log cohérents et pertinents donne donc un premier niveau d’information essentiel.
Voici les niveaux existants dans les différents frameworks, et leur utilisation communément admise (Log4J/Apache Commons Logging – java.util.logging) :

• TRACE / FINE : niveau d’information ultrafin.
• DEBUG / CONFIG : information détaillée pour le suivi d’exécution du programme (identification et résolution d’éventuelles anomalies).
• INFO : information essentielle sur le programme, suivi de l’exécution d’un point de vue global.
• WARN / WARNING : situation d’exécution non idéale (utilisation d’API dépréciées, ressource non critique absente…).
• ERROR / <pas d’équivalent> : situation d’erreur ou inattendue, qui n’entraine pas forcément une situation de blocage (accès à un service externe non critique et dont l’accès est re-testé périodiquement).
• FATAL / SEVERE : situation d’erreur critique, qui entraîne un blocage voire un arrêt du système (problème de connexion à la DB par exemple).

7 – L’utilisation du framework de logs doit être simplifiée

L’ajout de log doit être le moins contraignant possible pour les développeurs. De plus, dans le cadre d’une équipe de développement, il n’est pas toujours facile pour un développeur de savoir quelles sont les informations pertinentes à tracer, s’il n’est pas l’auteur de la classe suivie. Il faut donc faciliter la création de logs de qualité…

• … en rendant ses classes explicites.
  En surchargeant la méthode Object#toString(), afin qu’elle renvoie les informations principales d’une classe, on peut facilement tracer les informations en entrée ou sortie de méthode, et expliciter le contexte applicatif de l’exécution. Attention, les méthodes toString() ne doivent jamais lancer d’exception.

Evitez :

public String toString(){
   StringBuilder sb = new StringBuilder();
   sb.append(getClass().getName())
   // Ici, on peut avoir une NullPointerException
   sb.append(" myfield=[").append(this.myfield.toString()).append("]");
   return sb.toString();
}

Préférez :

public String toString(){
   return new ToStringBuilder(this).append("myfield", this.myfield).toString();
}

• … en définissant, documentant et partageant la hiérarchie de logger
  L’utilisation la plus répandue de la hiérarchie de Logger consitste à déclarer un logger par classe.

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

Cependant, il est souvent interessant de réfléchir à une hiérarchie plus poussée, par domaines technico-fonctionnels par exemple.
Il est parfois même utile de déclarer plusieurs Loggers par classe (un logger pour le suivi de l’exécution générale, un logger particulier pour surveiller une fonction critique)
Afin d’avoir des logs cohérentes, il est nécessaire de définir et de documenter la hiérarchie des Loggers au plus tôt de la vie du projet, et de la communiquer à l’ensemble des équipes, afin d’unifier les méthodes de logging.

8 – Une log efficace doit remplacer le debugger

Il existe un grand nombre de circonstances qui rendent impossible l’utilisation d’un debugger, dont la plus évidente, la nécessité de debugger un système en production. Mais on pourrait aussi citer les traitements multi-threadés, etc
Dans ces cas particuliers, l’utilisation de la log doit se substituer au débuggeur, et répondre aux mêmes besoins : « exécution » pas à pas des algorithmes, inspection des valeurs d’entrée et de sortie des points de passage clefs, parcours des différentes couches de l’application, surveillance des entrées / sorties du système.
La mise à disposition d’un tel outil est vitale pour les développeurs, car trop souvent, les équipes de développements sont dans l’obligation d’attendre plusieurs occurrences d’un même bug en production avant d’être aptes à déterminer ses conditions précises d’occurrence.

9 – Le framework mis en place doit servir exclusivement à produire des logs applicatives

Les logs sont et doivent être un outil technique. Utiliser le framework de log pour générer des traces ‘fonctionnelles’ (audit, génération de traces métier, constitution de fichiers métier) présente un risque majeur de perte de données. En effet, le risque d’effacement des logs est réel : la configuration des différents Appenders provoquent souvent un effacement périodique des logs, le comportement global des logs peut être totalement modifié dans le cadre d’une intervention de type ‘troubleshooting’ (limitation des traces à un sous-ensemble de classes très restreint)…
En revanche, il est possible d’utiliser les fonctionnalités offertes par le framework de logs (RollingFileAppender, etc) mais il faut que cette utilisation soit dissociée du fonctionnement et de la configuration des logs applicatives.

10 – Les logs permettent de décrire le comportement aux frontières de l’application

L’un des enjeux majeurs des Systèmes d’Information actuels est l’intégration des différentes composantes de ce SI.
Il est très souvent ardu de suivre intégralement la chorégraphie entre les différents composants, aboutissant à la réponse ‘finale’ du système.
D’où la nécessité de tracer le plus finement chaque appel entrant ou sortant du système, en utilisant :

• l’heure de cet appel
• le système appelant / appelé (par HTTP, JMS, SOAP…)
• une description concise de l’interaction sollicitée
• éventuellement, au niveau le plus fin (TRACE), le message émis / reçu

Certaines librairies Open Source, comme commons-http-client (HTTP) et CXF (SOAP) offrent ces fonctionnalités de manière native.

En conclusion

L’application de ces 10 commandements nous pousse de manière assez naturelle à l’utilisation de Log4J, qui répond à l’ensemble des besoins listés ci dessus.
Le choix de Commons Logging ou de java.util.logging, si il est loin d’être proscrit, demande une plus grande vigilance (voir les articles ‘Critiques’ cités en références).

Quoi qu’il en soit, il est primordial d’avoir en tête ces bonnes pratiques dès le démarrage d’un projet. En effet, au même titre que les tests unitaires ou que la documentation interne du code, les logs ne peuvent être repoussées à ‘plus tard’ : plus le temps passe, plus la complexité et le volume de code à ‘tracer’ augmentent.
Ceux qui ont expérimenté « l’intervention pompier » sur une application peu ou mal loggée savent qu’il est quasiment impossible d’otenir des logs globales et/ou pertinentes a posteriori (d’autant qu’il est difficile de ‘budgeter’ une telle opération, dont la valeur métier est nulle).

Références

Les frameworks de logs les plus connus

• Simple Logging Facade for Java (SLF4J) : A simple facade for various logging APIs allowing to the end-user to plug in the desired implementation at deployment time.
• Log4J : Site officiel du framework Log4J
• Java Commons Logging : Site officiel du framework Commons Logging
• java.util.logging : API de java.util.logging

Critiques

• Rod Waldhoff’s Weblog – Commons Logging was my fault : une critique de Commons Logging par son auteur
• Tomcat Docs – Logging : The default implemenatation of java.util.logging provided in the JDK is too limited to be useful. …

Un des problèmes récurrents qui fait intervenir les deux équipes est le déploiement des applications.

La problématique des déploiements d’applications J2EE

Les applications actuellement réalisées sont massivement distribuées : il n’est pas rare d’avoir une application multi-tiers (un serveur web, un serveur d’applications et une base de données par exemple) qui nécessite une installation sur plusieurs serveurs distincts. Le problème s’accentue encore sur les environnements de production, qui en plus d’être distribués, sont bien souvent clusterisés pour des problématiques de tolérance à la panne et de montée en charge. Les applications actuelles deviennent très complexes à installer.

Imaginez seulement devoir installer une simple application comme Microsoft Office sans recourir à l’installateur : ceci implique copier vous-même les fichiers dans les bons répertoires, mettre à jour les fichiers de configuration pour adapter Office à la machine et au répertoire d’installation choisie, mettre à jour la base de registre (sic !) … Ceci vous semblerait complètement invraisemblable. Imaginez maintenant que vous deviez répéter cette « procédure » d’installation sur plusieurs postes aux configurations différentes. L’opération deviendrait vite cauchemardesque. Eh bien, vous commencez à comprendre ce que ressentent les équipes d’intégration et de production qui vivent ce genre de situation au jour le jour.

C’est le constat que l’on fait généralement chez nos clients quand on se penche sur leur processus d’installation des applications. La plupart des opérations sont manuelles et au mieux décrites dans un document long, pas toujours très clair, très rébarbatif à lire et source d’erreurs. Ce genre de document est d’une part très difficile à produire par la MOE (oubli, clarté des explications, …) et d’autre part, très difficile à lire pour les équipes d’exploitation. Si l’application est mal packagée, l’effet s’accentue.

Vers une industrialisation des déploiements

L’industrialisation des déploiements est là pour améliorer cet état de fait.

L’industrialisation ne se focalise pas uniquement sur l’automatisation des déploiements. Quand on démarre ce genre d’étude, on cherche avant tout à simplifier les processus. Dans ce cas, il ne suffit pas de se concentrer sur les équipes de production et d’exploitation : les phases de packaging et de livraison entrent elles aussi dans cette étude de simplification. Et il convient donc de rencontrer les équipes de développements en charge de ces phases.

Il est important d’analyser le processus de déploiement complet, du packaging de l’application jusqu’à la mise en production. On identifie ensuite quelles sont les étapes qui consomment énormément de temps et quelles sont les étapes qui échouent le plus souvent.

En automatisant et en simplifiant le processus de déploiement, on diminue les risques, les erreurs dues aux étapes manuelles, les pertes de temps, etc.

L’une des conséquences de cette amélioration des déploiements est l’amélioration de la relation MOE / Exploitation. Si les applications sont faciles à déployer, les relations sont moins tendues et les différentes équipes de développement et d’exploitation seront plus enclines à collaborer activement car elles sentiront que leur travail est respecté et leurs besoins compris.

Cette interview avait été réalisée à l’occasion du TechTalk organisé par BEA sur les thèmes de la supervision, de l’administration et du support (Cf. notre billet du 26 juin : « Supervision, Administration et Support« ).

BEA organise le mardi 10 juillet 2007 un TechTalk sur les thèmes de la supervision, de l’administration et du support.

Un sujet plus que d’actualité puisque, comme le rappelait Luc Legardeur dans son billet « Exploitation J2EE : il y a urgence !!!!« , l’exploitation devient, avec l’augmentation en nombre et en criticité des applications J2EE, une discipline fondamentale pour les départements Production.

Elle nécessite la mise en place de bonnes pratiques de supervision J2EE impliquant tous les membres de l’organisation informatique (Etudes, équipes projets, cellule d’exploitation, …).
La performance, la stabilité des systèmes, la réactivité face aux incidents, le déploiement rapide des nouvelles applications, les exigences sécuritaires accrues mettent la résilience des infrastructures à rude épreuve.

Parmi les interventions :

• Un retour d’expérience de Stéphane Coussement, Directeur Technique de voyages-sncf.com sur l’amélioration des pratiques de supervision.
• Un topo sur les meilleures pratiques en matière de supervision des Infrastructures Java/J2EE par Guillaume Bodet, Directeur Technique de Xebia.

L’administration et le support « Préemptif » seront également à l’honneur avec :

• Une présentation des nouveautés de la version BEA WebLogic Server 10 : les nouveautés en terme d’administration, de nouvelles certifications, d’optimisation de la productivité des développements, etc.
• Une présentation et démonstration de l’outil BEA Guardian™ un outil de « support préemptif » unique, conçu et développé par BEA Systems. Cette innovation technologique signe l’ouverture vers une nouvelle génération de support.

Information et inscription au BEA TechTalk.

Pour patienter, vous pouvez dès maintenant :

• Visualiser l’interview de Guillaume Bodet, Directeur Technique de Xebia, au sujet des meilleures pratiques en matière de supervision des Infrastructures Java/J2EE.
• Lire le témoignage de Voyages-Sncf.com sur l’exploitation et la supervision J2EE.
• Télécharger une introduction sur le sujet : « Supervision des Infrastructures« .
• Télécharger la méthode utilisée par Xebia pour auditer les performances d’une application J2EE.
• Télécharger la démarche proposée par Xebia pour automatiser les déploiements.

L’adoption massive des technologies J2EE par les entreprises a contraint les cellules d’exploitation à adresser rapidement (et sans aucune aide particulière) plusieurs défis majeurs :

• Gérer l’augmentation sensible du nombre d’applications en exploitation.
• Rendre un service compatible avec le niveau de criticité des applications utilisées.
• Prendre en charge des cycles de déploiement et de mise à jour toujours plus rapides.
• Appréhender une complexité inhérente à l’empilement de couches logicielles nombreuses, basées sur des technologies nouvelles.

Pourtant, nous constatons tous que nous -collectivement les acteurs de l’écosystème J2EE- n’avons pas donné les moyens aux départements Production de faire leur travail.

Les symptômes que nous rencontrons le plus fréquemment chez nos clients sont :

• Déploiements chaotiques nécessitant de trop nombreuses interventions humaines.
• Performances dégradées, fuites mémoires, dysfonctionnements inexplicables, …
• Gestion des incidents et procédures d’escalade à faire se pouffer de rire les vieux routards de l’exploitation.

Face à cette situation, il est urgent d’agir. Agir de deux manières :

1. En amont, repenser le travail des architectes et développeurs et mettre l’exploitabilité des applications au cœur des applications.
2. En aval -comme nous le proposons- analyser la maturité des organisations, outils et procédures vis-à-vis de l’administration J2EE.

Pour cela, il faut découper l’administration J2EE en disciplines (Alimentation, Architecture et Exploitation).

Chaque discipline sera ensuite décrite par ses activités unitaires. Par exemple : la gestion de versions, le contrôle qualité, le déploiement, l’architecture middleware, l’architecture de sécurité, l’architecture HD, la gestion des environnements, la gestion des incidents, la gestion de la capacité, la gestion de la disponibilité, la gestion de la continuité, gestion des SLA, …
Il reste enfin à évaluer la maturité de chacune d’entre elles (état initial, reproductible, géré ou optimisé) et établir un plan d’action pour passer d’un état de non maturité (état initial) à l’état d’après (reproductible) …

Ce travail est nécessaire. Nous intervenons souvent en pompiers pour régler des problèmes ponctuels comme la performance.

Notre devoir de conseil nous oblige donc à tirer la sonnette d’alarme sur ce sujet.

Nous pouvons aider nos clients à devenir plus matures et à administrer plus sereinement leurs plateformes J2EE.

Luc Legardeur, Président

Comme son titre le suggère, ce premier billet concerne la journalisation, connue également sous son sobriquet anglo-saxon de « log ».
Depuis plusieurs années maintenant, l’utilisation d’un framework dédié pour gérer les logs s’est généralisée. Log4j a ouvert la voie, suivi par framework java.util.logging à partir du JDK 1.4, qui adopte une architecture très similaire à celle de log4j, tout en proposant une nomenclature moins intuitive (du moins pour ceux qui pensent que « DEBUG » désigne un niveau de journalisation plus évident que « FINEST »). Citons également les meta-frameworks Commons Logging et SLF4J, qui offrent une couche d’adaptation au dessus des différents frameworks pour en unifier l’usage.

L’objet ici n’est pas de comparer ces différentes solutions : elles sont toutes très proches et offrent toutes les fonctionnalités attendues d’un utilitaire de logging:

• une API simple et intuitive, style log.debug(message) ou log.info(message)
• une configuration externalisée permettant d’activer ou de désactiver certaines traces sans intervention sur les sources ou les binaires
• la possibilité de configurer des flux de sortie divers pour les messages (console, fichiers avec rotation, sockets, base de données, JMS, syslog, NTEventLog, etc.), avec une granularité très fine
• la possibilité de configurer le format des messages

On ne peut que se féliciter de l’adoption massive de ces frameworks, en particulier du plus illustre d’entre eux, log4j. Cette adoption a pourtant bien souvent un revers: disposer de ces fonctionnalités a exempté les architectes et développeurs d’une réflexion réelle sur l’usage des logs. La politique de journalisation se réduit fréquemment à cette simple directive : « Utiliser log4j », et le code est en conséquence saupoudré plus ou moins densément (selon l’humeur ou la sensibilité du développeur) d’instructions du style

Logger log = Logger.getLogger(this.getClass());
	[...]
	log.debug("Avant call gloubiboulga casimir.isHeureux()=" + casimir.isHeureux());
	casimir.gloubiboulga();
	log.debug("Après call gloubiboulga casimir.isHeureux()=" + casimir.isHeureux());
	[...]
	catch (Exception ex){
	    log.error("Une erreur s'est produite", ex);
	    throw new RealBadThingHappenedException(ex);
	}
	[...]

Plusieurs problèmes dans cette approche:

• le logger utilisé porte le nom de la classe. Il doit être configuré comme tel (y compris avec les mécanisme d’héritage). Les noms de classe (et de package) n’ont pas vraiment de sens pour les équipes d’exploitation, ce qui limite souvent leur autonomie sur la configuration des traces.
• les messages de debug manquent de consistance, et n’ont de véritable intérêt que pour le développeur au moment de la mise au point de la classe concernée (ce qui, notons-le, n’est pas critique; par nature, les messages de déboguage ne sont pas destinés aux exploitants).
• si plusieurs threads exécutent simultanément la méthode, les traces seront entrelacées et il sera difficile de rétablir le séquencement des opérations
• le message d’erreur est laconique et la pile d’appel, pour utile qu’elle soit, n’est interprétable que par l’ingénierie.
• il n’y a pas de trace intermédiaire entre DEBUG et ERROR, ce qui limite la capacité de diagnostic en exploitation
• l’utilisation des API de log tel quel peut poser des problèmes de performance (cf ce billet)

Nous nous pencherons aujourd’hui sur le problème de la corrélation: dans un environnement multithreadé et distribué, comment relier entre eux les messages relatifs à une même interaction?

Corréler les logs

Dans un environnement multi-threadé, et a fortiori dans un environnement distribué, il est difficile, sinon impossible, de corréler l’ensemble des traces issues d’un même traitement ou d’une même interaction (que l’on nommera désormais transaction pour plus de clareté). La solution proposée par log4j pour adresser ce problème consiste à placer dans chaque message un identifiant de corrélation unique pour chaque transaction. On trouvera une description de ce principe dans « Patterns for Logging Diagnostic Messages »(1).
Log4j supporte nativement cette contextualisation, aux travers des classes org.apache.log4j.NDC et org.apache.log4j.MDC (ce n’est pas le cas de java.util.logging; l’extension de java.util.logging pour supporter les NDC serait néanmoins très simple).
Pour implémenter ce mécanisme, il suffit donc d’intercepter le point d’entrée du système et de fixer l’identifiant de correlation dans le MDC (ou le NDC).
Le cas le plus simple est celui d’une application web, pour laquelle cette interception se fait au moyen d’un filtre:

public class Log4jMDCServletFilter implements Filter {
	public void doFilter(ServletRequest request,
						 ServletResponse response,
						 FilterChain chain)
					throws IOException, ServletException {
		try {
			if (MDC.get("CorrelationID") == null)
				MDC.put("CorrelationID", JOTUtils.generateCorrelationID());
			chain.doFilter(request, response);
		}
		finally {
			MDC.remove("CorrelationID");
		}
	}
...
}

Il suffit ensuite d’utiliser le pattern (cf. org.apache.log4j.PatternLayout) suivant pour disposer systématiquement dans les messages d’un identifiant de correlation :

%d{ISO8601} [%t] %-5p %c %X{CorrelationID} - %m\n

Il est bien sûr possible de fournir un contexte plus riche (par exemple le nom de l’utilisateur, le use case, le service, etc.), et ce mécanisme peut servir de base à un filtrage, permettant d’augmenter le niveau de trace uniquement pour un sous-ensemble de clients ou de contextes.
Le composant NDC (pour Nested Diagnostic Context) permet quant à lui de gérer une pile de contextes imbriqués.

Néanmoins, MDC et NDC s’appuie sur des variables ThreadLocal, limitées donc à l’espace mémoire de la JVM. Les choses se compliquent donc singulièrement lorsque les interactions sont distribuées et que l’on souhaite corréler les traces aux travers de plusieurs JVMs.

Dans un contexte distribué, l’identifiant de correlation doit être propagé aux différents composants traversés. Il n’existe malheureusement pas de moyen universel de réaliser cette propagation : elle dépend du protocole utilisé pour réaliser les invocations distantes. Le plus souvent, cependant, la distribution se fera au moyen de RMI/IIOP.
Le protocole IIOP bénéficie d’une technologie standard d’interception: les PortableInterceptors CORBA. Voici donc un moyen de réaliser la propagation transaparente de l’identifiant de corrélation sur IIOP.

Premier élément, un intercepteur client chargé d’enrichir le flux IIOP d’un contexte spécifique portant l’identifiant de corrélation:

...
public class CORBAClientInterceptor
	extends org.omg.CORBA.LocalObject
	implements ClientRequestInterceptor {
	private org.omg.PortableInterceptor.ORBInitInfo info;
	private int t_slot;
	private static final long serialVersionUID = -6768740178708556025L;
	public CORBAClientInterceptor(ORBInitInfo info, int t_slot) {
		this.info = info;
		this.t_slot = t_slot;
	}
	public String name() {
		return "JOT Log correlation id propagation - Client Interceptor";
	}
	public void send_request(ClientRequestInfo ri) throws ForwardRequest {
		org.omg.CORBA.Any any = null;
		try {
			any = ri.get_slot(t_slot);
		}
		catch (org.omg.PortableInterceptor.InvalidSlot is) {
			throw new org.omg.CORBA.INTERNAL("JOTClientInterceptor : Invalid slot : " + is.getMessage());
		}
		if ( ( any.type().kind().value() == org.omg.CORBA.TCKind._tk_null ) ||
		     ( any.type().kind().value() == org.omg.CORBA.TCKind._tk_void ) )
			return;
		org.omg.IOP.ServiceContext serviceCtx = new org.omg.IOP.ServiceContext();
		serviceCtx.context_id = 995;
		try {
			serviceCtx.context_data = ((String)MDC.get("CorrelationID")).getBytes("UTF-8");
		} catch (UnsupportedEncodingException e) {
			throw new org.omg.CORBA.INTERNAL("JOTClientInterceptor : UTF-8 Not Supported : " + e.getMessage());
		}
		ri.add_request_service_context(serviceCtx, true);
	}
...
}

Il faut ensuite un intercepteur symétrique, côté serveur, chargé de décoder l’identifiant de corrélation et de le placer dans le NDC log4j:

...
public class CORBAServerInterceptor extends LocalObject implements
		ServerRequestInterceptor {
	private static final long serialVersionUID = -5574812890862607150L;
	private org.omg.PortableInterceptor.ORBInitInfo info;
	private int t_slot;
	public CORBAServerInterceptor(ORBInitInfo info, int t_slot) {
		this.info = info;
		this.t_slot = t_slot;
	}
	public String name() {
		return "JOT Log correlation id propagation - Server Interceptor";
	}
	public void receive_request_service_contexts(ServerRequestInfo ri)
			throws ForwardRequest {
		org.omg.IOP.ServiceContext serviceCtx = null;
		try
		{
			serviceCtx = ri.get_request_service_context(995);
		}
		catch (org.omg.CORBA.BAD_PARAM bp){
			//Le client n'a pas fourni de contexte, on en génère un
			MDC.put("CorrelationID", JOTUtils.generateTID());
			return;
		}
		try {
			MDC.put("CorrelationID", new String(serviceCtx.context_data, "UTF-8"));
		} catch (UnsupportedEncodingException e) {
			throw new org.omg.CORBA.INTERNAL("JOTServerInterceptor : UTF-8 Not Supported : " + e.getMessage());
		}
	}
...
}

Et voici la classe d’initialisation qui permet d’enregistrer les intercepteurs:

...
public class CORBAInitializer extends org.omg.CORBA.LocalObject implements
		ORBInitializer {
	/**
	 * Log correlation slot id
	 */
	private int t_slot;
	/**
	 * Pre initialization
	 */
	public void pre_init(org.omg.PortableInterceptor.ORBInitInfo info) {
		t_slot = info.allocate_slot_id();
		CORBAClientInterceptor clientInterceptor = new CORBAClientInterceptor(
				info, t_slot);
		try {
			info.add_client_request_interceptor(clientInterceptor);
			// info.add_server_request_interceptor(serverInterceptor);
		} catch (org.omg.PortableInterceptor.ORBInitInfoPackage.DuplicateName dn) {
			String msg = "Error in initializer: Duplicate name when adding the interceptor : "
					+ dn.getMessage();
			throw new org.omg.CORBA.INTERNAL(msg);
		}
	}
	public void post_init(ORBInitInfo info) {
	}
}

L’implémentation de ce mécanisme pour d’autres protocoles dépend bien sût des capacités de ce protocole. Si le protocole est HTTP, il est assez simple d’ajouter les entêtes adéquates dans les requêtes. Pour d’autres protocoles, les choses peuvent s’avérer plus difficile, voire impossible pour des protocoles propriétaires.

Dans le prochain billet, nous chercherons à centraliser la configuration des catégories et à en simplifier l’usage.

Références
(1) « Patterns for Logging Diagnostic Messages » dans « Pattern Languages of Program Design 3″, édité par R. Martin, D. Riehle, et F. Buschmann (Addison-Wesley, 1997).