Dans la suite de ce billet, nous allons essayer d’analyser cette tendance émergente en revenant brièvement sur :

• Ce qu’est un ESB et les besoins des systèmes en terme d’intégration.
• Les plates-formes de cloud computing et leurs différents modèles.

Les ESB

Les tentatives pour couvrir la définition et l’utilisation des ESB ont fait couler beaucoup d’encre. Revenir brièvement sur le sujet s’avère donc un exercice très difficile. Néanmoins, on pourrait le synthétiser de la sorte (pour plus d’approfondissement, n’hésitez pas à consulter notre livre blanc sur le sujet) :

Un ESB est une plate-forme d’intégration basée sur des standards ouverts. Elle combine les fonctions d’échange de messages, de transformation, de routage et d’exposition de services, afin de permettre de relier efficacement et de coordonner les différentes composantes d’un système d’information étendu. À bien des égards, un ESB pourrait être un point de départ pour l’émergence d’une SOA orientée événement ou « Event-Driven SOA ».

Quelles motivations pourraient pousser une telle plate-forme à migrer vers les nuages ? Essayons de les appréhender en s’intéressant de plus près à ce nouvel environnement d’exécution.

Le cloud computing

Wikipedia définit le cloud computing, selon le livre blanc de notre cher SYNTEC, comme un concept se déclinant sous trois formes :

• IaaS : infrastructure as a Service. C’est le niveau le plus bas. Le fournisseur assure dans ce cas les infrastructures matérielles nécessaires à la demande et selon les besoins de scalabilité et de stockage de l’application. Le client doit prendre en charge tous les aspects OS, pile logicielle et configuration pour tirer profit de l’élasticité des infrastructures fournies. On pourra citer comme exemple Amazon EC2.
• PaaS : plate-forme as a Service, niveau intermédiaire. Le fournisseur met à disposition une pile logicielle spécifique à ses infrastructures matérielles. Il assure derrière la disponibilité de votre application en lui allouant dynamiquement les ressources nécessaires selon les variations de sa charge. Un des exemples les plus célèbres est Google App Engine
• SaaS : Software as a Service, niveau le plus haut du concept. Le client consomme le logiciel hébergé par la plate-forme sur une base de paiement par utilisation (pay per use). SalesForce a été un des pionniers de ce type de service.

Notons que le principe du « pay per use » s’applique aux différentes déclinaisons citées ci-dessus. Il représente un des avantages principaux du cloud computing. Il permet la rationalisation des coûts et l’élimination du gaspillage en exploitation, licences, …

Et comme il y a toujours un « Mais », celui du cloud computing a toujours été la sécurité des données et dans une moindre mesure le lock-in par rapport aux fournisseurs. Ce qui a donné naissance à une nouvelle variante, les clouds privés. Les entreprises désireuses de tirer profit du concept et ne voulant pas confier leurs données stratégiques à Amazon, Google et consorts, ont opté pour cette alternative. Elles gardent ainsi la main sur l’exploitation et la gouvernance de leurs infrastructures existantes tout en les mutualisant entre leurs différentes filiales.

Les premières applications à avoir été mises dans les nuages ont été les commodités telles que les solutions de stockage, les CRM, quelques modules d’ERP (par exemple l’offre Business ByDesign de SAP)…

Quels arguments pour les ESB dans les nuages ?

À la suite de ce bref tour d’horizon, deux arguments semblent se dégager en faveur d’un déploiement des ESB dans le cloud :

1. Les ESB, de par leur adoption de standards ouverts, pourraient être un jour considérés comme des commodités, ce qui en fait un bon candidat pour le cloud. Cependant, les tentatives de standardisation, telles que JBI, n’ont à ce jour pas rassemblé un nombre critique d’acteurs et l’offre actuelle du marché reste composée de solutions hétérogènes, adoptant des architectures différentes.
2. Un déploiement dans les nuages permettrait une intégration pervasive inter-SI, rendant les échanges entre les départements d’une même entreprise plus directs. Cela permet aussi de faciliter l’intégration des éventuelles nouvelles applications en mode SaaS avec le reste du parc applicatif.

