Note de lecture : OSWorkflow, par Diego Adrian Naya Lazo

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.

image

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

Osworkflow: A Guide for Java Developers and Architects to Integrating Open-Source Business Process Management

https://www.goodreads.com/book/add_to_books_widget_frame/1847191525?atmb_widget%5Bbutton%5D=atmb_widget_1.png&atmb_widget%5Bhide_friends%5D=on

Note de lecture : Service Oriented Java Business Integration, par Binildas C. A.

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…

service-oriented-java-bi

Référence complète : Service Oriented Java Business Integration – Binildas C. A. – Packt Publishing 2008 – EAN : 978 1 847194 40 4

Service-Oriented Java Business Integration

http://www.goodreads.com/book/add_to_books_widget_frame/1847194400?atmb_widget%5Bbutton%5D=atmb_widget_1.png&atmb_widget%5Bhide_friends%5D=on

Google moves from MySQL to MariaDB

nosql:

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.

Original title and link: Google moves from MySQL to MariaDB (NoSQL database©myNoSQL)

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…

Google moves from MySQL to MariaDB

Le tour de Varnish en 30 minutes

… 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.

Le tour de Varnish en 30 minutes

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. 

L'architecture de Varnish

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

Varnish VCL

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 :

  1. Cacher le contenu statique
  2. Configurer la compression
  3. Cacher le contenu semi-statique
  4. Automatiser l’invalidation
  5. 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 :

  • Gérer le streaming
  • Utiliser des ACL
  • Structurer des architectures multi-tenant.
  • Tester son architecture, c’est à dire en pratique tester sa configuration VCL, avec le framework de test qui fait partie de la distribution.
  • Gérer le Edge Side Include (ESI)

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.

La présentation de Dridi est accessible ici.

En épilogue, je vous propose de jeter un coup d’oeil au manuel de référence de l’outil.

Note de lecture : Succeeding with Open Source, par Bernard Golden

Note : 7 ; Quand le monde du développement organisé traditionnel rencontre le monde du développement communautaire.

Cet ouvrage traite de l’évaluation des prouits open source et de leur intégration au sein des systèmes d’information d’entreprise. Pour ce faire, l’auteur a développé une méthode d’évaluation (qu’il a appelé OSMM pour Open Source Maturity Model). Je dois dire que l’auteur m’a étonné, car venant de toute évidence d’un monde plus traditionnel, il n’essaye pas de comparer l’open source selon les canons des produits commerciaux. Au contraire, il apprécie leur qualité justement au regard de l’absence d’objectifs commerciaux qui amène ces développement à progresser d’avantage en terme de satisfaction des utilisateurs utôt qu’en terme d’attraction des clients potentiels qui entraine souvent une boulimie des fonctionalités qui se fait au détriement de la qualité. Au cours de ses périgrinations, l’auteur est devenu un fervent supporter de l’open source, tout e conservant un jugement serein, ce qui l’a entrainé à construire l’OSMM.

Le processus d’évaluation développé ici est bien adapté à l’open source, car il est simple. En effet, pourquoi développer un modèle compliqué, alors que celui-ci n’évitera pas l’évaluation technique ultérieure. En fait, ce processus a juste pour objet d’établir un « go / no go » basé sur des critères tels que achèvement du produit, disponibilité de support, de documentation et de formation, et de mettre ces informations en vis-à-vis du type d’utilisation que l’on désire en faire : expérimentation, production ou projet pilote. On ne reste pas dans la simple théorie, car chaque point développé est très concrètement illustré par l’évaluation d’un produit Open-source connu : JBoss. Il aurait certainement été intéressant d’y mettre en vis-à-vis un produit moins haut de game et moins abouti, bref plus dans la moyenne des produits open source disponibles, mais c’est très bien quand même.

