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
Jack Clark for TheRegister quoting Google senior systems engineer, Jeremy Cole’s talk at VLDB:
“Were running primarily on [MySQL] 5.1 which is a little outdated, and so we’re moving to MariaDB 10.0 at the moment,”
I’m wondering how much of this decision is technical and how much is political. While Jack Clark’s points to the previous “disagreements” between Google and Oracle, when I say political decisions I mean more than this: access to the various bits of the code (e.g. tests, security issues), control over the future of the product, etc.
J’avais déjà évoqué la chose précédemment, aujourd’hui le mouvement est clairement enclenché : c’est la totalité des instances MySQL qui passent sur MariaDB !
Les raisons qui conduisant à ce changement n’ont probablement pas la limpidité de la déclaration officielle. Le “vieillissant” MySQL est certainement l’un des facteurs, cela m’étonnerait que ce soit le principal. Pour ma part j’évoquerais en priorité :
Une dépendance à Oracle qui gêne le géant de Mountain View
Un manque pratiquement total de possibilité d’agir sur la base de code, les tests n’étant plus accessibles.
En contrepoint, le fait de travailler avec un petit éditeur qui a besoin d’une solide référence et qui est donc prêt à se plier au désidérata du géant de l’Internet a un intérêt évident…
Dès les premières pages, cet ouvrage m’a rappelé le « Scrum en Action » de Guillaume Bodet. Pour une excellente raison : ce dernier ouvrage est une adaptation très proche de celui-ci. La plupart des choses que j’ai pu en dire s’appliquent donc de manière égale ici.
Il s’agit d’un roman, ou plutôt d’une courte nouvelle retraçant la transition à Scrum d’une équipe sur un projet au bord du désastre, à deux doigts de couler la boite. C’est la déprime, le CTO va voir le client qui lui fixe un ultimatum. Et puis au bar, il rencontre un coach Scrum : c’est la révélation. Il l’invite à faire passer son équipe de développement en Scrum. Oh, bien sûr il y a un peu de résistance par ci par là (sinon, c’est vraiment pas crédible), mais tout le monde finit par s’y mettre et devenir enthousiaste. Alléluia, dès le premier Sprint les problèmes disparaissent : dette, tests, hop ! C’est résolu ! Dès le second, le client est enchanté par la délivery incrémentale (car contrairement à la plupart des clients, il ne demande pas une livraison unique en fin de projet). Bref, ils ne se marient pas à la fin de l’histoire, mais oui le CTO résous ses problème de couples et fait des gamins.
L’histoire est peu crédible, même si les différents morceaux pris indépendamment le sont. C’est le strike qui ne l’est pas. La lecture est agréable, aucun doute, c’est bien écrit. De plus les auteurs savent passer quelques messages forts de manière très opportune. Et le tout se complète sans problème dans la journée.
Je suis réellement perplexe vis-à-vis d’une présentation aussi édulcorée de Scrum. Jerry, le coach dit à un moment « le changement, c’est difficile », mais le texte laisse penser que c’est facile. L’un des développeurs joue le « senior résistant » mais se laisse convaincre en 5 minutes et devient même Scrum Master à la fin du livre ! Voilà bien peu de rapport avec la vie réelle. L’un des bons points est de présenter de manière progressive les différents aspects de la mise en œuvre de la méthode, dans le contexte de manière bien développée et introduite par Jerry. Mark le CTO joue le rôle du perplexe positif, tandis que Rick est le gros looser chef de projet qui perd son boulot mais devient P.O. dans la joie et la bonne humeur car on est chez les bizounours.
Je ne saurais conseiller cette lecture au nouveau venu qui ne connaît pas l’agilité car je trouve la présentation trop fallacieuse. C’est pourtant la cible visée. Si vous êtes un agiliste confirmé sachant prendre du recul par rapport à une lecture, celle-ci peut vous faire passer un bon moment !
Référence complète : The Power of Scrum – Jeff Sutherland, Rini Van Solingen & Eelco Rustenberg – CreateSpace 2011 – ISBN : 1463578067 (Kindle edition)
“First draft of a Report on the EDVAC”, c’est ainsi que l’histoire gardera trace de la publication qui définira l’architecture des ordinateurs pour (au moins) les 70 années suivantes !
Une paternité contestée…
Il en va hélas souvent ainsi des contributions majeures. Ce papier a été publié le 30 Juin 1945. Ce travail est l’émergence des réflexions du mathématicien, sans aucun doute après avoir travail sur ENIAC d’une part, et sur le Mark I d’autre part. C’est sans doute la raison pour laquelle Eckler et Mauchly contestent l’originalité des idées de Von Neumann, alors même que l’ENIAC n’était pas réellement un ordinateur programmable, mais plutôt recevable.
De l’autre côté, il semble qu’Howard Aiken, le père du Mark I qui lui était bien programmable n’ait jamais pris de position de controverse !
L’article
Je pense pour ma part qu’il faut rendre à Cesar ce qui est à César. Certes, Von Neumann n’a pas tout inventé, mais Eckler et Mauchly d’une part et Aiken de l’autre ce sont aussi inspirés de prédécesseurs : Vannevar Bush et même avant cela Babbage !
L’article que je met à disposition ici n’est pas l’original, mais une reproduction fidèle, le texte étant lui l’original, avec une mise en page aussi fidèle que possible à l’originale. L’IEEE est à l’origine de cette reproduction faite en 1993.
Pour bien fonctionner, l’exécution des requêtes s’appuie sur des plans d’exécution qui sont eux-mêmes optimisés par l’optimiseur du serveur : quel table doit-on requêter en premier, doit-on filtrer avant ou après, utiliser un index ou scanner la table, etc… Et l’optimiseur ne fait pas cela dans le vide, il utilise les statistiques des tables.
Ce court livret qui compte moins de 50 pages ne traite que des statistiques : quelles son-elles, comment sont-elles mises à jour et quand et comment sont-elles exploitées par le moteur de requête. Ce texte est tellement court, que l’auteur parle à plusieurs moment « d’article » dans le texte. Mais bon, il a un ISBN, donc…
Comprendre, c’est bien, savoir agir, c’est mieux ! L’auteur nous initie aux possibilités d’action sur les statistiques : les procédures stockées, les tables de statistiques et histogrammes elles-mêmes ainsi que les activations / désactivations totales et partielles de celles-ci, sans compter les statistiques filtrées.
Le livre compte deux parties, la seconde (un peu plus courte) est une série de problèmes / solutions qui reprennent et parfois approfondissent les points vus dans la première.
Le livre est court et de bonne tenue. J’ai juste deux petits regrets :
J’aurais aimé une ou deux (pourquoi pas 3 ?) études de cas avec des plans d’exécution, la mise en reliefs des statistiques correspondantes, les actions et la mise en lumière des différences de résultats.
L’auteur évoque à quelques reprises des outils plus pointus et même des DMV non documentées. On aurait pu y plonger.
Connaître le fonctionnement des statistiques n’est pas un « game changer » la plupart du temps. L’auteur le dit d’ailleurs : par défaut ce que fait SQL Server marche très bien dans la grande majorité des cas. Mais le ratio temps de lecture / amélioration des compétences est vraiment excellent. Pourquoi s’en priver ?
Référence complète : SQL Server Statistics – Holger Schmeling – Simple Talk Publishing 2010 – ISBN :
… 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.
Il n’est pas dans mes habitudes de parler de moi dans ce blog. Je vais le faire aujourd’hui, ce qui fait de ce post un texte un peu particulier.
Parler de soi n’est pas s’apitoyer. Pas nécessairement, en tout cas pas ici. Si je compte bien, c’est la première fois que je me livre à l’exercice. Un post vraiment spécial pour moi, donc.
Je suis venu te dire que je m’en vais
J’ai passé 5 ans au bureau du Scrum User Group, un peu plus, même. J’y étais depuis sa création par Luc Legardeur, jusqu’à aujourd’hui sans interruption. Cela faisait de moi l’ancien du groupe.
Et cela se termine aujourd’hui.
Etre l’ancien ne me confère aucun statut particulier, et c’est tant mieux. Par contre il n’a jamais été concevable pour moi de figurer au bureau de l’association et de rester inactif. Je vois cela comme une forme d’escroquerie : “voyez, je suis au bureau du SUG, d’ailleurs je l’ai mis dans mon profil LinkedIn (ce que je n’ai jamais fait, d’ailleurs)”. Si c’est pour ne pas contribuer aux actions de l’association…
Quitter un engagement de si long terme me donne une petite impression de vide, d’inconfort. Même si je suis convaincu d’avoir pris la bonne décision, lâcher cette situation réconfortante ne s’est pas fait aisément. Je sais, vous allez me dire que ce n’est pas comme si j’avais quitté mon boulot. C’est vrai, mais quand même…
Là où cela me laisse perplexe, c’est que ce changement qui semble normal avec un regard d’agiliste, a exigé de me faire violence. La stabilité, j’aime bien. Mon petit confort, j’aime bien aussi. Aller vers l’inconnu, confronter une situation nouvelle : pas trop. Oh, une fois que c’est passé, que j’ai réussi de nouvelles chose, accompli une action dont je suis fier ou pris un râteau sans trop de dommages, ça va. Je suis même fier en fonction des cas (ou raisonnablement pas trop honteux).
Bref, suis-je vraiment un agiliste au fond de moi ? Est-ce le “moi conscient” qui a pris la barre, sachant que la démarche agile est la bonne, mais heurte le “moi inconscient” qui lui est bien frileux ? Je vais arrêter ici ma psychologie à 2 balles, je vous ai probablement perdu. En fait je me suis perdu moi-même.
Pourquoi ?
C’est le moment que vous attendez : celui où je vais cracher mon venin ! Cela ne va pas arriver. Non seulement cela ne serait pas correct, mais il n’y a pas lieu de le faire. Nous avons fait de nombreuses choses en 5 ans, et je suis fier d’y avoir participé. Il suffit de regarder le Meetup pour s’en rendre compte ! Que vais-je mettre spécialement au crédit de cette période ?
Les personnes que j’ai pu côtoyer au bureau. Plus spécialement, certaines dont j’étais plus proche. Mais je ne vais pas citer de noms.
Les rencontres. A l’occasion des soirées, des Scrum Day ou des Scrum Beers. Notre communauté est riche de personnes avides de connaissances et de réflexions.
Je garde un excellent souvenir non seulement des rencontres lors des évènements, mais aussi des échanges avec les orateurs lors des préparations. On m’a régulièrement remercié pour avoir géré les appels à orateurs. La vérité, c’est que ce fut chaque fois un plaisir !
Alors, pourquoi quitter ?
Pour des raisons purement égoïstes ! Oui, faire partie d’un groupe et s’entraider sont des valeurs importantes. Mais cela ne doit pas se faire au détriment de nos motivations personnelles. Surtout quand il s’agit de bénévolat. Pour moi, il s’agit de prendre du plaisir à faire ce que je fais, d’avoir envie d’abattre le travail qui est devant moi. C’est aussi comme cela que j’arrive à donner le meilleur de moi-même.
Pour diverses raisons, ce n’est plus le cas. Les choses ne vont pas mal, ni pour moi ni pour l’association. Mais cela ne corresponds pas à mes aspirations actuelles.
La page est donc tournée.
Moving on…
Mon départ du SUG ne va rien changer à l’association. Ce n’est pas un regret, mais une source de satisfaction. Bien faire son boulot, c’est apporter une contribution utile sans se rendre incontournable. Montrez-moi une personne dont l’absence met un groupe en péril, je vous présenterais une personne qui ne fait pas son boulot jusqu’au bout. Dans certains cas, c’est même de la malhonnêteté.
Pour peu qu’il y ait quelqu’un pour reprendre le harnais, tout continuera comme avant. Je l’escompte bien, car j’ai bien l’intention de me rendre aux évènements que l’association organisera !
Très bien, mais quelles sont mes prochaines étapes ?
Pour l’instant, je reste sur mes projets actuels :
Deux conférences à préparer, à Bruxelles très bientôt et fin Novembre à Grenoble. Deux sujets différents que j’inaugurerai. Ca fait du boulot.
Tout cela sans compter ce Blog va bien m’occuper au moins jusqu’en Décembre. Et après ? Je ne sais pas. Je sais simplement qu’il est temps d’aller de l’avant.
Software Freethinker 