Par ailleurs, porter son bus dans les nuages induira des défis différents selon si l’on choisit un cloud privé ou public. Dans le premier cas, ils seront plutôt du côté de l’exploitation traditionnellement orientée vers la gestion des bases de données, des serveurs d’applications et des serveurs web et il faudra donc se munir d’un framework approprié pour la gestion d’ESB dans son cloud privé tel que Stratos. Dans le deuxième cas, ils seront plus nombreux. On citera principalement, la sécurité, la gouvernance et l’ouverture des firewall afin de pouvoir communiquer avec une plate-forme publique externe.

Perspectives

Les ESB dans les nuages ne sont qu’à leur début et la pertinence de ce portage est loin encore de faire l’unanimité. Certaines parties affirment même que les ESB n’ont pas leur place dans le cloud. Le débat promet d’être intéressant et animé.

Références

• Le système d’information durable
• Entreprise service bus
• ESBs in the cloud: Tricky in the early going
• What’s Next for the ESB? End of the Line, or Cloud Broker
• RunMyProcess

Actualité éditeurs / SSII

• Sortie de RabbitMQ 2.0

Le coin de la technique

• Gestion automatique des ressources dans Java7 (ARM)

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

• Google et les brevets

Actualité éditeurs / SSII

Sortie de RabbitMQ 2.0

La sortie de la version 2.0 du serveur de messaging AMQP RabbitMQ vient d'être annoncée ici.
Cette release majeure vient avec une refonte importante et son lot de nouveautés :