J’ai bien aimé ce livre, sa simplicité et son pragmatisme. Le reproche le plus important que je lui ferai et de ne pas développer l’aspect communotaire (ou au moins l’évoquer), par lequel un utilisateur se doit quand il le peut, aider les autres par son expérience acquise. L’auteur a trop tendance à inciter les utilisateurs à se placer dans une position de pur consommateurs (pourqoi mutuliser les connaisances au sein de l’entreprise, alors que chaque utilisateur peut directement interroger (et donc poser plusieurs fois la même question) la mailing liste sans que cela ne coûte rien ? Ormis ce point, il est bien que ce livre participe à placer l’open source dans une optique d’utilisation d’entreprise et non plus comme des développements de hobystes.

succeeding-open-source

Référence complète : Succeeding with Open Source – Bernard Golden – Addison Wesley / IT series 2004 – ISBN: 0-321-26853-9

Succeeding with Open Source

http://www.goodreads.com/book/add_to_books_widget_frame/0321268539?atmb_widget%5Bbutton%5D=atmb_widget_1.png&atmb_widget%5Bhide_friends%5D=on

Note de lecture : Spring Batch in Action, par A. Cogoluègnes, T. Templier, G. Gregory & O. Bazoud

Note : 7 ; Une qualité de prose qui fait honneur à la « in action » series, mais une lecture un peu lourde au total.

Mon premier contact avec ce livre a été teinté d’appréhension : il compte pas moins de 440 pages hors annexes, ce qui me semble beaucoup, je le dis sans ambage ! Puisque l’on en est aux présentations : le volume est découpé en 14 chapitres, eux mêmes regroupés en 3 parties. Il faut en plus compter une vingtaine de pages d’annexes. Cela nous donne une moyenne d’une trentaine de pages par chapitre. C’est beaucoup à mon gré, mais consistent avec le standard de la « in action » series. A propos de cette série, Manning fait beaucoup d’effort pour maintenir une ligne éditoriale de bonne qualité qui permet d’être rarement déçu avec chacun des opus. Nous verrons que ce volume fait honneur à la série.

La première partie s’intitule « background » et regroupe les deux premiers chapitres pour un total de 50 pages. Le premier d’entre eux nous fait faire le tour du propriétaire. Non seulement on y comprends l’architecture logique (finalement, Spring Batch c’est un framework-ETL Java) mais on va jusqu’à faire une mini-application de traitement (lecture, traitement et écriture) avec la configuration Spring correspondante. Impressionnant pour un premier chapitre !

Le second chapitre rentre plus avant dans les concepts sous-jacents du framework : job, métadonnées du job, step, etc… Le but de ce chapitre est de nous donner les clés pour décomposer une spécification de traitement en étapes décomposées. Bon boulot, à nouveau.

La seconde partie « core spring batch » est de loin la plus imposante du livre. Elle compte 7 chapitres et 225 pages. C’est donc un mini-livre à elle toute seule. C’est d’ailleurs à mon avis le problème le plus important du livre, mais je reviendrais là-dessus plus tard ! Le chapitre 3 qui débute cette seconde partie nous immerge dans la configuration des batches. Plus clairement : comment s’articule la configuration Spring d’une application Spring Batch. Il y a 5 niveaux d’entités hiérarchiquement emboitées à configurer (sans compter le repository de jobs) et le chapitre passe par le menu la manière de configurer tout cela avec les attributs qui vont bien. C’est un poil lourd, mais bien écrit.

Le chapitre 5 explore en profondeur la manière de lancer (et arrêter) les jobs : en ligne de commande ou en planifiant de différentes manières. Le tout est bien illustré par des diagrammes de séquence, entre autre chose.

Avec le chapitre 5, on attaque réellement le développement de traitements Spring Batch, en débutant par les composants de lecture. Le sujet est largement balayé en largeur sur 40 pages, que ce soit sur des fichiers plat, du JSON, du XML ou de l’accès aux bases de données. Rien à dire sur la manière dont le sujet est abordé, mais c’est quand même un peu long quand ce que l’on souhaiterait, c’est arriver au bout du chemin pour voir ce que cela donne !

Le chapitre 6 aborde fort logiquement le composant d’écriture. Si les aspects de base (field extraction, formatage) sont fort logiquement abordés, là aussi le sujet est abordé en largeur, avec non seulement l’écriture sur fichier, mais la production de XML, de file sets et l’écriture en base de données. Mais on aborde aussi l’écriture en flux JMS et l’envoi de mails. Là aussi je trouve que cela fait beaucoup pour une première passe, et paradoxalement, certains de ces sous-sujets sont traités un peu rapidement !

Toujours dans la même veine, le chapitre 7  nous présente les composants de traitement. Les items processors de Spring Batch recèlent nombre de richesses et il me semble difficile de faire des impasses par rapport à ce qui figure dans le texte. La lecture du chapitre me laisse cependant un léger sentiment de confusion, mais rien de bien grave. Les excellentes illustrations graphiques ou en code permettent de toute façon de se raccrocher aux branches.

Le chapitre 8 compte à peine 30 pages, mais elles recèlent une expertise qu’il serait dommage de rater. Il s’agit de la conception des reprises sur erreur avec Spring Batch. Excellent !

Cette seconde partie s’achève avec le chapitre 9 qui couvre l’aspect transactionnel des batches. Le sujet est traité de manière solide et claire en 25 pages, que ce soit sur les erreurs à ne pas commettre, sur la portée des transactions et les différents niveaux de transaction disponible (job, chunk,…). Rien à redire.

La 3ème partie du livre est consacré aux « sujets avancés » et le premier chapitre de cette partie, le chapitre 10, dédie 25 pages au contrôle d’exécution. Partage de contexte, flux alternatifs et même externalisation des définitions de job sont parmi les sujets traités.

Avec le chapitre 11, on commence à toucher du lourd, à savoir l’intégration d’entreprise. Les auteurs évoquent d’abord les styles d’intégration d’un point de vue architecture logique. Il n’est pas étonnant qu’ils fassent référence aux Enterprise Integration Patterns de Gregor Hope ! D’un point de vue pratique, la quarantaine de pages de ce chapitre s’appuie sur 2 fondations : Spring Integration d’une part et Spring MVC pour illustrer une intégration http/ReST. Il est juste dommage que les 2 approches ne soient pas mieux abordées en séquence afin de rendre la prose plus claire.

Ce livre ne rate pas le, oh combien important, sujet du monitoring. Le chapitre 12 fait du bon boulot là-dessus, que ce soit pour décrire la structure BDD supportant cela, pour décrire l’intégration JMX ou même pour éclairer l’usage de l’outillage prêt à l’emploi de Spring batch à savoir Spring Batch Admin ou JConsole.

Le chapitre 13 est vraiment un sujet avancé car il traite de scaling. Un chapitre sur lequel il est possible de faire l’impasse en première lecture.

Ce n’est pas le cas du dernier chapitre qui aborde la problématique des tests. Il le fait à 3 niveaux : tests unitaires, tests d’intégration et tests fonctionnels. Ces 3 niveau s’appuient sur JUnit est sur des helpers fournis par Spring batch. Je ne suis pas convaincu par ce qui est proposé du côté tests fonctionnels, mais les 2 autres niveaux sont OK.

Spring Batch in action est une bonne surprise. Les auteurs ont fait globalement un très bon travail à rendre le propos clair et l’apprentissage progressif. L bouquin reste hélas un gros pavé. Mais le framework est aussi beaucoup plus riche que je ne l’avais pensé au début. Pour en rendre l’abord plus digeste, je pense que les auteurs auraient dû découper la seconde partie en 2 : en traitant d’abord d’un cas d’utilisation simple n’utilisant qu’un sous-ensemble de chacun des 3 types de composants, puis une seconde itération pour les autres cas de figure. Au final, le volume du livre aurait un peu augmenté mais cela aurait permis au lecteur de faire l’impasse sur une centaine de page en première lecture !

Ce livre s’adosse à la version 2.1 de Spring batch, il est donc toujours parfaitement d’actualité, mais une révision sera certainement nécessaire quand la version 3.0 sera en GA.

Spring Batch in Action

Référence complète : Spring Batch in Action – Arnaud Cogoluègnes, Thierry Templier, Gary Gregory & Olivier Bazoud – Manning 2012 – ISBN : 978 1 935182 95 5

Spring Batch in Action


http://www.goodreads.com/book/add_to_books_widget_frame/1935182951?atmb_widget%5Bbutton%5D=atmb_widget_1.png&atmb_widget%5Bhide_friends%5D=on

MariaDB, plus fort que MySQL

On ne peut pas dire qu’Oracle se soit attiré la réputation d’une société ayant bien compris le modèle Open-Source. Parmi d’autres, MySQL en est une bonne illustration.

Ayant acquis la base Open Source par le biais de l’acquisition de Sun Microsystems, il me parait que le géant de la base de données a cherché avant tout à en faire un produit, plutôt qu’un projet open source. 3 éléments me confortent dans cette opinion :

  • Oracle seul décide de la roadmap MySQL
  • MySQL est positionné par l’éditeur en alternative à Microsoft SQL Server. Une stratégie perdante, car les produits ont un positionnement très différent.
  • Oracle verrouille les développements (patch ou fork) en ne releasant plus les cas de tests depuis plus d’un an !

La fondation MariaDB

Dès le rachat de Sun, le créateur de MySQL Michael “Monty” Widenius a créé le projet MariaDB. Comme il l’explique son but à l’origine était de conserver la communauté historique des développeurs du noyau MySQL, noyau qui était en passe de disparaitre.

J’avoue que bien que ce fork ait maintenant plus de 3 ans, il a échappé à mon radar. Pas seulement au mien visiblement, car il semble que son existence fut jusqu’à une date récente assez discrète. Il aura fallu la création de la fondation MariaDB pour booster sa visibilité.

Aujourd’hui MariaDB offre une alternative à MySQL

  • Compatible au niveau binaire
  • Offrant de nouvelles fonctionnalités marquantes.
  • Plus active que la base historique sur le volet des bus fixes.

MySQL semble avoir un peu perdu de vue sa nature première : non pas une base de données, mais un conteneur de moteur de bases de données. Tandis que MySQL vogue avec ses vieillissants MyISAM et Innodb, MariaDB nous propose de nouveaux engines: Aria, XTraDB (une évolution d’InnoDB), FederatedX (un engins utilisant d’autres SGBD en back-end), OQGRAPH (un moteur optimisé pour gérer les hiérarchies et les graphes) et SphinxSE.

Google à la rescousse

La communauté open source n’est pas la seule à s’inquiéter de la mainmise d’Oracle sur MySQL. Des sociétés de taille respectables pour lesquelles MySQL est une brique importante ont eu la même démarche.

L’annonce la plus marquante est sans aucun doute celle de Google annonçant un support au projet. Concrètement il s’agit d’y consacrer un développeur. Par rapport aux moyens dont dispose le géant du Web et l’importance structurelle de MySQL dans ses infrastructures, cela parait anecdotique, mais le message est là. D’après Widemius, d’autres société sont prêtes à aller dans le même sens, mais on n’a pas de noms…

Une alternative encore verte

Pour assoir une emprise sur le marché, il faut un packaging de bonne qualité. La fondation MariaDB propose des packaging prêts à l’emploi pour les plateformes Linux (Red Hat, Fedora, Debian, Ubuntu…) et Windows.

Mais point de distribution Mac ! Il faut passer par Homebrew avec compilation des sources et quelques petites manipulations … Ca ne va pas tout seul, autant le dire. Bref, ça va en rebuter quelques un. La fondation MariaDB explique que cette absence est due à leurs moyens limités.

Autre point faible : la documentation. Bon, elle existe, toutefois. Mais elle n’est pas vraiment au niveau. Pas de vrai autorail et les informations d’installations et de configurations sont assez éparses. Dans l’ensemble, les informations sont rassemblées sur le site ask monty. Bref, il y a encore à faire.

Côté bouquins, j’ai trouvé 2 titres sur MariaDB. Rien à voir avec la pléthore de livres sur MySQL.

Y aller ou pas ?

Aujourd’hui, je ne conseillerais à personne d’aller volontairement vers du MySQL, à moins que ce choix soit subordonné à un autre. Nombreux sont en effet les projets pour lesquels MySQL est sinon le choix par défaut, du moins un choix “pré-packagé”.

D’un autre côté, des distributions Linux commencent à venir avec MariaDB comme base par défaut en lieu et place de MySQL. De plus, il y a la “compatibilité binaire” revendiquée par MariaDB. Mais celle-ci doit encore se vérifier de contexte en contexte.

Côté Java, à priori MariaDB est toujours compatible avec le connecteur JDBC de MySQL. Mais il existe aussi un connecteur JDBC natif Maria DB.

La situation pour les autres langages est moins claire. Il existe bien un connecteur C dans ce qui est produit par la fondation, mais pour Python, Perl, etc… Il faut à priori utiliser les utilitaires gravitant autour de MySQL et faire des essais. Si l’on va faire un tour du côté de Stackoverflow, on voit que les choses ne sont pas si simples.

La tendance actuelle est un passage vers PostgreSQL (). Cette base est mieux qu’une alternative et est de plus en plus privilégiée à MySQL, non comme solution de replis mais en tant que solution techniquement meilleure.

Il me semble cependant qu’au vu de la roadmap déjà réalisée par MariaDB et de celle à venir, que cette alternative mérite considération, malgré les faiblesses dont il est fait mention.

Note de lecture : Open Source ESBs in Action, par Tijs Rademakers & Jos Dirksen

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…

open-source-esb-inaction-manning

Référence complète : Open Source ESBs in Action – Tijs Rademakers & Jos Dirksen – Manning 2009 – ISBN : 1933988215 ; EAN13: 9781933988214

Open-Source ESBs in Action: Example Implementations in Mule and ServiceMix

http://www.goodreads.com/book/add_to_books_widget_frame/1933988215?atmb_widget%5Bbutton%5D=atmb_widget_1.png&atmb_widget%5Bhide_friends%5D=on

Note de lecture : Alfresco Developer Guide, par Jeff Potts

Note : 5 ; Très complet, mais un poil indigeste.

Avec ses 500 pages, cet ouvrage ne cache pas ses ambitions de couvrir le sujet en profondeur. Il n’est découpé qu’en neuf chapitres, mais complétés d’annexes assez volumineuses couvrant les API sous forme de manuel de référence sur 70 pages.

Le chapitre 1 nous fait le tour du propriétaire sous l’angle de l’architecture. C’est ma fois fort réussie.

Au chapitre 2, on s’attaque au développement d’une extension d’Alfresco en utilisant Eclipse. Le but essentiel semble être de prendre de l’aisance sur l’environnement de travail. Toutefois j’ai trouvé la démarche un peu confuse.

Le chapitre 3 est particulièrement consistent, mais aussi très complet. Il aborde une facette différente d’Alfresco mais plus importante encore : la programmation de définition de contenus : création de nouveaux types, de propriétés, relations et facettes. Puis viennent les aspects qui viennent s’y greffer : programmation avec Java, les Web Services et PHP, customisation de l’IHM et des recherches, etc… Bref c’est particulièrement complet, mais le style rend tout cela hélas pas très facile à appréhender.

Le chapitre 4 fait suite assez logiquement, car il trait de tous les automatismes de traitement qui peuvent se greffer sur les contenus : actions, transformateurs, extracteurs, etc… Cela n’est en fait utile que si l’on a bien sûr l’intention de basculer de l’intelligence métier sur la gestion de contenu…

Le chapitre 5, moins utile de mon point de vue évoque la customisation de l’IHM d’Alfresco, donc utile seulement si l’on veut donner un accès à l’IHM du progiciel aux utilisateurs. J’avoue que je finis par être un peu noyé par ces fragments de code ou de XML que j’ai du mal à rattacher à quelque chose. C’était déjà un peu vrai dans les chapitres précédents, mais ça l’est plus encore ici.

Le chapitre 6 est particulièrement important, du moins à mes yeux : il évoque l’API Rest d’Alfresco. Hélas, le texte part du postulat de l’utilisation de cette API depuis des pages HTML, depuis du code JavaScript. De mon point de vue cela réduit nettement l’intérêt et la portée du chapitre.

Un large chapitre, le chapitre 7, est consacré aux « worflows avancés », donc ceux s’adossant à jBPM. Si les aspects en contact avec Alfresco présentent un peu d’intérêt (mais je cherche toujours comment lier un document à une instance de workflow, comme je le fais pour Documentum…), la description en profondeur de jBPM sort un peu du cadre de cet ouvrage à mon avis. D’ailleurs il y a des livres sur jBPM, même chez PACKT publishing !

Le chapitre 8 est assurément le plus volumineux de l’ouvrage, car ses 80 couvrent le Web Content Management. Le lien entre WCM et ECM (alors que c’est sans aucun doute l’un des intérêts d’Alfresco) ne m’apparaît pas clairement montré. Mais il faudrait que je mette mon nez de plus près dans ce chapitre pour m’en assurer.

Le dernier chapitre aborde la sécurité, aspect souvent complexe sur les systèmes d’ECM. Mais on fait bel et bien le tour de la question : authentification (essentiellement avec LDAP), SSO et permissions.

De manière générale, je dirais que l’ouvrage semble faire le tour de la question. Ou plus exactement, il aborde tous les sujets, même s’il nous laisse aller vers la documentation pour couvrir complètement en largeur tous les sujets. Si l’on avait voulu le faire, le livre aurait probablement fait 2000 pages ! Donc le parti pris était surement le bon. Il n’en reste pas moins que le traitement du sujet est assez aride, et comme je dis plus haut, un peu indigeste.

Enfin bon, le livre fait le boulot. Si vous développez avec Alfresco, ce sera sans aucun doute un plus de l’avoir près de vous.

alfresco-dev-guide

Référence complète : Alfresco Developer Guide, Customizing Alfresco with actions, web scripts, web forms, workflows and more – Jeff Potts – Packt Publishing 2008 – ISBN : 978 1 847193 11 7

Alfresco Developer Guide

http://www.goodreads.com/book/add_to_books_widget_frame/1847193110?atmb_widget%5Bbutton%5D=atmb_widget_1.png&atmb_widget%5Bhide_friends%5D=on

Note de lecture : Spring in Action 3rd édition, par Craig Walls

Note : 6 ; A la fois plus et moins complet que l’édition précédente.

Spring devient de plus en plus important … de plus en plus gros, même s’il se modularise. Je me demandais bien à quelle sauce on allait être mangé cette fois-ci ! L’édition précédente faisait 700 pages, celle-ci en fait … 380 ! En fait, non seulement cette édition se recentre sur les aspects essentiels du frameworks (certains thèmes ne sont donc plus traités), mais les aspects qui le sont toujours ont été revus et en fait la table des matière a changé de manière non anecdotique. Mon conseil : si vous avez la seconde édition, conservez-là !

Dans la première partie, les déclarations XML sont traitées plus légèrement à la faveur des annotations plus largement décrites, ainsi que du langage d’expression. De même la déclaration d’aspects est traité sur plus d’espace.

Ce qui était dans la précédente édition la seconde partie se retrouve désormais sur deux parties (la 2 et la 3). La plus importante différence réside sans doute dans le « client side Spring » qui a complètement disparu.

La première partie « Core Spring » regroupe 4 chapitre et compte 110 pages. Elle reprend les aspects qui ont fait le succès des éditions précédentes : une bonne introduction à ce qu’est Sprint (en y intégrant dès le début les annotation et les aspects) et un chapitre très solide sur le wiring qui inclut les namespaces de Spring et le langage d’expression SpEL. A cela s’ajoute un chapitre tout nouveau sur la prise en charge de l’injection de dépendances par annotations qui complète celui consacré aux aspects. Tout cela est très didactique et très bien épaulé par des exemples assez courts pour être parlants et de bons schémas.

La seconde partie « Spring Application Essentials » est longue de 140 pages en 5 chapitres. C’est le liens aux couches applicatives qui sont traitées ici. D’abord l’accès aux bases de données. Ce chapitre s’enrichit d’une partie consacrée à JPA, mais hélas les autres frameworks (à l’exception d’Hibernate) sont abandonnés ! Regrettable, spécialement pour iBatis / MyBatis. Une lacune que l’on va retrouver dans le chapitre suivant consacré aux transactions qui fait même l’impasse sur les transactions XA ! Les chapitres dédiés à Spring MVC et Spring Webflow sont repris de l’édition précédente et actualisés. Mais ne cherchez pas l’intégration avec JSP, JSF ou Struts : cela a complètement disparu. Il en va de même pour l’intégration EJB (bon, pour EJB2, j’aurais tendance à comprendre…). Enfin le chapitre consacré à la sécurité est toujours là, ni mieux ni moins bien que dans l’édition précédente.

La dernière partie est consacrée à l’intégration. Les exporters qui sont là depuis la version 1.0 peuvent passer pour de vieux trucs, mais ils sont bien pratiques et ils figurent toujours au menu de cette édition sans en réduire la voilure. Ouf ! Ne pas évoquer le support REST eut été une grosse lacune aujourd’hui : un chapitre complet lui est consacré. On retrouve aussi le support JMS, qui traite aussi de l’intégration ActiveMQ et Lingo. Le chapitre consacré à JMX est très court mais fait le boulot. Et finalement, le dernier chapitre regroupe l’intégration des trucs qui ne vont pas ailleurs. : l’externalisation de la configuration (cela aurait eu plus de sens dans la première partie), le wiring via JNDI, EJB (tiens si, finalement on en parle…), l’envoi d’emails et la planification de tâches. Sur ce dernier aspect on ne parle que du Scheduling natif Spring, mais pas de l’intégration Quartz qui est pourtant plus puissant ! Là encore, ne jetez pas votre édition précédente.

C’est vrai, Spring devient de plus en plus volumineux, mais il devient aussi modulaire car tout le monde n’a pas besoin de tout tout le temps. La ligne éditoriale du livre suit ce principe et un ouvrage de près de 700 pages qui aurait été en route pour en faire 900 se trouve réduit à en faire 380. La qualité de la rédaction est toujours là et les adaptations à Spring 3.0 sont réelles sans que cela soit pour autant des changements en profondeur à bien des égards. Le livre a été profondément restructuré au passage, et cela me paraît plus logique et mieux fait ainsi. Il faudra donc aussi compter désormais avec d’autres volumes pour compléter celui-ci : Spring batch in Action, Spring Integration in Action, etc…

Bref, ne vus dépêchez pas de jeter la seconde édition…

spring-inaction-3edt-manning

Référence complète : Spring in Action, 3rd édition – Craig Walls – Manning 2011 – ISBN : 978-1-935182-35-1

Spring in Action

http://www.goodreads.com/book/add_to_books_widget_frame/1935182358?atmb_widget%5Bbutton%5D=atmb_widget_1.png&atmb_widget%5Bhide_friends%5D=on