Note de lecture : OSWorkflow, par Diego Adrian Naya Lazo

Le par addinquydans Notes de lectureLaisser un commentaire

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

Réflexions sur la pensée agile, par Tobias Mayer

Le par addinquydans PresentationLaisser un commentaire

La keynote de cloture de l’auteur de The People’s Scrum lors d’Agile Spain 2013 évoque le “Business Craftmanship”, qui est également le titre de son blog. Tobias se centre et approfondis les fondement de la pensée agile. “people before process and tools” est une valeur dont on s’éloigne parfois sans même y penser. Tobias nous le rappelle !

Tobias était aussi présent à Agile EE pour évoquer les valeurs du “Tought Citizen”. Il nous parle d’inconfort, de courage et de “deep dialog”.

… Et Neo4J devint CMS !

Le par addinquydans Compte-renduLaisser un commentaire

Lors de ce Meetup Neo4J de Janvier, toujours dans le zLocalHost de Zenika, nous avons pu découvrir Structr, et comment il adresse la problématique du CMS. Ou du moins, nous allons le faire.

Cédric Fauvet au pas de charge !

Cédric commence par sa très classique introduction à Neo4J. Introduction un peu écourtée d’ailleurs : c’était la soirée des problèmes techniques et il a fallu rattraper le temps perdu.

Le temps tout de même de donner quelques nouvelles de la communauté et de l’actualité. On s’attardera quelques instants sur la dernière référence Française : Meetic ! Bien entendu, comme pour Viadeo, le but est la recherche d’adéquation de profiles. Ce n’est d’ailleurs pas une première expérience pour Neo4J qui a équipé d’autres sites de rencontre avant de s’occuper du n°1 européen.

Autre nouvelle intéressante : la mise à disposition de cours en ligne ! J’ai hâte d’aller voir ça…

Structr

Axel Morgner est fondateur de Structr, il est venu spécialement de Frankfort pour évoquer son usage de Neo4J. Après avoir longtemps travaillé dans le domaine du CMS, il a décidé de changer d’horizon, de faire autre chose. Il a découvert Neo4J, et a décidé de construire avec … un CMS !

image

Structr c’est une société mais aussi un logiciel open-source. La motivation ? Construire des sites web dynamiques avec du contenu. La première release de la bête est apparue en 2011.

La première itération : c’est une classique webapp standalone, dont la partie front utilise freemarker.

Les choses changent radicalement en seconde itération ! C’est d’abord un changement de scope : Structr devient un pur back-end, le front-end est abandonné ! Le produit assure un mapping bidirectionnel entre JSON et le graphe. Et le produit intègre une notion de schéma et de contraintes (avec même une gestion des suppressions en cascade), des choses qui vont bien plus loin que les évolutions apportées par Neo4J 2.0 !

L’interface utilisateur revient en 3ème itération, mais elle s’est faite HTML5 ! Elle permet l’édition sur place, la visualisation des liens entre pages, etc…

Démo time !

Axel nous fait bien sûr une petite visite guidée de la bête. On commence fièrement par un import de page que l’outil digère pour le transformer en graphe. On peut utiliser alors l’édition sur place pour importer ou saisir du contenue … ou faire référence à du contenu dans le graphe, via des requêtes Cypher, par exemple !

image

La sécurité n’est pas en reste et elle se configure sur les noeuds. Elle est bien sûr transitive, suivant les liens “contains”. L’IHM est aussi synchronisée entre les clients, permettant l’édition de contenu collaboratif.
Mais tout cela, c’est du statique. Du “boring stuff” comme le dit Axel. Structr gère la dynamicité du contenu, en partie du fait qu’il ne gère pas de cache et se repose sur la performance de neo4J. L’une des clés est la référence qui peut être faite depuis les pages vers du contenu structuré lui-même dans le graphe.