• Une refonte de la gestion de la persistence permettant une alternative au moteur de persistence embarqué. Il sera possible de développer un support pour une base de données relationelle ou NoSQL ou tout autre data store.
• Le support de différents protocoles de messaging : AMQP (0-8 et 0-9-1), XMPP, STOMP, HTTP, SMTP... Il sera aussi possible d'ajouter de nouveaux protocoles à l'aide d'extensions.
• La mise en place d'une infrastructure ayant pour but de simplifier le développement d'outils pour la gestion et le monitoring de RabbitMQ.
• Une amélioration de la gestion des plugins (il n'est plus nécessaire de compiler les plugins, une version pré-compilée peut être directement chargée par RabbitMQ).

SpringSource qui a récemment racheté RabbitMQ (nous vous en avions parlé ici) propose de son côté un template reprenant les principes des templates jdbc, hibernate, jms ou encore LDAP encapsulant le client Java d'AMQP. Les utilisateurs habitués à JmsTemplate retrouveront donc leurs repères en utilisant l'AmqpTemplate du projet spring AMQP.

SpringSource/VMWare continue donc de faire évoluer son portefeuil de produits avec cette évolution majeure de RabbitMQ, qu'il considère comme une pièce essentielle à sa stratégie de développement du Cloud Computing (voir cet article de Rod Johnson).

Le coin de la technique

Gestion automatique des ressources dans Java7 (ARM)

Java7 suit son petit bonhomme de chemin sans qu'on ait encore une bonne visibilité sur la date de sortie officiel. Le build 105 de la version actuelle propose une nouvelle fonctionnalité très intéressante qui devrait facilité la vie de chaque développeur: l'Automatic Resource Management.

L'idée, proposée par Joshua Bloch depuis quelques années déjà, consiste à améliorer la fermeture des ressources sous la forme d'une clause try-with-resources. Actuellement lorsqu'on manipule une ressource, par exemple un InputStream, la façon la plus propre ressemble à ceci:

Ce code devient vite très verbeux et répetitif car beaucoup de vérifications doivent être faites pour s'assurer de la possibilité de fermer la ressource. La solution pour simplifier cela est de déléguer la fermeture du flux à l'aide du try:

Le code gagne énormément en visibilité, les tests pour savoir si la ressource est null ou si la fermeture s'est bien déroulée sont gérés en interne de la JVM. A noter que pour être fermées les ressources devront étendre une nouvelle interface AutoCloseable.

S'il existe un certain consensus autour de l'utilité de cette évolution, il demeure encore un petit débat sur la partie catch des exceptions. Sans rentrer dans les détails, les exceptions levées pendant la fermeture d'une ressource annihilent celles levées dans le bloc try, ce qui en général est préférable mais du coup peut aussi masquer des exceptions importantes pour l'analyse du problème.

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

Google et les brevets

Semaine chargée pour Google:

• InfoQ nous annonce que le MPEG LA a décidé de continuer à ne pas réclamer de royalties pour les videos encodées en H.264 et distribuées gratuitement aux utilisateurs. Seules les plateformes vendant des vidéos sont, elles, toujours soumises à taxation. C'est donc une réponse à Google qui avait il y a quelques temps annoncé WebM, un codec vidéo semblable au H.264 mais plus libre et débarrassé des problèmes de brevets et de royalties qui entravent ce dernier. Si InfoQ ne voit pas trop de problèmes à continuer d'utiliser H.264, ce n'est pas du tout l'avis de Mike Shaver ingénieur haut gradé chez Mozilla et qui rappelle que les logiciels permettant de produire ou de consommer ces vidéos devront eux toujours s'acquitter d'une licence. La bataille entre WebM et H.264 ne fait donc que commencer.
• Ensuite, c'est Paul Allen, le co-fondateur de Microsoft, qui attaque Google et nombre de ses petits camarades (AOL, Yahoo, Facebook) pour avoir enfreint 4 brevets détenus par sa compagnie "Interval Licensing". Le blog Digits du Wall Street Journal s'est penché sur 2 de ces brevets. Nous vous déconseillons fortement la lecture de son analyse si vous avez réalisé quoi que ce soit dans l'informatique ces 10 dernières années. En effet, vous risquez de ne plus trouver le sommeil en vous rendant compte que vous enfreignez sans doutes, vous aussi, nombre de brevets !
• Et pour finir sur Google et les brevets, vous vous souvenez des récentes poursuites engagées par Oracle concernant Java et Android. Google vient de riposter, en annoncant qu'aucun de ses employés ne participera à JavaOne cette année. Pour ceux qui voulaient échanger avec les employés de Google, il semble que c'est plus tard dans l'année, à Devoxx, qu'il faille se rendre. Mais rassurez vous, il y aura quand même de l'ambiance à JavaOne: James Gosling, père de Java, demande sur son blog à toute personne y assistant de porter un TShirt arborant le slogan "Java just Free it". Si cette idée ne risque pas trop de faire bouger Oracle, elle devrait quand même apporter sa dose de fun à l'évènement !

Les Tooltips avec JFreeChart

Les implémentations des Tooltips fournis par l'API JFreeChart sont basées sur l'interface ToolTipTagFragmentGenerator.

ToolTipTagFragmentGenerator.java

L'api JFreeChart fournit quelques implémentations de base :

• StandardToolTipTagFragmentGenerator.java : Cette classe permet de générer un Tooltip en se basant sur les attributs alt et title.

• OverLIBToolTipTagFragmentGenerator.java : Cette classe utilise la libraire JavaScript overLIB pour générer un Tooltip avec un style par défaut.

Quelques exemples de Tooltips avec overLIB

Le site de la libraire overLIB proposent de nombreux exemples d'utilisation dont :

• Tooltip ordinaire avec le style fournis par JFreeChart :

• Tooltip personnalisé avec la librairie overLIB :

• Tooltip avec du html et du css :

Solution

Une fois le mécanisme compris, tout ce qu'il reste à faire c'est s'inspirer de la classe OverLIBToolTipTagFragmentGenerator pour créer un générateur de Tooltips personnalisés.

J'ai pour ma part opté pour la solution FULLHTML dans laquelle la librairie overLIB gère uniquement les événements onmouseover et onmouseout, les styles et les couleurs sont appliqués directement dans le code HTML.

Je commence par créer mon générateur personnalisé CustomToolTipTagFragmentGenerator :

Pour la génération du graphique, la classe ChartUtilities propose les méthodes suivantes :

Ou

Le code html permettant de générer le rendu du Tooltip est créé en implémentant l'interface StandardCategoryToolTipGenerator :

CustomValueToolTipGenerator.java

Une instance de cette classe doit être passée en paramètre de la méthode void setBaseToolTipGenerator(CategoryToolTipGenerator) de la classe AbstractCategoryItemRenderer.

Toutefois, si vous avez opté pour une utilisation des styles fournis par overLIB, la fonction generateToolTip doit se contenter de retourner le message à afficher dans le Tooltip.

En espérant que cette solution puisse vous aider !

Par audit, nous entendons l'audit des actions importantes réalisées sur une application.

Pourquoi auditer ?

Est-il vraiment utile de générer des informations d'audit dans nos applications ? Sans explications de juriste, quelques exemples suffiront à nous en convaincre :

• Un site web de partage de photos doit pouvoir dire qui a uploadé quelle image, depuis quelle adresse IP et à quelle date.
• L'application d'administration d'un site de e-commerce doit tracer toutes les modifications de prix pour empêcher un employé astucieux de baisser à 1 euro le prix de son téléphone préféré le temps de passer commande.

Pour revenir à des explications plus théoriques, les logs d'audit nous apportent :

• les informations nécessaires à la justice en cas d'infraction,
• la détection d'intrusions,
• la reconstitution des événements en complément des logs d'exceptions pour aider au diagnostique de problèmes.

Nous nous placerons dans le cas le plus fréquent où nous ne développons pas d'outil pour consulter ces informations d'audit et où un accès direct au média de stockage (grep sur fichier texte, sql sur base de données, etc) suffit.

Que faut-il auditer ?

Dans un monde idéal, le contenu des messages serait défini avec les équipes de sécurité. En pratique, nous sommes assez seuls pour les choisir et il ne faut pas dramatiser. Si l'on ne prend pas le sujet à la légère, après quelques itérations, notre bon sens est le plus souvent suffisant.

Les éléments clefs à tracer sont :

• L'heure exacte : il est essentiel que les serveurs soient à l'heure pour corréler les logs des différentes briques du système d'information. Le sujet est aujourd'hui censé être banal pour les équipes système (c.f. NTP) et nous pouvons demander le soutien des équipes sécurité pour obtenir gain de cause.
• L'action réalisée : il s'agit souvent du nom de la méthode métier appelée.
• L'identifiant et/ou la valeur des données métier sensibles manipulées : souvent les id ou le toString() des paramètres d'appel.
• L'auteur de la manipulation : nom de l'utilisateur connecté et son adresse ip (pour plus de détails sur l'adresse ip : XForwardedFilter et Tomcat : Adresse IP de l'internaute, load balancer, reverse proxy et header Http X-Forwarded-For).
• La description succincte des exceptions levées pour analyser les éventuelles attaques.

Pourquoi les logs d'accès des serveurs http ne suffisent pas ?

La première idée serait de se contenter des logs d'accès des serveurs web et des firewalls pour auditer les accès à nos applications ; nous n'aurions alors plus rien à faire.

Hélas, cela n'est pas suffisant car il manque dans les logs http des informations clefs :

• Nous n'avons pas l'identité de l'appelant : on a bien l'adresse ip mais pas le login de l'utilisateur authentifié.
• Nous n'avons pas les id passés en paramètre des opérations à auditer (sauf si on fait du REST) ; en SOAP, nous n'avons même pas le nom de l'opération !
• Nous n'avons pas le détail des exceptions levées par l'application.

API : Framework de log vs. framework dédié

Dans un monde idéal, le framework d'audit ne devrait pas dépendre de la configuration des logs pour ne pas risquer qu'une mauvaise manipulation de ces configurations de logs ne le désactive.

En pratique, les frameworks de logs sont les briques les plus performantes et les plus matures pour traiter les besoins d'écriture d'audit et la probabilité de désactiver l'audit en faisant une mauvaise manipulation sur la configuration des logs est négligeable. Ces raisons nous amènent à utiliser SLF4J avec logback ou log4j pour gérer l'audit.

Nous encapsulerons tout de même le logger avec une couche légère packagée dans la librairie Xebia Spring Security Extras qui ajoutera au message l'identité de l'internaute et son adresse IP (via Spring Security). Cette librairie offre une gestion déclarative de l'audit avec une annotation @Audited, son aspect associé AuditAspect et une classe utilitaire Auditor. Nous ne rentrerons pas dans le débat annotations vs. code ; dans la majeure partie des projets, nous avons pu traiter la plupart de l'audit avec une annotation et seuls quelques cas ont nécessité de passer par du code.

Exemple de gestion de l'audit avec l'annotation @Audited :

L'attribut message est un pattern supportant Spring Expression Language définissant l'entrée insérée dans le fichier d'audit ; la date, le nom de l'utilisateur, l'adresse ip et l'exception s'il y en a une sont ajoutés au message.

Fragment de configuration Spring Framework pour utiliser l'annotation @Audited :

Message d'audit généré :

Exemple de gestion de l'audit avec l'utilitaire Auditor :

Message d'audit généré :

L'entrée d'audit est ajoutée dans un fichier d'audit géré par le logger spécifique "fr.xebia.audit" (voir cet article pour la configuration du logger).

Intégration du framework dans une application

Ce framework peut être intégré de différentes façons dans une application :

• Intégration Maven :
  <project ...>
     <dependencies>
        <dependency>
           <groupId>fr.xebia.springframework</groupId>
           <artifactId>xebia-spring-security-extras</artifactId>
           <version>1.1.1</version>
        </dependency>
        ...
     </dependencies>
     <repositories>
        <repository>
          <id>xebia-france-googlecode-repository</id>
          <url>http://xebia-france.googlecode.com/svn/repository/maven2/</url>
        </repository>
        ...
     </repositories>
     ...
  </project>

• Téléchargement du jar xebia-spring-security-extras-1.1.1.jar (sources).
• En récupérant le code source disponible sous licence Open Source Apache Software Licence 2 dans le repository Subversion http://xebia-france.googlecode.com/svn/springframework/xebia-spring-security-extras/trunk/.

Stockage : fichier texte vs. base de données

Le stockage des entrées d'audit en base de données permet sûrement une recherche plus fine des données que sur des fichiers mais cela ajoute de la complexité (déploiement, exploitation, backup) ainsi que des risques de pannes et impacte les performances. Les approches JMS présentent des contraintes similaires et l'utilisation de systèmes de logs distants comme rsyslog présentent un défi de fiabilité. Ces difficultés sont accentuées lorsqu'une application génère de gros volumes de logs (plusieurs Go/jour).

Pour ces raisons, nous préférons stocker les messages d'audit dans un simple fichier. Les risques de saturation du système de fichiers sont assez facilement gérables par les équipes d'exploitation, les procédures d'archivage et de consultation très simples (gzip, scp, grep, etc) et il n'y a quasiment jamais de problème de performance, même avec des fichiers de quelques Go par jour.

Y-a-t-il un plus grand risque de perdre les données par de mauvaises manipulations ? Si une application est critique, les exploitants doivent déjà ne pas perdre les fichiers de log du système d'exploitation, des serveurs web et autres firewalls.

Pour la gestion des messages d'audit sous forme de fichier texte, nous aimons logback comme nous l'avons expliqué dans Java en Production - Les fichiers de logs mais il est aussi possible d'utiliser Log4j.

Exemple de configuration Logback pour gérer les messages d'audit émis sur le logger fr.xebia.audit :

Exemple équivalent avec log4j (le EnhancedPatternLayout requiert log4j 1.2.16) :

Que faire des logs d'audit après les avoir générées ?

Nous ne rentrerons pas plus dans les détails de la gestion des logs d'audit après leur génération par nos applications.

Ce sujet complexe présente aussi bien des aspects juridiques que de confidentialité ou encore de fiabilité. Schématiquement, on n'a pas le droit de garder indéfiniment des données personnelles, il faut restreindre leur consultation et empêcher leur modification et leur destruction par accident comme par malveillance.

Des professionnels de l'exploitation et de la sécurité sont beaucoup plus compétents que nous sur ce sujet .

Pour aller plus loin

Si le traitement de l'audit dans les applications vous a intéressé, nous avons aimé lire :

• The Importance of Audit Logs par George Spafford,
• NIST 800-92 Log Management Guide in the Real World et l'ensemble des présentations de Anton Chukavin.

Synthèse

Nous avons vu aujourd'hui une façon simple de gérer l'audit d'applications java en reposant sur le framework de log de l'application (Logback voire Log4j) pour écrire les messages dans de simples fichiers texte avec une surcouche très légère composée d'une annotation @Audited et d'un utilitaire Auditor.

Actualité éditeurs / SSII

• James Gosling sur l'affaire Oracle vs Google
• ActiveMQ 5.4.0

Le coin de la technique

• Hibernate ne supporte plus CGLIB

Actualité éditeurs / SSII

James Gosling sur l'affaire Oracle vs Google

James Gosling revient sur l'épisode Oracle vs Google avec un article dans lequel il nous donne quelques éléments pour mieux comprendre la politique de Sun vis à vis de Java et des brevets :

• Sun a principalement déposé des brevets afin de se protéger d'éventuelles attaques venant de ses concurrents. Un épisode malheureux dans lequel Sun fut attaqué par IBM concernant un brevet sur les processeurs RISC leur fit prendre conscience qu'il était nécessaire de posséder un arsenal de brevets. Le procès se termina en effet en leur défaveur et ils durent payer d'importantes indemnités à IBM, les mettant au bord du dépôt de bilan.
• Les brevets sur la technologie Java et le choix de la license CDDL avaient pour but de garantir l'interopérabilité des applications java sur les différentes plateformes. Cette protection a donné lieu à un procès entre Sun et Microsoft car ce dernier avait fournit une implémentation d'un machine virtuelle Java sur laquelle le code ne s'exécutait pas de la même manière que sur les autres JVM (dont celle de Sun) qui respectaient les spécifications. La machine virtuelle java de Google présentant elle aussi des problèmes d'interopérabilité, Oracle se sert de cette jurisprudence pour les poursuivre.
• Sun aurait souhaité obtenir une partie des bénéfices générés par la plateforme Android mais sans succès. Il semble donc qu'Oracle souhaite continuer dans cette voie mais en choisissant de sortir l'artillerie lourde pour parvenir à ses fins.

Cette affaire a un effet néfaste sur l'image de Java et James Gosling, loin de cautionner l'action d'Oracle, regrette l'absence de moralité des grandes compagnies informatiques actuelles.

ActiveMQ 5.4.0

Un peu moins d'un an après la dernière release, Apache sort une nouvelle version de son broker de message. Au-delà des 283 bugs résolus, on notera quelques nouvelles fonctionnalités intéressantes:

• Priorité des messages: Jusqu'à maintenant pour jouer sur la priorité de certains messages sur d'autres il fallait contourner le problème en utilisant plusieurs queues de messages qui pouvaient être, elles, priorisées. Le point de blocage jusqu'à maintenant était lié à l'ordonnancement des messages, trop gourmand en temps. Ce problème semble être en partie réglé et le paramètre priorité du message JMS (inclus dans l'API) sera pris en compte.
• Planifier ses messages: ActiveMQ possède à présent un planificateur persistant de message. En d'autres termes, il est possible à l'envoi du message de préciser la date réelle de l'envoi et la durée entre la répétition d'un envoi. L'interface permet même de préciser tout cela sous la forme d'une entrée CRON. Ceci peut être assez intéressant pour par exemple faire du heartbeat (envoi d'un message à intervalle régulier pour s'assurer du fonctionnement de l'application ou faire des calculs de performance).
• WebSocket: Le sujet est à la mode, surtout avec l'émergence d'HTML 5, HornetQ le propose également sur sa dernière version. Il s'agit d'utiliser le broker de messages depuis du code javascript. Tout comme HornetQ, ActiveMQ utilise son protocole de message simplifié STOMP. Deux librairies javascripts sont proposées sur leur site: Stomple et stomp-websocket.

Hormis ces nouveautés, des améliorations ont été apportées sur OSGI et le shell unix.

Le coin de la technique

Hibernate ne supporte plus CGLIB

Historiquement CGLIB a rendu de nombreux services à Hibernate et Spring pour permettre de manipuler le bytecode Java. Par exemple, vous avez sans doute déjà vu passer un proxy préfixé par CGLIB lorsque vous débuggez votre application. Mais récemment, Steve Ebersole, développeur chez Hibernate, a annoncé qu'il n'y aurait plus de support pour cette librairie. Cette décision aurait été prise non pas pour des raisons purement techniques mais parce que cette librairie n'aurait plus de support et semble figée à la version 2.2 qui date de 2008. L'auteur donne pour exemple un ancien bug sur une incompatibilité de version de la librairie ASM (qui manipule à un niveau plus bas le bytecode) avec celle de Spring et qui mit un an à être corrigé.

Hibernate à présent privilégiera Javassist, un projet JBoss (tout comme Hibernate, tiens, tiens...), aux fonctionnalités similaires mais encore en vie. Reste à savoir si Spring suivra la même démarche.