Note de lecture : Workflow Management, par Wil Van der Aalst & Kees Van Hee

Note : 6 ; Une référence, certes, mais aussi un texte aride !

Soyons clair dès le début : ce livre fait autorité sur les fondamentaux des Workflow et est écrit par la plus grande autorité reconnue en le domaine. D’ailleurs le livre débute ses deux premiers chapitres en posant les bases des concepts fondamentaux des Workflows : tâches, work items et activités, mais aussi les réseaux de Pétri, bien entendu.

Le chapitre 3 s’attaque à la gestion des workflows : l’alignement des ressources et de l’organisation sur les workflows, ainsi que l’adéquation de ceux-ci par rapport aux objectifs et aux coûts. Cette étude est complétée par le chapitre 4 qui couvre l’analyse de pertinence et de performance des workflows.

Si ces 4 premiers chapitres couvrent la théorie, la pratique arrive avec le chapitre 5 qui présente les architectures de systèmes de Workflow, le chapitre 6 qui lui fait suite s’attaque à l’aspect méthode. Une partie qui aurait aussi bien pu être oubliée car elle apporte assez peu ici. L’étude de cas qui termine l’ouvrage est une bonne idée, mais elle est peu passionnante aussi bien par le fond que par la forme.

On notera enfin les 2 annexes : la première destinée aux fondamentaux mathématiques ravira les plus courageux (je n’en fais visiblement pas partie) et la seconde assez courte dédiée à la représentation des workflows avec UML.

Lire la suite

Note de lecture : Architecting Enterprise Solutions, par Paul Dyson & Andy Longshaw

Note: 7 ; Un excellent “pattern language” d’approche très Alexandrienne. Dommage que l’aspect solution me laisse un peu sur ma faim.

Le titre de l’ouvrage est assez évocateur à cet égard: Il s’agit là de décrire le style architectural des systèmes d’information Internet à l’aide d’un pattern language, à la Christopher Alexander. Digne représentant de la « software design patterns series », cet ouvrage expose sur 290 pages découpées en 12 chapitres formant 3 parties des architectures de déploiement dédiées aux applications Internet. Bien sûr, vous allez me dire que le texte va accuser son âge, surtout dans le domaine où les plus grands progrès ont été faits au cours des 10 dernières années ! Si ce point est indéniable, il n’est pas aussi marqué que l’on pourrait le craindre car il se focalise bien plus sur les principes d’architecture que sur les solutions techniques !

Je passe sur le premier chapitre qui ne nous apprend rien pour aborder la première partie « Architecture, Patterns and Internet Technology » qui comprend 4 chapitres sur 60 pages. Le premier d’entre-eux (donc le second chapitre) « system architecture » mérite que l’on ne passe pas trop vite dessus. Ses 15 pages sont consacrées aux propriétés non-fonctionnelles des architectures. Intéressant. Le point sur les technologies de l’Internet que nous propose le chapitre 3 sur 17 pages est un peu superficiel, mais pas aussi démodé que l’on pourrait le croire. Mais il apporte peu. Le chapitre 4 est en quelque sorte la table des matières patterns du livre. C’est un incontournable pour ce genre d’ouvrage. Pour clore cette première partie, les auteurs présentent l’étude de cas fictive sur laquelle ils ont choisi de s’appuyer. On y fait le tour des propriétés non-fonctionnelles que l’on avait énumérées au chapitre 2. C’est bien fait.

