Quelques Nouvelles de Petals ESB

J’avais pensé faire un titre plus original, mais j’y ai renoncé.
J’avais aussi égrainé quelques informations ces derniers mois sur le forum de support de Petals ESB. J’avais notamment précisé que je ne travaillais plus qu’à temps très partiel sur Petals ESB. En gros, je suis ce qui se fait. Cela rejoint les objectifs que nous avions définis l’an passé. Mais je ne développe plus sur Petals pour l’instant, ou très peu.

En réalité, je travaille sur une plateforme collaborative dans le nuage (PaaS, cloud computing, ce genre de choses…). J’espère en parler d’ici quelques mois, le temps que la base du projet soit stable.

Mais revenons-en à Petals.
Je vous propose ici 3 parties : la première va retracer la vie du projet au cours des douze derniers mois, la deuxième va expliquer ce qui est fait actuellement et où le projet va, et la troisième servira de conclusion et d’ouverture.

 

Rétrospective

Remontons jusqu’à mars 2012. Ce mois marque un tournant dans la vie du projet (un des nombreux virages qu’aura connu Petals). Ce tournant concerne l’équipe de développement, la roadmap et l’organisation de l’équipe. Jusqu’alors, le projet avait toujours été piloté sur Toulouse, avec quelques antennes et contributions ça et là (c’est là que je précise que je suis sur Grenoble). En mars, nous sommes passés à un mode complètement distribué. Une première roadmap a été revue pour stabiliser et compléter la release de la version 4 de Petals. C’est la version 4.1, sortie en juin 2012, et téléchargeable sur le site communautaire. Cette release apportait des améliorations sur Petals CLI, notre outil d’administration en ligne de commandes, et d’énormes progrès sur les performances et la robustesse (introduisant au passage de nouveaux paramètres de configuration). Quand je dis progrès, je peux illustrer ça avec la méthodologie de tests : vous prenez un client qui appelle un service web au travers de Petals. Et ce service va générer en quelques secondes plusieurs milliers de requêtes. C’était un test qui n’avait pas été poussé aux limites (remplir les files jusqu’à leur maximum). Ces tests ont fait apparaître des faiblesses, qui ont été corrigées. Vraiment plus aucun message n’est perdu. Sans rentrer dans les détails, disons que les consommateurs s’adaptent aux capacités de traitement des fournisseurs de service dans le bus.

Au même moment que cette release, Linagora absorbait la société à l’origine de Petals ESB, et la roadmap suivante était définie. Elle visait une release 4.2 à la fin de l’automne. Certains l’avaient peut-être vu sur le forum. Cette release portait sur des améliorations de l’outillage de Petals 4 : administration (refonte complète de la partie web, nouvelles commandes pour Petals CLI), supervision de la plateforme (rajout de sondes et documentation de l’utilisation d’outils comme Cacti pour se brancher sur ces sondes) et supervision des flux (exploitation des nouveaux logs avancés, avec des outils comme Splunk, Jasper ou BIRT par exemple). Surtout, il était prévu d’écrire un nouveau tutoriel pour ceux qui découvrent Petals.

Le travail avait bien commencé, mais a été interrompu au début de l’automne. Des ressources, dont moi, ont été affectées sur d’autres projets. La roadmap a été ajournée. Et nous avons très mal communiqué sur le sujet. En grande partie parce que ce n’était pas très clair pour nous.

Avec quelques mois de retard sur ce que nous avions prévu à l’origine, Linagora devrait sortir la prochaine version 4.2 de Petals ESB avant l’été (2013 – je précise pour les mauvaises langues :P).

 

Petals 4.2 et après…

J’ai dit « devrait », car on veut mettre beaucoup de choses.
En gros, cette release contiendra les évolutions suivantes :

  • Nouvelles commandes de Petals CLI, l’outil d’administration en ligne de commande pour Petals.
  • Revue des logs avancés : plus de MONIT_MSG, log handlers complètement externalisés et indépendants du code du conteneur. On peut donc rajouter son propre log handler sans avoir à « recompiler Petals ».
  • L’item précédent peut faire sourire, mais Petals surveillait l’ensemble des JAR chargés au démarrage. Petals 4.2 vient maintenant avec un mécanisme d’extensions, qui va se généraliser avec l’avenir.
  • Distribution de Petals ESB et Petals CLI sous la forme de paquets Debian, pour une meilleure intégration avec certains systèmes d’exploitation basés sur Linux.
  • Rajout de sondes JMX dans le transporteur et le BC SOAP, pour une exploitation avec des outils comme Nagios, Cacti & co… De telles sondes vont être ajoutées un peu partout au cours des prochaines releases.
  • Une nouvelle version du studio devrait sortir, corrigeant ainsi de nombreux bugs qui étaient apparus avec les versions 1.3.x.

Au passage, le BC EJB va définitivement passer en composants communautaires. Nous avions des évolutions et des corrections en tête, mais elles sont compliquées et très coûteuses en ressources. C’est un investissement et une maintenance qui ne se justifient pas, d’autant que ce composant n’est plus utilisé.

