Waiting for the Storm…

Le Storm User Group, c’est une initiative de quelques collègues autour du « big data temps réel ». Aujourd’hui, nous parlons de Storm et quelques infrastructures qui peuvent s’y connecter. Demain, il s’agira peut-être de Spark ou d’autres…

Halte là ! Je vais peut-être un peu vite ? Et d’abord, Storm, qu’est-ce que c’est ? Voilà une question à laquelle une partie de cette première rencontre va être consacrée.

Oui, Storm, qu’est-ce que c’est ?

C’est Florian Hussonois qui va répondre à cette question. Nous pourrions résumer la chose en déclarant simplement qu’il s’agit d’un Hadoop « temps réel ». Il s’agit en quelque sorte d’un middleware permettant le traitement d’évènements en mode flux.

Un (petit) peu d’historique

Storm a été développé par Nathan Marz chez BackType en 2011. La société est rachetée ensuite par Twitter qui promeut le projet et le passe en Open-Source. La première release officielle date de 2011. En Septembre 2014, le projet devient officiellement « Apache Top Level Project » alors même qu’il n’a pas encore atteint la release 1.0 !

Ecrit principalement en Clojure et en Java, ce « processeur d’évènements » est conçu pour traiter un flux de très nombreux évènements (des tuples dans la terminologie Storm), à savoir 1 millions de tuples par seconde et par noeud (1 seul coeur processeur), avec tolérance aux fautes, gestion de la scalabilité et garantie de traitement !

image

Lire la suite

Note de lecture : Activity in Action, par Tijs Rademakers

Note : 7 ; Un bon ouvrage au standard « in action » pour accompagner une immersion dans Activity, malgré quelques frustrations.

Activity, c’est le « spin off » de JBPM par ses créateurs. Mais, ainsi qu’il est expliqué en introduction, ce n’est pas un fork mais une réécriture complète, avec les choix de conception que l’équipe aurait voulu prendre à l’époque !

Mais revenons au livre. L’auteur est un des comiters principaux du projet, ce n’est pas non plus un auteur débutant. Tout ce présente donc sous les meilleurs auspices pour commencer. La prose est conséquente : 400 pages sur 15 chapitres distribués en 4 parties inégales. Il est temps de rentrer plus en profondeur.

Les quelques 80 pages de la première partie regroupent 4 chapitres et sont une introduction à BPMN 2.0 et Activity. On commence par une présentation générale d’activity, de son architecture et l’incontournable « hello world » précédé d’une installation basique. C’est réussi. Le chapitre suivant a pour but de nous présenter BPMN 2.0. C’est fait avec pédagogie et bien illustré, mais aussi assez superficiel et on sort de là un peu frustré. La présentation de l’outillage Activity est un peu touffue, probablement parce que cet environnement l’est aussi un peu : il manque d’homogénéité et est un peu de pièces rapportées. Espérons que cela s’améliore à l’avenir.

Lire la suite

Note de lecture : Swing (Les cahiers du programmeur), par Emmanuel Puybaret

Note : 4 ; Pédagogique mais trop pesant.

Cette série Eyrolles est sensée être dédiée à des ouvrages permettant de monter en compétence sur des sujets. Dans les faits, on en prend pour 500 pages. Peut-être l’auteur a-t-il été trop gourmand en essayant d’avaler de nombreux sujets ? On va voir ça !

De prime abord, le texte est découpé en 12 chapitres. Mathématiquement, cela va donner de gros chapitres, donc un découpage « à la française ». Le concept global du livre est de mener une étude de cas en mode projet, avec des itérations. Le tout à la façon extrême programming. Cela fait donc au moins 2 sujets à aborder. 3 si l’on compte le détour par SWT. Je ne compte pas toute la partie outil également aborder. Il est temps de commencer.

Le premier chapitre présente l’étude de cas : il s’agit d’un système de CAO. On évoque aussi l’approche XP (mal) qui sera utilisée et un bref exposé des cas d’utilisation (malgré que l’on soit avec XP où les user stories sont préférées). Bonne nouvelle, le tout est bouclé en 9 pages.

Lire la suite

Note de lecture : Practical Apache Struts2, par Ian Roughley

Note : 4 ; Raisonnable, mais c’est bien tout.

Ce livre cible, sans surprise, le développeur Java d désirant s’initier à Struts 2. Il ne nécessite pas vraiment de connaissances préalable du développement d’application Web en java, car on est en gros pris en main dès les tâches les plus simples. Voyons ce que le livre à a nous proposer. Tout d’abord, il est de taille moyenne, avec 326 pages découpées en 10 chapitres, un départ raisonnable, avec un découpage raisonnable.