Avec 167 pages, la seconde partie est le gros de la troupe du bouquin, et de loin ! Il faut dire que cette partie qui ne compte pourtant que 4 chapitres s’intitule « The Patterns ». Et l’on commence fort logiquement au chapitre 6 par un chapitre « fundamental patterns » de 18 pages. Il présente deux patterns, le très classique « application server architecture » encore largement majoritaire aujourd’hui et un moins convainquant « péripheral specialist elements » dont la symétrie est questionnable du fait de la BDD unique… Le chapitre 7 nous offre un gros morceau avec les « system performance patterns » qui couvrent 45 pages. Les patterns architecturaux de ce chapitre sont particulièrement intéressants et bien décrits dans leur essence (load balancing, redondance, failover, appliance, replication, resource pooling, cache, offlining), il ne manque guère que le sharding des bases NoSQL ! Les diverses variantes de ces stratégies sont abordées ainsi que des considérations d’équilibrage de charge CPU, etc… Bref un chapitre riche qui justifierai le livre à lui tout seul !

Place aux « system control patterns » au chapitre 8, qui nous occupe sur 60 pages. Ce chapitre nous expose nombre de patterns de monitoring et de contrôle d’application en production. Ces patterns ne sont pas, disons « mortels », mais ils ont le mérite d’être là ainsi que les discussions qui vont avec. Plus intéressant, ce chapitre couvre aussi un volet sécurité avec les DMZ, l’encryptions et le secure channel (SSH). Le chapitre 9 qui clos cette seconde partie est probablement le plus décevant. Couvrant le « system evolution patterns », les patterns présentés restent de haut niveau. Petite exception pour le « swappable stagging environment » qui reste la perle de ce chapitre.

La dernière partie de l’ouvrage est consacré aux applications de ce que nous avons vu. 60 pages sont dédiées à cette partie qui regroupe 3 chapitre. Le chapitre 10 revisite ainsi notre étude de cas. C’est l’occasion de mixer plusieurs patterns pour endosser la performance, le monitoring et le déploiement. C’est un peu rapide mais donne une image à grande échelle de l’usage combiné des patterns. Le chapitre 11, « applying the patterns » couvre une vingtaine de pages. Son objectif est de donner une logique à l’application des patterns de la seconde partie, ce que je ne trouve pas convainquant. L’ouvrage se conclut par un mini chapitre « moving on » dont le but est de donner une perspective d’avenir. Bien sûr, c’est aussi celui qui accuse le plus son âge !

N’en doutez pas, l’objectif du livre est parfaitement réussi. Car nous avons vraiment là un bel exemple de pattern langage, dont chaque pattern est l’essence d’un point particulier de l’architecture, l’ensemble formant un tout cohérent. Cet ouvrage est convainquant sur la description efficace et agréable d’une architecture avec un pattern language. Une parfaite réussite à cet égard.

Ce qui modère un peu ma note, c’est que le volet technique, plus « design » soit un peu frustrant, car le propos reste assez haut niveau, même si le style est agréable et efficace. Quoi qu’il en soit, si vous décidez d’acquérir la connaissance de ce qu’est une architecture Internet, voilà le livre que vous cherchez. Toutefois, si vous êtes un pur techos, vous risquez d’être déçus. Moi je ne l’ai pas été !

image

Référence complète : Architecting Enterprise Solutions: Patterns for high-capability Internet-based systems – Paul Dyson & Andy Longshaw – John Wiley & sons / Software Design Patterns series 2004 – ISBN: 0-470-85612-2

Architecting Enterprise Solutions: Patterns for High-Capability Internet-Based Systems


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

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

Les concepts clés

Pour bien comprendre Storm, il faut en saisir les concepts de base.

  • Le Tuple : Nous en avons parlé, il s’agit de l’unité d’information à traiter. C’est l’évènement.
  • Le Stream : c’est une séquence illimitée de tuples.
  • Le Spout : C’est un connecteur producteur de tuples. En pratiques, ce sont des composants source de données. Il en existe de nombreux types (dans le projet officiel et en dehors) pour se connecter à différentes infrastructures.
  • Le Bolt : Il s’agit du composant de traitement élémentaire. Il consomme bien entendu des tupples et peut en produire (mais pas obligatoirement). Il peut aussi se connecter à une base de données, par exemple.
  • La Topologie : il s’agit de la structure de déploiement de votre configuration Storm. Dans la pratique, il s’agit d’un graphe acyclique (DAG).
  • Groupements de streams : Si les bolts peuvent « splitter » des streams (façon CBR) ou les multicaster, ils peuvent aussi les regrouper. Il existe 7 types de regroupements.