Pour cela il faut créer un projet “data type”. C’est lui qui permet la structuration des données et les contraintes dont nous avons parlé plus haut. On y crée aussi des bindings qui peuvent être référencés par des noms symboliques.

L’une des question que je me posais pendant que la démo se déroulait concernait les contenu volumineux, de type “blob”. On sait que Neo4J n’est pas fait pour cela. Qu’a cela ne tienne, les data types peuvent référencer des fichiers ou même des répertoires ! Au-delà de cela, il y a aussi des concepts de “web components” et de “shared components area”, mais ne m’en demandez pas plus, car j’ai un peu perdu le fil à ce moment là !

Malgré quelques petits accrocs lors de la démo, il faut avouer que cette gestion de contenu est pour le moins étonnante et résolument différente de ce qui se fait !

Teasing

Cédric souhaitait innover en donnant une minute de parole au débotté à des participants du Meetup ayant un projet avec Neo4J.

Un étudiant de Supinfo Lille (désolé, je n’ai pas noté son nom) nous a donc parlé de son projet d’étude : un “Dropbox like” intégrant une dimension sociale de partage. L’utilisation de Neo4J permet ici de représenter les structures de fichiers, répertoires, partages et droits, tandis que les contenus eux-même peuvent être répartis sur différents serveurs de stockages, ces contenus étant simplement référencés dans le graphe.

Quand Sébastien Just est venu nous parler de Seij, j’ai cru que Structr venait de trouver son frère jumeau ! J’ai pu discuter un peu avec Sébastien et suis maintenant convaincu que ce n’est pas le cas. Certes les deux applications partagent nombre de concepts : le CMS basé sur des graphes Neo4J et la possibilité de constituer son contenu en assemblant les éléments issus des noeuds. Mais là où Structr s’appuie sur une structuration et un typage fort, Seij s’enorgueillis de son approche “free form”, un peu comme si l’on avait un Excel pour la gestion de contenu. Des concepts très proches mais un ciblage client très différents en font deux produits qui ne se comparent finalement pas. J’espère que Sébastien aura l’occasion de revenir nous le présenter et nous en parler !

OSGi en mode natif et ployglotte

Le par addinquydans PresentationLaisser un commentaire

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…

Le par addinquydans En imagesLaisser un commentaire

Le Congrès Solvay de 1927

Le congrès Solvay 5ème du nom ayant pour thème “électrons et photons” reste le plus célèbre, d’une part parce qu’il permit la première rencontre entre Lorentz et Einstein mais surtout par l’impressionnant aréopage de sommités réunis à cette occasion. Je vous laisse découvrir les noms figurant sous la photo…

Note de lecture : Software in 30 days, par Ken Schwaber & Jeff Sutherland

Le par addinquydans Notes de lectureLaisser un commentaire

Note : 3 ; Déçu, déçu, déçu et anachronique !

Jurgen Apello a qualifié ce livre de « poorly writen marketing brochure ». Je dois avouer que cela résume bien le livre. Pourtant, je me réjouissais d’avoir enfin un texte co-écrit par les 2 créateurs de la méthode, mes attentes étaient donc élevées, c’est certain. Voyons ce qu’il en est.

Le livre est bref : 125 pages (rajoutons les 3 très volumineuses annexes qui comptent tout de même 60 pages), sur 10 chapitres rassemblées en 2 sections. C’est du John Wiley, le papier est dégueulasse, c’est une habitude chez cet éditeur. En fait, ça commence même mal dès la couverture : qui fait encore du Scrum sur 30 jours ? Les auteurs sont restés campés sur leur position vieille de 20 ans (pour être précis). Le monde a changé entre temps, ils ont choisi de décider que le monde avait tord et que la Vérité promulguée il y a 2 décennies était inaltérable. En tout cas, cela ressemble à ça.