Le premier chapitre est clairement superflu, il traite de généralités sur le Web 2.0, les principes comme « convention over configuration », l’injection de dépendances, etc. Passons vite !

Le second chapitre est destiné à nous mettre le pied à l’étrier. La moitié du chapitre est consacré … à Maven 2, tandis que le reste évoque les différents fichiers de configuration nécessaires pour commencer le projet. Mais c’est un peu confus.

Lire la suite

Note de lecture : Lucene in Action, par Otis Gospodnetic & Erik Hatcher

Note : 6 ; Fait le boulot comme attendu, contrat rempli.

Lucene est le grand classique, pratiquement l’unique moteur d’indexation et de recherche full texte en open source, du moins dans le monde Java. Il était normal qu’un volume de la sérié « in action » de chez Manning lui fut consacré. Voyons en pratique ce qu’il en ressort.

Tout d’abord le texte compte pratiquement 400 pages découpées en 10 chapitres. Cela me semble au premier abord plutôt volumineux et constitue des chapitres qui seront en moyenne plus long que ce que j’apprécie en général. Au moins, on va pouvoir les passer en revue.

Le premier chapitre comme il est coutumier dans cette série présente la problématique de la recherche plein texte, la réponse de Lucene et ses alternatives. Le tout est bouclé en 27 pages et c’est une entrée en matières plutôt sympathique.

Lire la suite

Note de lecture : Swing, la synthèse par Valérie Berthié & Jean-Baptiste Briaud

Note : 6 ; Une approche simple et claire pour débuter avec Swing.

Ecrire la note de lecture d’un ouvrage 11 ans après sa parution est un exercice difficile, peut-être même un peu malhonnête. Je vais toutefois tenter l’exercice.

Ce livre est publié dans une collection qui n’a jamais fourni des morceaux d’anthologie de la littérature informatique française. Tant pis. Ici nous avons 325 pages sur 7 chapitres et 2 annexes, avec 280 consacrées au corps du livre, donc des chapitres assez importants.

Le premier chapitre est consacré aux principes fondamentaux de Swing et pèse tout de même 76 pages ! C’est en fait une bonne surprise : après avoir expliqué la facette historique menant de AWT à Swing, on aborde les différents composants de manière très pédagogique, avec des morceaux de code simples et même des diagrammes UML !

Lire la suite

Note de lecture : The Definitive Guide to SWT and JFace, par Rob Warner & Robert Harris

Note : 3 ; Quand même un peu mieux que la Javadoc. Mais pas tellement plus…

Voilà un pavé à 800 pages qui fleure bon le livre de commande. Pourtant le périmètre de l’ouvrage est volontairement limité aux frameworks de base d’Eclipse : SWT et JFace. On ne parle pas de développer des plugins et encore moins une application RCP. Aucunement question de s’appuyer sur les points d’extension du Workbench ni autre plaisanterie du même acabit… Voyons comment on en arrive là.

Le livre est découpé en deux parties (trois en fait) de taille inégales :
La première partie « Getting Ready » couvre le setup de votre projet applicatif au bout de 2 chapitres. Cela dit, on ne s’étale pas et c’est bouclé en 25 pages en tout.

Dès la seconde partie, on passe aux choses sérieuses avec SWT. En fait, c’est le gros du bouquin : 10 chapitre sur un peu plus de 500 pages. Tout est abordé de façon logique et je dirais même classique. On se rend vite compte qu’il y a principalement 3 choses que noircissent la papier : de grosses copies d’écran, des listing de codes un peu trop extensifs et une reformulation de la javadoc ! C’est un peu dommage, car les explications qu’il y a entre sont plutôt claires.

Lire la suite

Carnet de route : Agile France 2014 (3/4)

Suite du compte rendu d’Agile France, après la journée de Jeudi disponible ici et ici.

De bon matin…

De bon matin, ce n’est pas moi. J’arrive à temps pour le café et discuter un peu avec les autres. Mais quand j’arrive, un petit groupe se livre déjà à des exercices de Qi Gong.

image

Je retrouve les autres dans la salle commune. On discute, Alex Tweet. Business as usual…

image

Assez plaisanté ! La journée va commencer, place à la keynote !

Coaching Teams Through Change

Rachel Davies nous avait déjà gratifié d’une session il y a peu lors du ScrumDay. Fort heureusement, ce ne fut pas la même. J’ai d’ailleurs préféré cette keynote.