Le parallélisme est intrinsèque à Storm. Chaque Bolt peut être instancié plusieurs fois (on les appellent « task »). Chaque tâche est prise en charge par un Executor qui correspond dans la pratique à un thread. Storm prend en charge la répartition des Executors sur des Workers (qui correspondent à une JVM). Chaque Worker devant être géré par un Supervisor. Ce dernier point est important, car les Workers peuvent tomber ! Un petit dessin vaut parfois mieux qu’un long discours…

image

Pour gérer et faire tourner l’ensemble, Storm met à notre disposition 3 briques importantes :

  • Le Supervisor : nous en avons parlé, il gère un Worker, le relançant si nécessaire, et permet de surveiller sa charge.
  • Zookeeper, qui a en charge de gérer une topologie
  • Nimbus, qui gère les masters des topologies. Il doit lui-même tourner sous supervision.

Traiter en toute quiétude

Les graphes de traitement de Storm peuvent devenir des arbres très complexes ! Toutefois Storm s’y entend pour reconnaitre si un Tuple entrant a été traité sur la totalité de son arbre. Tout d’abord chaque Tuple a son id (sur 64 bits). Nathan Marz a développé un algorithme très complexe, basé sur le XOR pour identifier si un arbre a été complètement traité. Bien entendu, chaque Bolt opère son acquittement local, c’est le « Ack ».

image

Florian passe rapidement sur Trident qui permet d’assurer une sémantique « exactement 1 » aux traitements. J’avoue que le sujet est passé trop rapidement pour moi. Peut-être une occasion de creuser le sujet ultérieurement ? Il en va de même pour la fonctionnalité DRPC.

Si vous avez raté le live et que ma prose vous laisse de marbre, voici l’enregistrement de l’intervention de Florian lui-même !

Storm et Redis chez Twitter Foot

Ce retour nous était proposé par Benjamin Houdu. Cette présentation m’intéressait d’autant plus que j’ai participé au début de ce projet. Et je dois dire que ce dont Benjamin nous a gratifié est probablement le meilleur retour d’expérience auquel j’ai pu assister !

Le projet

Comme son nom l’indique, Twitter Foot traite des flux Twitter, suivant des comptes identifiés par l’AFP (7000 comptes sur 5 ligues), pour fabriquer des timelines spécialisées et toute sortes de statistiques, comme des tendances, la détection de viralité ou de popularité.

Techniquement, les particularités de cette mise en oeuvre de Storm repose d’une part sur la connexion Twitter via la streaming API en utilisant le connecteur Hosebird, et d’autre part sur la mise en oeuvre conjointe de Redis, un base NoSQL de type clé-valeur fonctionnant en mémoire. Redis est d’ailleurs très exploité ici, car on en fait un triple usage :

  • Pour bufferiser le flux Twitter et alimenter le stream Storm. Incidemment, cela rend l’architecture plus testable, car les tests peuvent être faits simplement en peuplant Redis, sans connexion à Twitter, avec en prime la maitrise sur les données injectées !
  • Pour sauvegarder les données de référence : aussi bien la topologie que l’on va injecter dans Zookeeper que les comptes sur lesquels on a des abonnements.
  • En frontal, pour exposer les timelines résultantes et les données statistiques !

En pratique, la topologie est constituée de 3 machines abritant chacun un worker, auxquelles il faut rajouter le serveur frontal abritant le serveur Rest qui expose les services ainsi construits.

image

Et bien sûr, il y a le serveur hébergeant Redis !

Justement Redis, qu’est-ce que c’est ?

