Note : 3 ; Ciblant l’analyste, un ouvrage trop superficiel et d’avantage focalisé sur le processus de réalisation que sur l’outil ! Dommage.
Difficile de faire autrement que de comparer ce livre à son pendant adressant OSWorkflow ! Même type d’ouvrage, même éditeur et même taille, l’auteur du premier est même relecteur du second. Bref, deux ouvrages courant dans la même catégorie ! Mais autant j’ai été accroché par le premier, autant j’ai été déçu par celui-là. Explications.
En réalité, dès le départ, on s’aperçoit que cela va être difficile : le premier chapitre n’évoque guère jBPM en guise d’introduction. On y évoque plutôt le processus d’analyse et de modélisation. Va pour les 20 premières pages.
Le second chapitre évoque de manière plus détaillée le processus de modélisation du BPM à l’aide d’une étude de cas ici introduite. Ce livre n’étant pas réellement un ouvrage de BPM, le traitement de ce sujet est quelque peu léger, sinon naïf. Et l’on est arrivé page 52 (sur 200) et toujours pas de jBPM à l’horizon.
On en parle enfin au chapitre 3, où tout le processus d’installation et de configuration est détaillé, un peu trop à la façon « pour les nuls » à mon goût. Mais on finit quand même par aborder le sujet qui m’intéresse ici en premier lieu, c’est-à-dire jPDL (on est quand même page 74). Au final nous avons quand même droit ici à 25 pages de matière réellement pertinente.
Le chapitre 4 évoque l’interface utilisateur, c’est-à-dire les formulaires JSP que l’on peut construire directement sur la plateforme jBPM.
Le chapitre 5 revient sur le leitmotiv des auteurs : le processus de développement. Nous avons toutefois droit à 7 pages particulièrement intéressantes sur l’intégration de systèmes : juste de quoi nous mettre l’eau à la bouche, mais clairement pas assez pour nous délivrer une information pertinente et utilisable !
Le chapitre 6 « proof of concept implémentation » noie pas mal d’informations importantes sous couvert de processus de développement (encore lui), mais sont toutefois évoqués : configuration, déploiement et même monitoring et BAM avec la plateforme SeeWhy. Ce dernier volet est tout à fait intéressant, à la fois par l’évocation de SeeWhy que par le fait que l’intégration en est bien décrite.
Le dernier chapitre sur le « process improvement » n’est que du bla-bla, oubliez-le.
Bref, ce livre est une grosse déception, je n’y aie trouvé que 50 à 60 pages d’informations utiles. D’un autre coté je n’ai pas ici une couverture complète du sujet me permettant de jauger si cet outil correspond à mes besoins. Je doute que vous-même y trouviez votre bonheur.
Référence complète : Business Process management with JBoss jBPM, a practical Guide for Business Analysts – Matt Cumberlidge – Packt publishing 2007 – EAN: 9 781847192 36 3
Note : 7 ; Un tour d’horizon clair concis et efficace
Est-il possible de faire un tour d’horizon introductif d’OSWorkflow en moins de 200 pages ? De toute évidence : oui, et cela sans faire particulièrement de concessions au sujet traité. Cet opuscule est en effet découpé en 8 chapitres, chacun focalisé sur une facette précise.
Le premier chapitre, comme il se doit traite de la vue d’ensemble d’une SOA animée par un moteur d’orchestration et de la vue de cette architecture par le WfMC. 20 pages suffisent à cela.
Le second chapitre nous donne déjà toutes les clés sur les capacités d’OSWorkflow en nous présentant les éléments les plus importants de la définition d’un workflow avec OSWorkflow et comment le tester !
A partir du chapitre 3, on rentre dans des aspects plus pointus : écrire du code Java qui s’interfacera avec le moteur de Workflow ! Les choses sont exposées simplement et progressivement, on n’est jamais perdu. Le chapitre 4 termine les aspects applicatifs généraux en évoquant l’intégration du moteur au sein d’une application.
C’est à partir du chapitre 5 que sont traités les aspects avancés. Ils ouvrent de nouvelles perspectives et sont rafraichissants sur ce point. Le chapitre 5 (justement) est un bon essai en ce sens, mais tout en donnant une bonne idée sur ce qu’est l’intégration d’un moteur de règles, il n’est guère convaincant. Et quitte à parler Open-Source, pourquoi ne pas avoir plutôt évoqué Jess ?
L’intégration de Quartz, évoquée au chapitre 6 est plus intéressante, car elle permet d’imaginer des architectures non seulement basées sur des workflows, mais également asynchrones . Là encore les exemples sont suffisamment simples et complets pour donner une bonne idée de la chose.
J’ai particulièrement apprécié le chapitre 7 et son traitement des CEP (complexe events processing) avec ESPER. C’est en fait la première fois que je vois évoqué concrètement la mise en œuvre de ce concept. Bravo !
Le chapitre 8 est un peu l’inattendu de cet ouvrage, puisqu’il ne traite rien de moins que le BAM ! L’implémentation est faite avec Pentaho BI (qui est plutôt une suite qu’un framework Open-Source), mais l’ensemble est convaincant.
Voici donc un opuscule qui remplit globalement ce que l’on attend de lui : un tour d’horizon du moteur de workflow, avec des exemples. Il vous sera incontestablement utile si vous souhaitez mettre en œuvre OSWorkflow, mais seulement au début, car il limite ses ambitions aux aspects introductifs, ce qui constitue le point faible du livre.
Référence complète : OSWorkflow, a guide for Java developers and architects to integrating open-source Business Process Management – Diego Adrian Naya Lazo – Packt Publusing 2007 – EAN : 978 1 847191 52 6
Parlons net : aujourd’hui OSGi est la seule alternative qui marche à la pantalonnade “Java Modules” qui ne cesse d’être repoussée de version en version de Java. On ne saurait affirmer que nous les auront pour la version 9, mais on sait déjà que les développeurs n’auront pas accès à l’écriture de modules.
OSGi marche et depuis longtemps. Par le biais de la RFP156, cette “SOA ina JVM” n’entends pas rester cantonnée à un rôle de faire-valoir par rapport à Java Module, mais à s’étendre à d’autres environnements et langages. Sont principalement visés: C, C++ et Javascript ; mais les autres environnements sont évidemment bienvenus.
Cette RFP est assez sommaire, voir superficielle. Elle fait le point sur les travaux des différentes équipes et s’en sert comme base pour les requirements listés à partir de la page 9.
Et sur les autres fronts
Il y a aussi un projet sur GitHub mais il ne semble pas bouger depuis au moins un an.
Mais on n’en reste pas là. Le Polyglot OSGi fait son chemin, comme nous le démontre cette présentation
Et après le RFP 156 centré sur C++, cet article fait le point sur OSGi pour Javascript, incarné par la RFP 159 (mais celle-ci reste un brin creuse).
Le choses bougent avec une réelle volonté côté OSGi ; Elles bougent au moins aussi vite que ne s’enlise ces java Modules, pas encore là et déjà vidés de leur substance…
Note : 7 ; Du concret sur l’ESB, mais un texte qui accuse aussi son âge…
Pas facile de s’y retrouver au sein du concept technico-marketing qu’est l’ESB ! Ce dont on a surtout besoin, c’est du concret. Et c’est exactement ce que l’auteur nous propose ici. Malgré son titre généraliste, le livre se focalise presqu’exclusivement sur la mise en œuvre de l’ESB open-source d’Apache, ServiceMix et de la norme JBI qu’il dessert.
En fait, les 2 premiers chapitres sont consacrés à la vue générale des problématiques d’intégration. Le premier chapitre présente les banalités habituelles sur l’ESB (mais plutôt bien présentées) et le second se focalise sur l’aspect plus technique en introduisant JBI et les « integration patterns ». Ce n’est qu’au chapitre 3 (on est déjà page 57) que ServiceMix, ou plutôt la vue globale de son architecture, est introduit.
A partir du chapitre 4, on passe en revue les différents types de binding, selon une complexité croissante. Tout d’abord un binding simple, dit conventionnel (chapitre 4), puis un binding « contract last » avec XFire (chapitre 5). Un binding plus complexe à trois niveaux est abordé au chapitre 8, mettant en œuvre des EJB, tandis que le binding de POJO est enfin abordé au chapitre 9. Puis c’est le tour de l’approche « gateway » ou « contract first » avec Axis (chapitre 10).
Les chapitres 6 et 7 font figure d’interludes. Il était difficile d’aller bien loin sans aborder les concepts de packaging et de déploiement des services ServiceMix, c’est chose faite au chapitre 6. De même, il est parfois utile de compléter la panoplie de bindings proposés par l’ESB, c’est l’objet du chapitre 7.
La problématique du transport est aussi un domaine où l’ESB permet une certaine souplesse. Le chapitre 11 montre comment accéder un Web Service au travers de JMS. Au chapitre 12, on voit comment effectuer le binding entre Java et XML (le langage natif de l’ESB) en utilisant en autre XStream. Enfin le chapitre 13 aborde le point plus complexe mais aussi plus exotique des proxys JBI.
Les derniers chapitres peuvent être vus comme des aspects avancés, donc pas forcément indispensables de prime abord. Le chapitre 14 aborde la problématique de versioning des Web Services, utile dans le cadre d’un SI « évolutif ». Le très long chapitre 15 traduit en services ServiceMix de nombreux integration patterns. L’agrégation de services est abordée au chapitre 16. Il s’agit d’un sujet plutôt avancé et c’est tant mieux car le propos n’est pas des plus clairs. On finit en ordre dispersé par un chapitre fourre-tout, avec les transactions, la sécurité le clustering et la vie des bêtes au chapitre 17. J’espère qu’il y a mieux ailleurs car ce n’est pas la joie.
Comme on le voit, c’est un tour d’horizon plutôt complet qui nous est proposé sur 400 pages. Il s’adresse clairement aux architectes. On y aborde les concepts et le code. Si le code Java est clair, il est fort dommage (et c’est mon reproche principal) que les configurations ServiceMix pourtant complexes soient aussi peu décortiquées. Leur compréhension reste ardue.
Ce type d’ouvrage est hélas sujet à l’obsolescence. Ne nous voilons pas la face, c’est bien le cas ici. ServiceMix (pour ne parler que de lui) a déjà changé de version majeure depuis un moment. Il n’a plus nécessairement la pertinence qu’il avait au moment de sa sortie…
Référence complète : Service Oriented Java Business Integration – Binildas C. A. – Packt Publishing 2008 – EAN : 978 1 847194 40 4
En gagnant en taille, l’Agile Tour Bruxelles gagne en standing ! Fini les sandwiches, bienvenue au buffet commerce équitable ! La qualité est au rendez-vous, mais l’attente est un petit peu longue. Difficile de d’être parfait en la matière.
De mon côté, je ne tiens pas réellement la forme. On sert aussi du potage en Belgique et je trouve en l’occurrence que c’est une très bonne idée. Surtout quand, comme ici, il est excellent.
Bref, l’ambiance est au beau fixe. On est bientôt d’attaque pour la seconde mi-temps !
Joanne Ho : Agile methodologies for research
Scrum nous enseigne que l’agilité s’applique bien au domaine des projets complexes, mais n’est pas conçue pour les domaines “chaotiques”. J’ai toujours (à tord ou à raison) classé la recherche dans cette catégorie. Joanne Ho nous donne l’occasion d’en savoir plus sur l’adéquation de l’approche agile pour les chercheurs.
L’un des points marquants du fonctionnement des chercheurs est qu’ils ne travaillent pas en équipe !
Pourtant la recherche est fondamentalement adaptée au mode itératif : étymologiquement cela ne signifie-t-il pas [Re]cherche ? Pour Joanne Ho, chercheur environnementale, on peut faire une correspondance entre le travail de chercheur (du moins le sien) et Scrum:
Le client : c’est la société (au sens large).
Le produit : de nouvelles connaissances
La Définition de terminé : la pertinence sociale
Enfin oui, Joanne utilise un backlog.
Un backlog très mouvant, il faut bien le dire, car :
Un item peut ne pas aboutir, nécessiter de nouvelles de nouvelles informations et donc être mis en suspens.
Il peut générer d’autres items.
Provoquer l’obsolescence d’items déjà présent dans le backlog.
Ce sont des choses qui existent déjà plus ou moins dans le fonctionnement des projets agiles. Sauf qu’il est très difficile d’avoir un plan de bataille fixe pour une itération. Donc la plupart du temps, Joanne dépile simplement l’item le plus prioritaire. Ce ne sont sont donc pas des sprints fixes et l’on est plus proche de XP que de Scrum, n’était-ce la présence du backlog… Mais si on ne sait pas se fixer précisément d’horizon aux itérations, celles-ci gardent-elles un sens ? La réponse est : oui ! Les itérations aident à faire du bon boulot en gardant le rythme. Sans itération, la masse de travail devant soi devient vite déprimante. Les itérations permettent de se voir avancer, de délivrer de la connaissance grâce auxquelles il sera plus aisé de prendre des décisions en connaissance de cause. Et les rétrospectives ? Mauvaise nouvelle : les chercheurs sont bien trop occupés pour se livrer à cela !
Joanne Ho nous donne ensuite en exemple un travail récent sur les biogaz. Comment cela s’est-il organisé ? Traditionnellement, la structure d’une telle équipe serait :
Le travail en silo est le standard.
Beaucoup de compétition interne.
Peu de transparence. Les revues de pair tournent vite aux critiques, voir aux insultes !
Les stakeholders sont des personnes imaginaires.
Une reconnaissance basée sur la quantité.
Pour cette étude, il a été constitué une équipe pluridisciplinaire, avec un mode de travail en pair et du test de groupe sur les hypothèses. Le processus était le suivant :
D’abord comprendre le problème, définir ce que l’on veut tester. Et donc faire l’expérience du stakeholder en allant sur le terrain.
Définir l’objectif, en définissant le critère de succès.
Une réflexion en binôme, pour modéliser toutes les facettes du problème. Ce travail doit produire des hypothèses.
Les tests unitaires, ce que Joanne appelle le “reality check”.
L’intégration continue : la mise en commun des éléments.
L’acceptance test : Une solution globale acceptable par le stakeholder.
En conclusion…
On peut utiliser l’agilité littéralement partout !
L’agilité est surtout une attitude.
Sans dialogue, on n’aboutit à rien.
Se déplacer pour aller réfléchir à différents endroits, sur le terrain.
Mettre toutes ses tâches dans un backlog.
Travailler en équipe est une chose nouvelle dans les université. ON n’a pas encore de modèle de fonctionnement pour cela.
En définitive, on fait émerger de meilleures questions, on prends d’avantage de plaisir ! La présentation de Joanne Ho reprends les thèmes développé dans son livre sur Leanpub.
C’était à mon tour, sur le créneau suivant. Pas de résumé de ma session, il ne faut pas pousser, mais la publication de ma présentation très bientôt, et celle-ci sous forme d’article lorsque je l’aurais complété !
La mesure de mon temps n’était pas non plus excellente. Je vais jouer le joker “état grippal” sur ce coup. Il faut dire que j’avais quand même prévu 20 exercice pour une heure. J’ai probablement été optimiste…
Domenico Musto : Event-Driven Architecture in Practice
Domenico est venu nous perler d’EDA. Il commence avec un point sur lequel j’achoppe : l’architecture doit être planifiée !
Enfin, surtout pour les gros projets d’après lui, et EDA n’est pas pour les petits projets. Mais pourquoi EDA ? Parce que l’architecture doit être “business drivent” , suivre la structure des flux d’évènements métier. Au contraire, les architectures SOA favorisent l’intégration point à point, aboutissant à un réseau inextricable quand le nombre de composants augmente.
Les flux EDA ne sont pas nécessairement des messages d’un MOM, c’est surtout un concept logique qui peut se traduire en :
Enregistrements d’une base de données.
Fichiers
Messages d’un MOM (quand même !)
Le support de ces messages, le canal, transmet différents types d’évènements qui peuvent être :
Des évènements
Des commandes
Des doc-messages ; ce dernier type de message est auto-porteur. C’est un paradigme “push” dans lequel le message comporte tout ce qui est nécessaire au traitement par le composant cible. C’est le modèle vers lequel on souhaite se diriger.
L’architecture EDA implique aussi de nombreux corollaires :
Le cas des données de référence : Elles doivent être embarquées en partie dans le doc-message. Cela me rappelle un certain nombre de considérations autour du MDM…
La consistance (de l’ordre) des identifiants d’évènements : leur ordre est-il garanti ? S’il ne l’est pas, il peut y avoir nécessité de versionner les entités afin d’en reconsidérer l’historique depuis n’importe quel évènement.
L’idempotence, ou la capacité à rejouer un évènement. Cette propriété va de pair avec le versionning.
L’architecture EDA se matérialise par un pattern publish-subscribe asynchrone au niveau de l’architecture. Cela n’est pas sans poser certains challenges en terme de tests. Mais dans cet ordre d’idée, une fois la capacité de test acquise, les composants sont relativement indépendants les uns des autres. La communication à base d’évènements rend aussi possible le business monitoring (le fameux BAM). Par contre les “évènements avec états” sont un autre niveau de challenge. Il est (en partie) adressé du côté des Web Services avec les corrélations, mais surtout avec les moteurs de workflow type BPEL / BPMN 2.0 Terminons avec les infrastructures techniques. Domenico s’est appuyé sur les “reactive extensions” de Rabbit MQ pour implémenter EDA. De mon côté je pense aussi à Storm que nous mettons en oeuvre actuellement…
Clôture et dernier verre !
Il est l’heure de nous rassembler à nouveau pour conclure ce second Agile Tour Bruxelles.
C’est de nouveau Bruno qui nous donne rendez-vous aux prochains évènements Belges : XP Day Benelux (le seul, le vrai…), l’Agile Tour Namur … et bien entendu l’Agile Tour Bruxelles de l’an prochain !
Comme l’an dernier aussi, les conférenciers ont droit à un cadeau local. Au menu : bierre, confiserie, chocolat et Schtroumph, entre autres…
Pas questions de se barrer comme des voleurs à Bruxelles ! L’an dernier, on avait dégainé la bière locale. Cette année on est visiblement monté en gamme (comme je le disais au début).
J’avais prévu mon train de retour suffisamment tard pour discuter un peu. Et nous l’avons fait à propos de l’informatique et de l’éducation, de la représentation trop faible des femmes et des minorités dans notre métier en nous demandant pourquoi et en ne sachant toujours pas vraiment y répondre…
Il est temps de s’en retourner. Un grand merci à la très sympathique équipe organisatrice. Et à l’an prochain, si tout va bien…
BPEL est, en quelque sorte, le modèle d’exposition du SOA. Ni les produits ni les ouvrages ne se bousculent pour autant au portillon, toutefois. J’étais donc assez content d’avoir mis la main sur un de ces livres, celui-ci étant traduit en français, en prime ! J’avoue ne pas en avoir eu pour mon argent (il faut aussi dire que le livre est particulièrement cher).
Le livre se découpe en deux grandes parties : la première est consacrée à la description de BPEL, avec une assez longue introduction sur les Web Services, la seconde est dédiée au survol de deux outils : Oracle BPEL Server et Microsoft Biztalk, ce dernier n’étant traité que de façon superficielle.
La première partie (celle sur BPEL), débute par 2 chapitres introductifs. Le premier introduit les concepts généraux de SOA, des ESB et de l’orchestration de services en général. Sans être un chef d’œuvre, il donne un bon panorama de la question. Le second introduit les normes liées au Web-Services et la pente est plutôt raide, j’ai fini par décrocher.
De cette première partie, ce sont en fait les chapitres 3 et 4 qui traitent réellement de la grammaire BPEL. Ils sont à mon sens les plus importants de l’ouvrage et me laissent un sentiment mitigé. Certes, le boulot est fait et la grammaire présentée, mais on sent l’auteur souvent plus pressé de présenter des fragments de XML que d’exposer l’explication correspondante. J’avoue que le propos est souvent difficile à suivre, à défaut d’être passionnant (ce qu’il n’est pas), et j’ai régulièrement perdu pied. Au final, le livre m’a quand même bien aidé à voir la « big picture ».
L’une des plus-values de ce livre est probablement de montrer comment tout cela se met en œuvre avec un serveur BPEL. Deux d’entre eux sont présentés, mais c’est surtout Oracle BPEL server qui illustrera le propos. Les chapitres 5 et 6 (soit 125 pages) sont consacrés à cela.
Le chapitre 5 est particulièrement intéressant car il expose non seulement l’architecture d’Oracle BPEL server mais explique également comment les fichiers sources sont organisés, comment s’effectue le déploiement, ainsi que l’utilisation des outils de développement (a.k.a. BPEL Designer). Le chapitre 6 consacré aux aspects avancés du produit est également intéressant, surtout grâce à la présentation de l’intégration de WSIF au sein de l’outil.
La partie dédiée à Biztalk server qui termine l’ouvrage (chapitre 7) est un ajout dont on aurait bien pu se passer : la présentation est inintéressante et présente essentiellement un défilé de copies d’écrans sans réellement exposer la philosophie et l’architecture du produit. On en ressort aussi ignorant qu’on y est entré.
Si vous cherchez un ouvrage traitant sérieusement de BPEL, soyez lucide, il y a peu de choix. Celui-ci n’est peut-être pas obligatoire, mais vous allez tomber (ou retomber) dessus assez vite. Mais le livre ne fait pas briller les yeux. Les middleware de workflow ne sont pas forcément non plus des sujets « trendy » d’où le déficit d’ouvrages…
Référence complète : BPEL pour les services Web 2ème édition, Orchestration de services web avec BPEL : guide pour architectes et développeurs – Matjaz B. Juric, Benny Mathew & Poornachandra Sarang – Packt publishing 2006 – EAN : 978 1 847192 16 5
… En fait, cela aurait dû être “le tour de Varnish en 80 jours” … cela s’est avéré trop long, nous nous sommes donc repliés sur 30 minutes !
Varnish, j’en entends parler régulièrement, surtout quand il s’agit de gros, de très gros sites. Mais jusqu’à présent, je ne savais pas vraiment ce que c’était. La présentation que nous a fait Dridi Boukelmoune chez Zenika nous a éclairé sur la bête.
Varnish, c’est quoi ?
C’est un cache HTTP. Plus exactement un reverse proxy cache HTTP. Ce n’est ni le premier, ni le seul. Pourquoi donc l’évoquer ? Comme je l’ai dit, on trouve Varnish dans les grosses, les très grosses infrastructures Internet. Car outre sa remarquable stabilité, ce sont ses performances très élevées qui ont fait la réputation de Varnish. Bien qu’issue de Varnish Software (la partie commerciale de Varnish), cette petite Vidéo fait un bon résumé de la situation.
Bref, Varnish, c’est un cache HTTP très performant car travaillant au plus près de la pile TCP/IP.
Pas d’IHM sexy pour configurer la bête. Varnish est fait pour les admmins sys barbus et se configure à l’aide d’un DSL : le VCL.
Configurer Varnish avec VCL
VCL c’est plus qu’un script de configuration, c’est un DSL qui est ensuite compilé en C. Pré-compilé, devrais-je dire, car bien sûr ce code C est lui même compilé ! Nous l’avons évoqué, Varnish est focalisé sur la performance, et on ne fait pas de choses performantes avec des mécanismes dynamiques ! Malgré tout, le changement de configuration peut être opéré à chaud.
Time to live
De base, Varnish gère son cache en TTL, mais on peut y inclure certaines variantes:
En fonction de l’encoding
En fonction du navigateur utilisé
En fonction de la compression
Les règles par défaut
Tout ne doit pas aller en cache ! Le VCL permet d’ajuster ces règles, mais par défaut Varnish stipule que :
Il n’y a pas de mise en cache d’une ressource si elle est liée à un cookie.
Pas de mise en cache si il y a des informations d’authentification.
Seules les requêtes GET et HEAD sont mises en cache. Les requêtes POST ne le sont pas.
Varnish gère les “variantes” en s’appuyant sur l’en-tête HTTP vary qui permet d’indiquer explicitement un élément à associer à la décision de cache.
Invalidation ou prolongation
Au-delà de la règle de fonctionnement de Varnish, qu’il s’agisse des règles par défaut ou d’une configuration qui s’en écarte, il est possible d’exclure des ressources du cache à l’aide de plusieurs mécanismes.
L’invalidation des ressources est possible, que ce soit sur une base individuelle ou suivant une expression régulière. Elle peut être opérée en ligne de commande ou via le VCL.
L’option la plus radicale d’invalidation est la purge. La ressource est retirée du cache, il n’y a plus moyen de la ressusciter une fois cela fait.
Varnish possède aussi une notion de ban. Il permet d’invalider un objet du cache, mais sans en entrainer son nettoyage.
A contrario on peut prolonger une ressource au-delà de ce que prévoit initialement les règles de Varnish, avec la notion de “grâce” qui permet de prolonger un contenu à priori périmé. Ce mécanisme peut s’avérer utile en cas de défaillance du back-end.
Mais comment ça fonctionne le VCL ?
Ecrire du VCL, c’est presqu’écrire du C (c’est probablement pour cela que c’est facile à compiler…). Varnish propose un certains nombre de “looks”, des template méthodes qui sont appelées par Varnish si elles sont implémentées. Il suffit alors d’implémenter la fonction en question pour s’insérer dans le cycle de vie du cache, et d’y utiliser les fonctions que Varnish met à notre disposition pour bannir un objet, par exemple.
Bien sûr, il faut pour cela connaitre le cycle de vie des objets
Et voici ce à quoi peut ressembler un bout de configuration Varnish :
sub vcl_recv {
if (req.request == "PURGE") {
if (!client.ip ~ purgers) {
error 405 "Method not allowed";
}
return (lookup);
}
}
Comme on peut l’imaginer, cet élément de configuration vient “hooker” l’état recv, en suivant le pattern “template method”.
Au-delà de la configuration
Director : Varnish fait du load balancing !
Enfin, pas tout à fait du load balancing, mais presque !
Un director est un groupe de back-ends clusterisés pour lesquels on établit une stratégie de redirection. Le but premier n’est pas de faire du load balancing, mais plutôt de maximiser les chances d’obtenir une ressource.
Maintenant, on peut aussi s’en servir pour faire du load balancing !
Etendre Varnish avec les modules
Outre la possibilité qu’offre le VCL d’y introduire du code en C, la méthode la plus élégante d’étendre Varnish est d’utiliser les modules, ce qui est possible depuis la version 3 de l’outil.
Dridi a d’ailleurs écrit un article (sinon l’article de référence) sur ce sujet, sur le Blog de Zenika.
Administrer l’outil
La console
On n’est pas chez les touristes. Ici de base, l’administration c’est la ligne de commande avec varnishadm ! Certaines des opérations que l’on peut faire avec sont même scriptables pour être intégrées dans un sh. Du classique pour les admins, donc.
Le bundle commercial de Varnish propose la Vanish Administration Console (VAC) qui est un outil Web. Mais comme toujours dans ces cas là, on ne peut quand même faire l’impasse sur la ligne de commande.
La gestion des logs
C’est un sujet d’attention particulier. Le loge peuvent rapidement ralentir terriblement les traitements. Varnish a pris une option radicale à cet égard : les logs sont en mémoire et sont en binaire ! Et Varnish propose un ensemble d’outils pour y accéder et les exploiter (varnishlog, varnishncsa)
Vers l’infini et au-delà…
En résumé
Le point essentiel, celui qui fait choisir Varnish, c’est qu’il s’agit d’un cache HTTP ultra-performant à même de décharger efficacement le back-end dans le cas de sites à très fort trafic. C’est LE cas d’utilisation. Pour un site n’ayant pas un très fort trafic, Varnish sera de très peu (et plus probablement d’aucun) intérêt.
Varnish en 5 étapes
Voici la démarche condensée de mise en oeuvre que nous propose Dridi :
Cacher le contenu statique
Configurer la compression
Cacher le contenu semi-statique
Automatiser l’invalidation
Améliorer le back-end
Les autres fonctions de Varnish
Bien que sa fonction essentielle soir le cache HTTP, on ne peut ignorer ce que Varnish sait faire d’autre :
Bien entendu, nous l’avons évoqué, Varnish peut servir de reverse proxy, bien que ce ne soit pas sa vocation première.
Merci Dridi !
Dridi n’est pas seulement un excellent collègue chez Zenika, son intérêt et sa maitrise croissante sur Varnish l’ont amené à en devenir un contributeur ! Il est entre autre chose l’auteur du module QueryString.
La présentation dont Dridi nous a gratifié fera partie de sa présentation des petits déjeunes planifiés sur Lyon et Paris, consacrés à Varnish. J’avoue que cette présentation en 30 minutes (30 minutes et 18 secondes, précisément) était un peu ardue pour moi, car faite un peu sans concession. C’est mon seul reproche. Elle présente clairement les fonctions et possibilités de l’outil et l’enthousiasme, la passion devrais-je dire de Dridi pour ce projet open-source font beaucoup au plaisir que j’ai eu à l’écouter.
Le consortium Web RTC est soutenu par Google et Mozilla, entre autres, avec le but avoué de supporter cela dans leurs browsers respectifs. C’est également un groupe de travail à l’IETF ainsi qu’au W3C.
Voir aussi l’excellente présentation faite par Google lors du Google IO 2013 ; la vidéo de cette présentation est incluse dans les slides. La présentation faite lors du Google IO de l’année précédente mérite aussi que l’on s’y arrête.
En pratique…
Dans la pratique, il s’agit de 3 ensembles d’API :
MediaStream API : Elle permet d’échanger vidéo et son, nottament.
RTCPeerConnexion : qui permet de maintenir des connexions pair à pair entre machines pour échanger des streams. Cette connexion peut être obtenue avec ou sans serveur intermédiaire en fonction du protocole retenu. Hadopi aura peut-être quelque chose à dire là-dessus…
RTCDataChannel : pour les échanges d’autres types de données, par exemple pour les jeux.
Disponible en version papier (il a fait l’objet d’une note de lecture), cet ouvrage l’est aussi en version électronique. La licence Créative Commons nous permet de profiter de son contenu.
Note 5 : Un propos qui serait clair s’il n’était alourdi par la présentation de 2 ESBs et qui a prématurément vieilli.
Pour bien comprendre ce qu’est un ESB, le mieux reste encore de le mettre en pratique. C’est l’objet de ce livre : mettre en œuvre non pas un mais deux ESB et de comparer leurs cas d’utilisation. 11 chapitres sur 235 pages regroupées en 3 parties auxquelles il faut ajouter les 50 pages d’annexes sont nécessaires à ce défi.
La première partie est dévolue à la découverte du monde de l’intégration en général et de l’ESB en particulier. Le premier chapitre nous parle des cas d’utilisation des ESBs dans le monde des architectures J2EE. En fait, il va plus loin que cela en nous proposant un « hello world » avec chacun d’entre eux. C’est une bonne mise en jambe.
Après la présentation générale, vient l’architecture. Mule et ServiceMix (car c’est d’eux dont on parle) sont présentés du point de vue des concepts architecturaux, en empruntant largement les représentations officielles. Mais les auteurs montrent aussi les différents concepts en illustrant avec des fragments de code. Là aussi, c’est tout bon.
Présenter 2 ESBs présente aussi des difficultés. Ce chapitre 3 consacré à la mise en œuvre jongle entre les 2 plateformes. Cela rends la lecture compliquée et les 35 pages de ce chapitres semblent denses, sinon fouillis. Il eut été préférable de consacrer un chapitre à chacune des cibles.
Cette première partie se conclut par le chapitre 4 au cours duquel on va réaliser un mini-projet d’intégration avec Mule et avec ServiceMix. On y trouve aussi une évocation de Spring Intégration, encore balbutiant au moment de l’écriture de l’ouvrage mais qui soulève apparemment l’enthousiasme des auteurs.
La seconde partie est une plongée en profondeur dans les fonctionnalités des ESB. Il compte également 4 chapitres. On débute par le chapitre 5 où il est question de traitements sur les messages. On y évoque bien entendu le content-based routing, la validation et la transformation des messages. Le tout abondamment illustré de code avec en complément de Mule et surtout de ServiceMix : Apache Synapse et Camel.
Le chapitre 6 traite des connecteurs, de la manière dont ils s’intègrent et ils s’utilisent. On y passe en revue la connexion aux fichiers, à JMS, l’accès aux données via JDBC au mail, à JNDI ou au FTP. Chaque fois ServiceMix semble un peu mieux traité que son rival. Les 50 pages de ce chapitre ont un peu des allures de catalogue mais tout est clairement expliqué, illustré de schémas et de code, donc c’est O.K.
Le sujet peut paraître désuet aujourd’hui, pourtant il reste important : l’accès aux services Web SOAP est le thème du chapitre 7. Les deux plateformes s’appuient sur CXF aussi bien pour invoquer que pour être appelés. Le WSDL est déjà lui-même un peu touffu, il ne faut pas s’étonner que ce chapitre ne soit pas très simple d’accès. Last but not least, ce chapitre évoque aussi quelques normes WS telles que WS-Security ou WS-Adressing. Ca ne fait rien pour alléger le propos.
Cette seconde partie se conclut par un chapitre dévolu à la gestion d’erreurs et à la sécurisation des ESBs. C’est pratiquement un challenge d’y comprendre quelque chose. Mais c’est surement un sujet sur lequel on peut revenir plus tard, une fois que l’on s’est réellement approprié le sujet. Car les explications ne sont pas évidentes quand on débarque…
La 3ème partie est consacrée à des « case studies » qui s’avèrent en fait être un peu plus que des études de cas, mais des sujets avancés dans la mise en œuvre d’ESB. Le premier chapitre de cette dernière partie qui en compte 3 est consacrée aux Enterprise Integration Patterns de Gregor Hope. Après une courte introduction au sujet, on plonge dans la réalisation d’un système de réservation pour 3 restaurants en intégrant progressivement différents patterns des EIP. On passe ainsi du CBR au publish-subscribe tout en allant chercher des données en base… cela devient plutôt complexe surtout qu’il faut de surcroit faire cela sur 2 plateformes.
Je me demandais à quel moment on allait parler de monitoring. La réponse est : c’est au chapitre 10 ! On continue avec notre cas d’utilisation sur les restaurants et c’est aussi l’occasion d’aborder d’autres patterns comme le Message Store (c’est une base de données XML, eXist qui est utilisée ici). Comme on pouvait s’y attendre, on aborde aussi JMX. Là aussi devoir traiter 2 plateformes complique terriblement le propos. C’est d’ailleurs Mule qui tient la corde ici, il est mieux outillé pour gérer les instances de production. Pour ServiceMix, il faut en gros se tourner vers JConsole…
L’ouvrage se conclut sur le chapitre 11 et l’intégration d’un moteur de workflow ! Ca ne rigole plus et c’est même un peu trop pour le livre. Logiquement, c’est jBPM qui a été choisi. Mais on consacre aussi quelques pages à Apache ODE (qui semble aujourd’hui moribond). Je pense qu’on aurait pu faire l’économie de ce chapitre pour mieux traiter séparément les deux ESBs dans le reste du livre.
Les sujets abordés deviennent parfois ardus, mais le texte est globalement de bonne qualité et bien illustré. Comme je l’ai dit, il est rendu complexe par le traitement parallèle, je dirais presque schizophrénique de deux plateformes. Plus gênant, les exemples de code ne semblent pas fonctionner directement. Ils demandent au minimum un peu de bricolage. Trop pour que l’on s’amuse à tous les tester. Autre grand regret : la vitesse d’obsolescence. Le texte traite de ServiceMix 3.x au moment même ou ServiceMix (qui est très différent) apparaît. On en est aujourd’hui à la version 4.5.x ! Il en va de même pour Mule qui était en version 2.0 au moment de la rédaction et qui est aujourd’hui en 3.4 !
Pour ces raisons, je ne saurais conseiller ce texte aujourd’hui. Il mériterait une mise à jour, car les évolutions de ces deux ESBs sont maintenant en rythme de croisière, avec le travail de fond nécessaire sur les exemples. Malheureusement, je ne pense pas que cela arrivera…
Référence complète : Open Source ESBs in Action – Tijs Rademakers & Jos Dirksen – Manning 2009 – ISBN : 1933988215 ; EAN13: 9781933988214
Software Freethinker 