Rachel travail pour Unruly, une société spécialisée dans le « social media advertising ». C’est un domaine où les spécifications changent véritablement tous les jours. L’objectif est ainsi de déployer effectivement tous les jours !

image

Le début d’un changement

Au début les départements produit et développement étaient deux directions séparées. C’est le départ du directeur produit qui a permit d’enclencher un changement de structure.

Ce changement, c’est l’organisation en équipes de 3 à 5 personnes pour développer le produit. Et pas seulement développer : ces équipes prennent en charge la totalité des activités entourant le développement : l’écriture des user stories, les tests, etc. Ce sont eux qui vont solliciter les différents interlocuteurs (produit, marketing, commercial) quand cela s’avère nécessaire. Pas de product Owner qui est la seule voix du client, l’équipe va parler directement à tous les interlocuteurs ! Parmi ces interlocuteurs, nombre d’entre-eux ne sont accéssibles qu’à distance : l’équipe utilise Google Hangout pour communiquer. La conversation s’engage avec les interlocuteurs pour trouver la plus petite chose utile à construire, ce qui nécessite de prendre en compte tous les point de vue.

Lone rangers et development owners

Tout le développement est réalisé en binômes. Mais les équipes sont constituées d’un nombre impair de personnes ! En fait, par rotation, l’une d’entre-elle est le « lone ranger ». Elles s’occupe de diverse choses dans l’équipe, mais pas du code de production. C’est aussi à cette personne que les intervenants extérieurs à l’équipe s’adressent, afin de ne pas perturber les binômes en train de travailler.

L’équipe a aussi développé l’idée de « owner of the development area » : un développeur plus expert au sein d’un sous-ensemble fonctionnel. C’est lui qui élabore une proposition par rapport à un besoin exprimé.
Les propositions sont traitées en planning meeting. Celui-ci n’est pas un planning meeting classique XP : seule la priorisation des propositions y est traitée, il n’y a pas d’engagement de charge. Ces planning sont donc très courts : ils n’excèdent pas 30 minutes !

Gold card

A l’image de ce que Kniberg décrit pour Spotify, Unruly fait des efforts particuliers par rapport au bien être des équipes. Outre divers évènements sociaux, la société applique la politique du 20% free time inspirée de Google (bien qu’elle disparaisse progressivement de Google, justement). Ici elle s’appelle « gold card day » et sert de sources d’inspiration pour creuser de nouvelles idées.

Ce que j’en ai pensé

Sans être exceptionnelle, cette présentation nous offre l’opportunité d’avoir un retour sur une organisation d’équipe différente de ce que l’on voit aujourd’hui :

  • Les itérations s’estompent au profit de la déliverie continue, mais des points de priorités réguliers contrebalancent l’effet « court terme » du flux.
  • Pas de « product owner » ici : c’est l’équipe qui fait le lien avec les divers interlocuteurs. Le périmètre de responsabilité de l’équipe s’accroit, mais on évite ainsi l’effet paravent du PO !

Je change mon programme à la dernière minute. Je choisis en 15 secondes d’aller à une présentation résolument technique. Grand bien m’en a pris !

Le mythe du framework agile

Jean-Baptiste Dusseault vient mettre fin à quelques idées reçues concernant ces frameworks qui doivent nous agilifier / faciliter la vie. Au départ de ce « ras le bol » un titre de livre : Agile Web Developement with Rails ! Même co-écrit par l’un des signataires du manifeste agile (et par l’auteur de Rails), ll y a un problème ici. Probablement plusieurs même. Le premier est la taille du livre : près de 500 pages !

Le framework maison

Mais commençons par le commencement. Et le commencement, puisque nous parlons ici de frameworks « full stack », c’est le fameux framework d’entreprise. Un bon point : nous n’avons que trop rencontré ces pantalonnades. Lâchons-nous, ça va faire du bien !

image

Le but de ces frameworks, c’est d’avoir le « meilleur du moment », tout bien branché ensemble. On met les pantoufles, on débranche le cerveau, et l’on peut tranquillement produire plein d’applications en un tournemain !
Sauf que ça ne se passe pas comme ça. Ces braves frameworks transforment notre vie en enfer !