Nous l’avons dit, il s’agit d’une base NoSQL de type clé-valeur fonctionnant en mémoire. On devinera que ces choix l’orientent vers la performance, ce qui explique les autres choix techniques : elle est écrite en C et est … monothreadée ! Ce dernier choix peut paraitre curieux, mais de fait, il évite de devoir gérer les problèmes de contention. Il se justifie aussi par les excellentes performances de la base dont les requêtes sont non seulement traitées rapidement, mais aussi peu sensibles à l’augmentation de volume : la plupart des fonctions proposées ont des indices de performance en O (Log (n)) !

Parmi les fonctionnalités intéressantes de cette base, on pourra noter dans le désordre :

  • La présence d’une API de type « publish / subscribe » bien pratique entre autre pour le débug !
  • La présence de connecteurs pour un grand nombre de langages.
  • La mise à disposition de structures intelligentes : sorted sets, Z sets, etc. qui permettent non seulement de retrouver un élément, mais de sélectionner un « range » d’éléments. Une fonctionnalité qui s’avérera particulièrement précieuse dans le cas d’utilisation de Twitter Foot !
  • La présence d’un langage de script basé sur Lua qui permet d’écrire l’équivalent de procédures stockées dont l’atomicité d’opération est garantie par l’architecture monothreadée de la base !
  • L’accès en mode interactif en ligne de commande, via redis-cli pour travailler sur la base en mode non programmatique.

Storm, au coeur de Twitter Foot !

Nous n’allons pas revenir sur le descriptif général de Storm que Florian a fort bien abordé. Benjamin attire toutefois notre attention sur les changements importants survenus entre les versions 0.8.x et 0.9.x, la première dépendait fortement de Zero MQ, ce qui n’est plus le cas des versions ultérieures. Il met aussi l’accent sur l’intérêt de Storm UI d’un point de vue opérationnel, surtout pour savoir quel tâche tourne sur quel worker ! En effet, il faudra abandonner l’idée que l’on traite l’affinité des tâches sur les workers / machines, c’est Storm qui gère cela.

En fait, l’un des enseignements que tire Twitter Foot, c’est que l’administration est un volet du projet aussi important que le développement, et il faut y faire face le plus tôt possible dans le projet ! Autre difficulté, la configuration dont les changements imposent des redémarrages de topologies. C’était une contrainte trop forte pour Twitter Foot, aussi l’équipe a-t-elle traité la configuration comme un Stream traversant les Bolts !

Des fenêtres bien glissantes…

Un concept est rapidement apparu sur Twitter Foot : la nécessité de faire des statistiques sur une durée fixe, mais relative au temps présent. Ce que l’on a appelé des « fenêtres glissantes », c’est à dire entre T0 et T-n minutes (ou heures, ou jours), avec un échantillonnage représentant la résolution de ces statistiques en x minutes ! Vous pouvez aussi dire « sliding windows » pour briller dans les salons, mais ne cherchez pas sur Google, c’est un concept maison !

image

Plusieurs essais d’implémentations en ont été faites. Benjamin nous parle de deux d’entre-elles.

Tout d’abord, on peut s’appuyer sur un concept Storm : les Rolling Buffers. Ils sont plutôt complexes à mettre en oeuvre, mais ils présentent entre autre l’avantage de gérer automatiquement l’éviction des échantillons quittant la fenêtre glissante !

Autre possibilité : s’appuyer sur les ZSets de Redis. Redis permet même d’opérer des aggrégations par x minutes et donc de gérer pratiquement automatiquement l’échantillonnage ! Par contre l’éviction des vieux échantillons doit se faire programmatiquement.

Quelques mots sur la testabilité

J’ai été agréablement surpris de voir Benjamin aborder ce point finalement assez déconnecté des problématiques purement techniques de Storm (bien qu’il y ait bien sûr des corolaires techniques). Le projet a en effet mis en oeuvre tôt dans ses premières phases une approche ATDD impliquant le client et s’appuyant sur le paradigme « Given When Then » outillé avec Cucumber JVM. Cette approche a réellement permit une convergence et appréhension fine des fonctionnements attendus.