Long d’un peu plus de 50 pages et fort de 4 chapitres, la première section défends l’idée que toutes les organisations peuvent produire du logiciel… en 30 jours (encore !). Les 13 pages du 1er chapitre introduisent la « crise du logiciel ». C’est l’introduction classique à l’agilité. L’intérêt ici, c’est de s’appuyer sur des études datant de 2011 au lieu de la classique étude du Standish group de 2002 !

Au chapitre 2, on s’intéresse à l’essence de Scrum : l’empirisme. Un propos que j’ai l’impression d’avoir déjà lu il y a 10 ans dans les ouvrages précédents de Ken Schwaber. Plus pathétique encore : comparer cette approche au Waterfall. Sans doute il y a-t-il encore un peu de Waterfall sur des projets dans des coins, mais que diable, nous sommes en 2013 !

Après l’introduction, la mise en œuvre. Le chapitre 3 nous propose de choisir un projet pilote pour mettre en œuvre Scrum. C’est à mon avis un anachronisme de plus, car si ce concept pouvait exister il y a 10 ans, aujourd’hui les projets qui ne sont pas critiques ne sont simplement pas faits. Seule bonne nouvelle : le chapitre est court.

Cette première partie s’achève sur un court chapitre de 8 pages qui pose et investigue la question : quelle est la prochaine étape ? C’est une introduction à la seconde partie.

Cette seconde partie, justement, compte 70 pages sur 6 chapitre. Elle débute par le chapitre 5 qui présente les grandes lignes du framework Scrum. Le grand moment de rigolade de ce chapitre, c’est quand les auteurs prétendent que la majorité des mises en œuvre de Scrum se font avec des durées de 30 jours et que la réduction de cette durée à 2 semaines n’affecte que de façon très marginale les durées des meetings de début et fin d’itération. C’est ce qu’on appelle être bien à côté de ses pompes !

Le chapitre 7 nous présente le « studio Scrum ». C’est peut-être le chapitre le plus intéressant du livre, sans qu’il soit non plus transcendant. Mais au moins on parle un peu sérieusement de la « definition of done », par exemple.

Les chapitres 8 et 9 évoquent Scrum au niveau de l’entreprise. Cela reste dans la même veine que l’Enterprise Scrum de Ken Schwaber, rien de nouveau et c’est nettement plus superficiel.

Enfin le chapitre 10 nous parle de cycles d’amélioration de Scrum. Là encore un propos qui fait double emploi avec la prose de Agile Project Management with Scrum de Ken Schwaber.

Le Scrum Guide de l’annexe B est celui disponible en ligne. OK, cela occupe au moins un peu de place. Le « playbook » de l’annexe 3 est plus originel, quoiqu’il date de 2005 !

Ce livre est une grosse déception à de nombreux niveaux. Clairement j’attendais mieux des créateurs de la méthode. Le propos est très superficiel, et même carrément marketing. Je m’attendais à y voir les tripes des auteurs, y sentir des choses profondément ancrées : rien. Le seul intérêt que je peux voir est l’usage exclusif des termes et concepts originaux de Scrum. Ainsi on y parle exclusivement de « product backlog items (PBIs) », là où il semble admis un peu partout de parler de user stories… le retour aux fondamentaux n’est pas nécessairement un mal partout.

S’il n’y a pas de raison à bouleverser le framework Scrum, le propos n’a pas non plus changé d’un iota. Un certain nombre de points souvent dogmatiques sont toujours là et présentés comme indiscutables. Pourtant ils peuvent l’être ou être anachroniques, tel la durée des sprints sur 30 jours (ce que je n’ai ni pratiqué, ni jamais vu pratiqué). Un livre que je déconseille très fortement à tout le monde. Les bons livres sur Scrum existent. Ailleurs.

Référence complète : Software in 30 days – Ken Schwaber & Jeff Sutherland – John Wiley & sons 2012 – ISBN : 978-1-118-20666-9

Software in 30 Days: How Agile Managers Beat the Odds, Delight Their Customers, And Leave Competitors In the Dust

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