Citons dans le désordre :

  • Prévus pour être simples, ils s’avèrent en fait ultra-compliqués ! Peut-être leur conception et leur réalisation par des « équipes transverses » explique-t-elle quelque chose ?
  • Ils sont difficiles à tester et très bugués. Là encore, leur réalisation détachée des projets n’a pas contribué à leur testabilité. Utilisés uniquement par quelques projets de l’entreprise (au mieux) le « durcissement » du framework n’a jamais vraiment eu lieu…
  • pas de support : souvent les équipes ayant réalisé le framework sont parties depuis longtemps…

Qu’en est-il des « full stack » reconnus ?

Ici on parle des rails, Play, etc… Ils nous font la même promesse d’accélérer les développement du sol au plafond. En vérité, ils prennent des décisions d’architecture pour nous ! Jean-Baptiste va plus loin : en déléguant les choix d’architecture au framework, on laisse celui-ci nous utiliser !

Nous n’utilisons pas les frameworks “full stack” : ce sont eux qui nous utilisent.

Ce biais a des conséquences, on va le voir bientôt.

D’où vient leur succès ? Ils permettent de faire très vite 80% de l’application. Mais on galère sur les 20% restant ! Généralement, la réalisation en suivant le tutorial va vraiment vite.

Hélas, ils encouragent certains comportement. La partie « basse » entité et persistance est plus ou moins câblée. Il n’est pas possible d’y intervenir facilement. Et les entités ressemblent beaucoup aux tables de la base de données (ça rappelle les outils RAD client/serveur). On hérite donc d’un couplage vertical sur la base de données.

En fait, le seul endroit où l’on peut réellement raccrocher du code, c’est le contrôleur ! On l’accroche comme on peut. Et si des comportements communs apparaissent dans le code tartiné sur deux contrôleurs, le seul moyen efficace de le partager est le copié-coller ! Beurk !

Bref nous obtenons :

  • Des architectures monolithiques.
  • Des frameworks optimisés pour l’écriture de code … mais pas pour sa maintenance !
  • Des couplages forts avec la représentation et la base de données.
  • De grosses difficultés pour sortir des clous via des « plugins » et autres joyeusetés du genre qui ont de grosses courbes d’apprentissage.
  • Une testabilité rarement au rendez-vous.

Mais alors, c’est quoi un framework agile ?

Plutôt que de framework agile, parlons d’architecture agile, et des propriétés qu’elle devrait avoir.

  • Elle doit nous permettre de retarder les décisions
  • Elle minimise les couplages.
  • Elle est facile à changer.Elle est testable (via TDD et ATDD)

Une proposition et des inspirations

Pour Jean-Baptiste Dusseault, une telle architecture c’est :

  • Au centre un véritable modèle du domaine d’inspiration DDD, comme les proposent l’architecture hexagonale d’Alistair Cockburn ou la Clean Architecture de Bob Martin. Ce modèle ne dépend de rien et ne connait pas la persistence ni aucun système tiers, mais expose une API métier.
  • Une couche « commandes » implémentant les cas d’utilisation du modèle du domaine. Des idées que l’on retrouve dans la Lean Architecture de Jim Coplien.
  • Au-dessus un couche d’accès type CQRS dialoguant en asynchrone avec la couche commande et routant différemment les évènements commande (vers la couche commande) des requêtes qui sont adressées directement à la couche d’accès à la base de données.

Bien sûr le postulat de cette architecture, c’est que le métier est au centre des préoccupations. On n’évoque pas non plus l’architecture en micro-services qui me semble pourtant adaptée mais peut-être pas facile à concilier avec une architecture hexagonale…

La présentation de Jean-Baptiste est évidemment en HTML5 et elle est accessible en ligne ici.

Ce que j’en ai pensé

Cette session est une agréable surprise. Si le bashing des « frameworks agile » ne fait que confirmer ce que je pensais, les idées développées sur l’architecture agile me font beaucoup plus réfléchir, pour ne pas dire qu’elles soulèvent mon enthousiasme !

Comment j’ai développé mon muscle de l’amélioration continue en faisant mes courses

Ayant décidé de bouleverser mon programme, je n’ai de nouveau que 2 minutes pour changer mon programme. De nouveau, c’est une bonne pioche avec la session de Cyrille Deruelle !

Tout d’abord : pourquoi faire des exercices d’amélioration ? Pour que cela devienne une habitude, rendre cela naturel. Et Cyrille s’est livré à cet exercice en faisant ses courses du Samedi : c’est drôle et instructif !

image

Bien sûr tout ça n’a pas très bien marché du premier coup (d’où la nécessité de s’améliorer). Au départ, Cyrille a essayé d’impliquer son épouse (Product Owner des courses) dans la résolution des problèmes qu’il rencontrait. C’est une première leçon :