D’un point de vue technique, il a été possible de se servir de l’alimentation par Redis pour effectuer ces tests déconnecté de Twitter en injectant dans Redis des Tweets « forgés ». Autre point délicat, la nécessité de ne pas redémarrer la topologie entre chaque tests afin de garder des temps d’exécution raisonnables.

Et le monitoring ?

Nous l’avons dit, avec Storm on fait beaucoup d’administration, ce qui a quelques implications.

D’abord, plus encore qu’ailleurs, les opérations réalisées fréquemment doivent être en « push button ». Jenkins est d’une aide appréciable à ce niveau.

Le Storm Supervisor : il est indispensable, et il en faut un par machine.

L’équipe a aussi utilisé avec bénéfice Monit, un watchdog qui s’est avéré d’une grande utilité. Notre orateur est dithyrambique à ce sujet !

Du côté de Redis, c’est redis-rdb-tools qui s’est avéré indispensable. Le gros avantage est le parse des logs offline, donc sans impacter la machine de production. Dans la pratique, beaucoup d’investigations peuvent être menées à bien en différé.

Si on a réellement besoin de connaitre l’état de santé de l’instance en live, il y a … Redis Live !

Quelques mots sur le débug et les best practices

L’investigation de problèmes sur une architecture Storm peut très facilement se transformer en chemin de croix ! Il faut anticiper cela au niveau de la conception et penser les Bolts avec des responsabilités bien séparées (principe SRP de Bob Martin). En fait, Benjamin nous suggère de séparer les Bolts de contrôle des Bolts d’action !

Même chose sur Redis : bien séparer les actions d’insertion des actions de nettoyage.

Enfin, même les topologies peuvent être décomposées, une leçon qui est arrivée hélas bien tardivement sur Twitter Foot ! De plus petites topologies se testent plus facilement et sont plus robustes. Mais attention, ne pensez pas mutualiser les workers : un worker ne peut appartenir qu’à une topologie.

Autre problème bien connu, celui de l’auditabilité : comment retrouver l’origine du problème ? L’équipe Twitter Foot nous propose la technique du « Carbon dating » : injecter dans les Tuples des informations de trace des Bolts traversés !

Du côté Redis enfin, si l’aspect « sans schéma » est apparemment une liberté bienvenue, on touche vite les limites de ce manque de typage. Ici, c’est l’emploi de json-schema que vient nous recommander l’équipe.

Si vous préféreez la présentation de benjamin in extenso, ne pleurez plus, la voici !

Ce que j’en ai pensé

Je l’ai dit au début : l’orateur nous a gratifié là d’un retour d’expérience d’un niveau de qualité que j’ai rarement (jamais ?) vu !

La mise en oeuvre d’un projet avec Storm est réellement quelque chose de complexe. On perçoit cette impression rapidement, mais les dimensions de cette complexité apparaissent clairement dans cette présentation !

Mais on va plus loin ici : les voies à explorer, les points d’attention dans le projet, les outils indispensables et leur utilité, tout nous est clairement exposé. Un grand bravo !

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.

Avec 35 pages, le chapitre 4 est le gros morceau de cette première partie, on y débute l’implémentation de l’étude de cas, avec configuration Maven, définition de processus, implémentation de tâches en Java et tests unitaires. Honnêtement, ça fait un peu trop de chose pour être vraiment clair.