Enfin, le SE BPEL devrait bientôt passer en composants communautaires lui aussi.
Non pas que BPEL soit définitivement abandonné, mais cette implémentation est elle-aussi coûteuse à maintenir. On songe à d’autres options. Et c’est là que l’on peut aborder ce qui va venir plus tard.

Un premier chantier concerne l’orchestration et la composition de services dans Petals. Il faut quelque chose de plus simple. Actuellement, c’est Java, EIP ou BPEL. Java restera. BPEL devrait passer au travers d’un composant ODE, et ne plus se baser sur le moteur que nous avions cherché à développer. Quant au SE EIP, il devrait être supplanté par un composant Camel (notre fameux serpent de mer, mais Camel est juste incontournable).

Un deuxième chantier, en cours depuis l’automne, et qui va courir encore longtemps, c’est la cloudification de Petals ESB. Petals étant déjà distribué, on pourrait croire que le passage est assez simple. Alors, certes, cela simplifie des choses. Mais cela reste un gros chantier. En plus de définir ce qu’est un « ESB as a Service », il s’agît aussi et surtout de revoir tout le conteneur Petals (basé sur JBI pour rappel). Il s’agît d’améliorer la modularité du socle de Petals, pour pouvoir ensuite rajouter de nouvelles fonctionnalités. On touche là à la dette technique d’un projet qui fêtera bientôt ses 9 ans. Je vais quand même préciser que c’est très bien parti (la 4.2 inclut certains résultats de cette démarche).

Enfin, un troisième chantier devrait concerner les outils, avec une nouvelle console d’administration web, et des démonstrateurs variés pour illustrer la supervision de la plateforme (Est-ce que mon noeud Petals a assez de CPU ? Est-ce qu’un web service invoqué par Petals est tombé ?) et la supervision des flux (outil personnalisé, Jasper, BIRT, etc). Et si je trouve un peu de temps, j’essayerai de rédiger un nouveau tutoriel sur Petals ESB. Celui qu’il y avait pour la version 3 a certes aidé des gens à se lancer, mais je le trouve assez limité. Il n’explique pas grand chose au final, sur ce qu’est un ESB ou à quoi ça sert, ni sur comment on peut utiliser Petals sur son propre cas d’usage.

 

Tant qu’à donner des nouvelles…

Ce billet devrait rassurer ceux qui s’inquiétaient de ne pas avoir de nouvelle de Petals. En même temps, je précise que Linagora rédige une note qui sera publiée sur son site très bientôt. C’est aussi une des raisons pour laquelle je me permets d’en parler ici. Alors certes, l’équipe est un peu moins fournie qu’avant, mais le projet bouge encore, à son rythme.

Il m’arrive de me demander quel créneau Petals peut encore occuper, quand on voit la concurrence, les moyens impliqués et les résultats obtenus. Et pourtant, Petals a de vraies qualités. De ce point de vue, Petals reste un vrai projet open source, poussé par quelques personnes qui y croient encore. C’est un projet qui se distingue réellement sur les problématiques d’architecture. La partie serveur est robuste et performante, et petit à petit, Petals en est venu à couvrir la grande majorité des besoins, notamment sur les différents types de supervision. Et le tout, intelligemment. C’est un cheminement qui a été long et difficile, mais nous avons appris de nos tentatives et erreurs passées. On adresse ces besoins, mais leur couverture n’est pas encore optimale. Nous avons aussi mûri sur la dualité « éditeur / prestataire de services ». Aujourd’hui, Petals fournit énormément de bases ou de points d’ancrage. Libre après aux équipes projets d’utiliser ces points dans leur contexte. Ainsi, sur la supervision des flux, nous n’imposons aucun outil. On fournit un système qui peut être adapté à des cas d’usage très variés, soit en customisant les logs handlers, soit en développant sa propre solution d’exploitation, soit en la branchant sur des solutions existantes (comme Jasper ou BIRT). Ce n’est pas à nous, éditeur, de faire le choix. En revanche, on peut accompagner et conseiller une équipe projet sur des choix. Je pense que cette liberté est une vraie force de Petals ESB.

Il reste encore des faiblesses, que nous allons tenter de régler progressivement. En tant que formateur et consultant, j’ai surtout en tête la partie outillage et la couverture fonctionnelle des composants. Mais on ne peut pas tout faire en même temps.

Avant de vous laisser, je vais également mettre des pointeurs vers des contributions, en cours de maturation, et qui pourraient venir un jour compléter l’ensemble des outils Petals.

Une application web pour administrer un ensemble de noeuds Petals.

petals-web-admin

Une application web qui illustre les capacités liées à la supervision des flux. C’est une démonstration de ce que l’on peut faire, que l’on retrouvera certainement soit dans un tutoriel, soit en formations Petals.

petals-simple-flow-viewer-1

petals-simple-flow-viewer-2

Un client de test plus complet dédié à Petals ESB. Un genre de SoapUI adapté à Petals. Probablement utilisé pour les tutoriels et en formations Petals.

petals-test-client

Publicités

About this entry