Les gens se foutent de la manière dont nous résolvons les problèmes.

Au hasard des améliorations, on va trouver :

  • « t’as rien oublié » … où comment suivre que l’on a tout acheté ? A l’aide d’une liste de courses et d’un gros feutre noir (le stylo fin ne convient pas).
  • Grouper les courses par catégorie : afin d’optimiser le parcours dans le magasin.
  • Prendre une photo des rayonnages pour les produits compliqués … afin de permettre à son épouse d’indiquer le produit souhaité. Le choix de la lessive a été vaincu ainsi !
  • Gérer les dates limites de consommation en les pré-calculant par rapport aux courses suivantes : afin d’éviter les erreurs pendant les courses.
  • Sortir des éléments du process : Les packs d’eau, c’est ingérable ! Alors on ne les sort du processus standard et on fait de temps en temps des ravitaillements en eau (en grande quantité) !

Les conclusions de Cyrille

  • Mes problèmes sont mes problèmes : Il n’est pas possible de s’en décharger sur d’autres personnes.
  • Il n’y a pas de choses simples : l’amélioration continue est une quête !
  • Les actions d’amélioration sont fragiles et difficiles ; c’est une discipline de tous les jours.
  • Mesurer l’impact d’un problème, c’est déjà 50% de la résolution

Enfin parfois, les améliorations ne sont pas possible, c’est le CCMCCC : C’est Con Mais C’est Comme Ca !

Grâce aux actions d’amélioration, Cyrille n’a pas seulement rendu son processus de meilleure qualité et plus efficace, il l’a aussi rendu fun !

Ce que j’en ai pensé

Une très bonne session : amusante et instructive. Bravo !

Refactorer du Legacy

Pas besoin de changer de salle pour la session de Johan Martisson. J’ai rencontré Johan lors du ScrumDay 2014. Ou plus exactement, Jean-Laurent de Morlhon me l’avait présenté. D’ailleurs Jean-Laurent était là à cette session résolument intimiste orientée craftmanship, avec des vrais morceaux de « live coding ».

image

Johan nous parle et nous démontre son approche de la reprise en main du code legacy, à l’aide de la librairie ApprovalTests. Pour résumer l’approche en quelques points :

  • On construit un harnais de tests résolument temporaires de manière rustique mais rapide.
  • On construit de manière assez brutale des combinaisons de conditions d’entrée pour couvrir une combinatoire de cas couvrant l’espace du problème.
  • On exécute une première fois les tests pour constituer la référence, sans se soucier de la justesse des résultats : il s’agit juste du comportement courant de la librairie.
  • On vérifie la stabilité du comportement du soft en comparant les résultats par rapport à la référence.
  • Au fur et à mesure du refactoring, on construit des tests unitaires définitifs. On peut envisager de se débarrasser définitivement des tests temporaires, de manière progressive.
image

Ce que j’en ai pensé

Au début de la présentation, je mes suis demandé où Johan essayait de nous emmener et j’ai pris conscience avec un peu de retard de l’efficacité et de la rapidité avec laquelle Johan mettait en place son harnais de tests ! Je dois dire que c’est très convainquant. Une petite vidéo pour vous en convaincre.

J’avais prévu d’être un peu plus long sur le descriptif de ce que Johan nous a montré avec l’outil, mais il le fait mieux que moi sur son blog. Je vous invite donc à le lire.

Pause déjeuner

Par une curieuse coïncidence, c’est de nouveau avec Jean-Luc Lambert que j’ai échangé lors de cette pause. Et nous avons parlé éducation et « génération Y ». Jean-Luc évoque avec enthousiasme le challenge que représente l’enseignement avec cette population.

  • Elle ne prend pas pour acquis les propos de l’enseignant. Le cours magistral a une vertu pour le moins limitée.
  • Ils sont « multi-tâches ». C’est assez déroutant, mais il faut faire avec !
  • Ils sont réceptifs aux jeux et aux exercices libres. Les techniques type « from the back of the room » leur sont bien adapté.
  • Ils ont beaucoup d’autonomie et sont entreprenant.
  • Ils ne se sentent pas beaucoup d’attache ni de fidélité pour la société pour laquelle ils travaillent.

Voilà pour cette dernière matinée. Je vous retrouve très bientôt pour la dernière partie de cet Agile France 2014 !

Note de lecture : Business Process management with JBoss jBPM, par Matt Cumberlidge

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.

image

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

Business Process Management with Jboss Jbpm

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

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