La seconde partie est consacrée à l’implémentation de processus avec Activiti, c’est donc le cœur du livre. On y compte 150 pages et 5 chapitres, ce qui le met à égalité avec la 3ème partie. Là où le chapitre 4 était un peu brouillon, le chapitre 5 reprends les choses calmement et implémente un BPM simple mais non trivial, avec une implémentation d’un script task et de différents service tasks. On va même jusqu’au déploiement. C’est bien fait et clair. Le chapitre 6 nous permet de faire des choses plus avancées (sous-processus, points de décision) et couvre aussi l’accès à JPA depuis Activity et la mise en place de listeners sur les tâches. La gestion des erreurs (en Java ou en définition de processus) est traitée avec sérieux au chapitre 7, un bon point ! C’est aussi le cas sur les options de déploiement abordées au chapitre 8, bien que je reste sur ma faim sur la façon dont l’utilisation de l’interfaçage ReST est abordé. Le chapitre 9 qui clos cette partie n’est pas mon préféré. Seul la partie OSGi m’aurait intéressée si elle avait été abordée clairement !

La troisième partie se focalise sur les aspects avancés d’Activity. Le chapitre 10 fait un peu pot-pourri entre des aspects avancés de modélisation (sous-tâches, délégation), la connexion au LDAP ou les tâches multi-instances, ça manque un peu de cohérence. Le chapitre 12 est plus « focus » car il traite d’un aspect important : l’intégration. L’utilisation d’Apache Camel et de Mule ESB font le gros de ce chapitre. C’est une bonne idée, car cela donne un exemple avec ESB et un autre avec « ESB light ». L’intégration d’un moteur de règle n’est pas nécessairement l’aspect qui m’aurait intéressé de prime abord, mais le chapitre 13 qui le traite et clair, bien écrit et même source d’inspiration. Je ne dirais pas la même chose du chapitre 14 qui traite de l’intégration avec Alfresco.

Alfresco est le principal comiter Activity et parler de cette intégration sonne comme un passage obligé, mais personnellement j’en retire peu de choses. Ca fait plutôt plaquette publicitaire. Cette partie se conclut par un passage par le monitoring de production e l’intégration avec Esper : utile, intéressant et bien fait.

La quatrième partie ne compte qu’un seul chapitre et 25 pages. L’objectif est de nous permettre de monitorer les processus en production. Concrètement on entre dans le modèle de données d’Activity et on fait un petit tour dans le Job Executor. Pas grandiose mais nécessaire.

Activity in Action fait bien le boulot, il est à la hauteur du standard « in action » de Manning. Le texte est bien écrit et les illustrations aident. Les exemples par contre sont plus problématiques : ils sont souvent non seulement complexes et volumineux, mais insuffisants tels qu’ils figurent dans le texte. Il est nécessaire d’avoir recours au code source complet.

Personnellement, mon regret est une approche très « Activity centric », où les fonctions du logiciel sont subordonnées aux hooks qu’offre le framework. Etant essentiellement conçu en ce sens, l’approche est compréhensible. Toutefois Activity possède aussi un ensemble d’API ReST permettant de l’utiliser de l’extérieur à la façon d’une appliance. Je suis d’avantage intéressé par cette architecture et je soupçonne que de nombreuses personnes le sont également. Très peu de contenu est orienté en ce sens. A mon avis, l’ouvrage aurait bénéficié d’un ou deux chapitres en ce sens, même si cela avait dû être au détriment d’autres sujets.

Malgré ces quelques frustrations, le contrat est bien rempli. Pour qui veut s’initier à Activity, voilà un excellent compagnon.

image

Référence complète : Activity in Action, Executable business processes in BPMN 2.0 – Tijs Rademakers – Manning 2012 – ISBN : 978 1 617290 12 1

Activiti in Action

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

Note de lecture : L’EAI par la pratique, par François Rivard et Thomas Plantain

Note : 4 ; Noyé !

J’ai éprouvé de l’intérêt et des regrets à la lecture de ce livre. De l’intérêt tou d’abord : des livres sur l’EAI, il n’y en a finallement pas des masses et ils volent souvent un peu trop haut, évoquant les flux d’échanges B2B et autres intégrations de systèmes. Mais ils évoquent rarement la mise en œuvre pratique : ce n’est pas le cas de celui-ci.

Ici, on est de plein pied dans la réalisation de flux EAI, en l’occurrence avec Vitria. Pour illustrer cela, on dispose d’une étude de cas dont je dois dire qu’elle a juste la bonne complexité, ni trop ni trop peu. Et pour structurer cette mise en œuvre, les auteurs nous proposent une démarche étagée en 4 niveaux :

  • Conception : On modélise le processus métier les tableaux de bord désirés d’un coté et l’architecture technique (y compris les besoins en terme de connecteurs applicatifs de l’autre).
  • Mise en œuvre : Déploiement des configurations EAI et référentiel d’intégration.
  • Réalisation : il s’agit là de l’implémentation des processus métier avec le produit, de la réalisation des tableaux de bord, des échanges B2B et autres mappings.
  • Exploitation : On évoque ici le suivi d’exploitation fonctionnel et technique.

La partie « mise en œuvre » évoque également dans 2 chapitres qui leurs sont dédiés, l’utilisation de Tibco Rendez-vous et de WebMethod.

Alors, pourquoi ai-je noté si sèchement ? Eh bien, hélas, cette belle approche est malheureusement mise à mal par le traitement trop « outil » du sujet. Plutôt que de faire apparaître les traits essentiels, nous sommes noyés sous une avalanche de détails (souvent peu utiles) de réalisation, de copies d’écrans, etc. qui masquent complètement le fond. On ne sait même plus où on en est dans l’approche évoquée ci-desus. Bref, les auteurs auraient dû tailler dans le lard, alléger les détails et réduire le volume du texte des 400 pages qu’il accuse à 250 pages environ.

Dommage !

image

Référence complète : L’EAI par la pratique – François Rivard et Thomas Plantain – Eyrolles 2003 – ISBN : 2-212-11199-1

L'eai Par La Pratique

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

Note de lecture : Loosely Coupled, par Doug Kaye

Note: 7 ; Du Web Service à l’ESB

Tout d’abord une précision: si vous cherchez un ouvrage sur la mise en oeuvre technique des Web Services, ce n’est pas le bon livre. Cela dit, il en existe plein et celui-ci viendra en complément, car ce livre ne traite pas de mise en œuvre technique, mais d’aspect architecturaux liés à l’utilisation des Web Services dans un contexte SOA. Les grandes questions que pose cet ouvrage sont : comment puis-je utiliser les Web Services pour effectuer l’intégration de systèmes ? Quels sont les briques technologiques qui manquent et comment les compenser ? Bien sûr, ayant lu ce livre presque 5 ans après sa parution, j’en ai raté l’approche novatrice en bonne partie car ce sont ni plus ni moins que les bases de l’ESB que l’auteur pose ici ! Mais même en arrivant après la bataille, le texte éclaire l’approche Web Service proposée ici (attachement + couplage faible + asynchronisme) qui a été emmprunté par l’ESB et peut nous permettre de mieux exploiter ceux-ci correctement. Allons voir plus en détail le contenu des 320 pages de l’ouvrage.

Le livre est intelligemment découpés en 20 chapitres dont la longueur varie de 10 à 25 pages. Le format du livre étant également plus petit qu’à l’accoutumée, chaque chapitre se lit donc aisément, ce qui est une bonne chose.

La première partie, intitulée « perspectives » est composée de 5 chapitres. Elle campe les besoins d’infrastructures d’une architecture d’intégration de services, d’abord en rappelant l’historique au chapitre 1 (Corba, COM, DCE, EAI, etc…), ce qui est synthétique et bien fait. Ensuite le chapitre 2 met en perspective les Web Services avec les technologies vues précédemment et les avantages relatifs de cette technologie. Le chapitre 3 nous projette dans l’extrapolation, l’évolution des technologies « en devenir » et des « mainstream » pour stigmatiser l’importance des Web Services. Les chapitres 4 et 5 sont complémentaires et servent de charnière pour le reste du livre : que manque-t-il à la technologie Web Services pour être une pièce maîtrise du SOA et de l’intégration de services.

Aux 58 pages de cette première partie succède une seconde partie longue de 82 pages et intitulée « concepts ». les 5 chapitres qui la compose détaillent les paradigmes que l’auteur juge importants par rapport au SOA. Le chapitre 6 développe la volet intégration et poursuit une discussion commencée au chapitre 2. Les chapitres 7 et 8 nous aident à comprendre les corollaires d’une architecture d’intégration basée sur les Web Services et pourquoi le style orienté document doit être favorisé par rapport au style RPC. Les chapitres 8 et 9 sont dédiés à l’architecture asynchrone et pourquoi ce style doit être favorisé en intégration de services.

La troisième partie « technologies » est consacrée … eh bien au volet technologique ! Ce sont de nouveau 5 chapitres et 90 pages qui sont dédiés à cette avant-dernière partie. Le volet « sécurité » s’y taille la part du lion, avec 2 chapitres et 46 pages. Le premier chapitres met en évidence les besoins (intégrité, authentification, non-répudiation, etc…) rien de bien original mais fort bien expliqué. Le second chapitre propose des solutions, bien que celles-ci soient souvent, disons originales (comme le XML firewall). Un chapitre est consacré aux transactions et plus précisément aux transactions applicatives. La surcouche orchestration n’est évoquée que brièvement car elle sort du cadre de cet ouvrage, tout comme l’aspect déploiement qui est traité assez légèrement.

La dernière partie « stratégie » interpelle les managers. Quid de la qualité de service (chapitre 16) ? Qu’en est-il des SLA et de l’externalisation de services (chapitres 19 et 20). Enfin la gestion de projets d’intégration est traitée aux chapitres 17 et 18.

Bref, voilà un ouvrage qui vaut le détour. Il n’est pas purement technique et ne vous apprendra pas à développer ou utiliser des Web Services mais donne des clés pour créer une architecture intelligente basée sur cette technologie.

image

Référence complète : Loosely Coupled, the missing pieces of web services – Doug Kaye – RDS press 2003 – ISBN : 1-881378-24-1 ; EAN : 9 781881 378242

Loosely Coupled: The Missing Pieces of Web Services

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

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

OSGi en mode natif et ployglotte

Parlons net : aujourd’hui OSGi est la seule alternative qui marche à la pantalonnade “Java Modules” qui ne cesse d’être repoussée de version en version de Java. On ne saurait affirmer que nous les auront pour la version 9, mais on sait déjà que les développeurs n’auront pas accès à l’écriture de modules.

OSGi marche et depuis longtemps. Par le biais de la RFP156, cette “SOA ina JVM” n’entends pas rester cantonnée à un rôle de faire-valoir par rapport à Java Module, mais à s’étendre à d’autres environnements et langages. Sont principalement visés: C, C++ et Javascript ; mais les autres environnements sont évidemment bienvenus.

Les participants à cette RFP font tous partie des mondes C et C++; en l’occurence Celix ©, CTK plugin framework (C++), NOSGi (C++) et CppMicroServices (C++).

Cette RFP est assez sommaire, voir superficielle. Elle fait le point sur les travaux des différentes équipes et s’en sert comme base pour les requirements listés à partir de la page 9.

Et sur les autres fronts

Il y a aussi un projet sur GitHub mais il ne semble pas bouger depuis au moins un an.

Mais on n’en reste pas là. Le Polyglot OSGi fait son chemin, comme nous le démontre cette présentation

Et après le RFP 156 centré sur C++, cet article fait le point sur OSGi pour Javascript, incarné par la RFP 159 (mais celle-ci reste un brin creuse).

Le choses bougent avec une réelle volonté côté OSGi ; Elles bougent au moins aussi vite que ne s’enlise ces java Modules, pas encore là et déjà vidés de leur substance…