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


One more video of a talk I gave at OW2Con 2012 about a research project I am working on since two years now called Play (and not the play framework…).

"The PLAY project develops an elastic and reliable architecture for dynamic and complex, event-driven interaction in large highly distributed and heterogeneous service systems.
Such an architecture will enable ubiquitous exchange of information between heterogeneous services, providing the possibilities to adapt and personalize their execution, resulting in the so-called situational-driven process adaptivity…"


Classé dans:Conference Tagged: cep, cloud, eda, events, opensource, ow2, ow2con, PEtALS, petalslink, SOA

Here is the video of a quick talk I gave two weeks ago at OW2Con 2012 dealing with Petals Enterprise Service Bus.

He gives some background about what is Petals, how it can be used, why it is a distributed runtime, what is really new in the last version and finally what is planned in the next version.

I already spent many time explaining what we have in mind to push Petals in the cloud and this will be a reality in the next months as we are currently working on that exiting feature. More information soon, for real this time!


Classé dans:Conference Tagged: cloud, esb, ow2, ow2con, PEtALS, petalslink, SOA

Status Dashboard is an awesome node.js monitoring application developed by @obazoud. I recently sent some pull requests to Olivier to improve the IRC plugin and then I though that even if I am always connected to IRC, jabber or whatever, I also have a Terminal opened most of the time. So the question was: How can I get my services status pushed to my laptop in realtime?
Socket.IO is the candidate: It does not provide only server and browser modules, there is also the socket.io-client module which can be used in your node runtime, on the client side in exactly the same way you use Socket.IO in your HTML pages. Since Socket.IO is already used in Status Dashboard to push status to the browser, we have the right solution.

I created a simple node.js client application called statusdashboard-client which connect to a status dashboard instance using Socket.IO. Once data is pushed by the server to the client, it is displayed with some basic code colors on the terminal:

It is totally fun to see what we can do without any node.js expertise. I just start looking at it but I already have many ideas, especially for platform monitoring.


Classé dans:Node Tagged: dashboard, JavaScript, monitoring, Node.js, petalslink, socket.io, terminal, Web application

Status Dashboard is an awesome node.js monitoring application developed by @obazoud. I recently sent some pull requests to Olivier to improve the IRC plugin and then I though that even if I am always connected to IRC, jabber or whatever, I also have a Terminal opened most of the time. So the question was: How can I get my services status pushed to my laptop in realtime?
Socket.IO is the candidate: It does not provide only server and browser modules, there is also the socket.io-client module which can be used in your node runtime, on the client side in exactly the same way you use Socket.IO in your HTML pages. Since Socket.IO is already used in Status Dashboard to push status to the browser, we have the right solution.

I created a simple node.js client application called statusdashboard-client which connect to a status dashboard instance using Socket.IO. Once data is pushed by the server to the client, it is displayed with some basic code colors on the terminal:

It is totally fun to see what we can do without any node.js expertise. I just start looking at it but I already have many ideas, especially for platform monitoring.


Classé dans:Node Tagged: dashboard, JavaScript, monitoring, Node.js, petalslink, socket.io, terminal, Web application

Pour ceux qui auraient loupé l’information, Petals ESB vient de sortir dans sa version 4.1.
Il est accompagné d’une version de maintenance du studio (1.3.2). Ce dernier corrige des bugs qui avaient été reportés sur la version précdente.

Alors, que nous réserve cette nouvelle mouture de Petals ?

Pour moi, Petals 4.1 marque le passage définitif aux versions 4.x. Quand la 4.0 est sortie en janvier, elle cohabitait encore avec la dernière version de maintenance de Petals 3, la 3.1.3. Et la 3 s’en sortait très bien face à la 4. La version 4.1 met tout le monde d’accord, elle est bien supérieure aux 2 versions précédentes. Elle contient plusieurs corrections de bug, ainsi que de légères refontes qui préviennent les fuites mémoire (ces mauvaises pratiques qui empêchent le garbage collector de faire son travail, parce qu’il reste une référence cachée à un objet Java). Un exemple concret de ce dernier cas est le remplacement des classes internes qui n’étaient pas statiques. Bref, il y a eu un beau travail de profilage sur le bus.

Il y a également eu un chantier mené sur les performances aux limites.
En effet, si Petals tient bien la charge, il fallait en revanche prévoir une petite marge sur la volumétrie (toujours ménager un peu de place dans les files de messages). Cette marge, une fois épuisée, pouvait mener à des problèmes tels que timeout, mauvaise gestion côté émetteur du message, voire pire, la perte du message. Aujourd’hui, tout ça est du passé. La politique de gestion des messages a été revue. Contrairement à ce que l’on pourrait croire, ce n’était pas un problème de persistance, mais bien une négociation entre l’émetteur et le récepteur du message (entre le consommateur et le fournisseur du service) lors de l’échange. Aujourd’hui, il y a une adaptation propre qui prévient ces problèmes. Cela a pu être vérifié lors de tests aux limites, avec un fort débit de messages, et des files d’exécuteurs et d’attentes archi-pleines.

Mieux encore, cette évolution a mené à l’ajout de nouveaux paramètres dans la configuration des composants Petals. Ces paramètres permettent un calibrage (on dit aussi tuning) plus fin de Petals ESB. Concrètement, l’ajustement de ces paramètres permet d’améliorer le traitement d’une volumétrie particulière de messages au sein du bus. Toutefois, ce genre d’opérations nécessite une bonne connaissance du fonctionnement des composants Petals. Il est possible que l’on rajoute un jour un volet à ce sujet dans la formation Petals. Ou dans une formation « exploitation de Petals ESB ».

Enfin, la 4.1 sort avec une nouvelle version de CLI, le client d’administration en ligne de commande pour Petals.
J’aurai l’occasion de revenir sur cet outil dans un autre article.

Au final, cette version 4.1 est donc une bonne chose.
Elle pose une base solide sur laquelle les clients et utilisateurs peuvent s’appuyer. C’est aussi la base sur laquelle nous allons nous appuyer nous pour les évolutions à venir (et que l’on a hâte de pousser). Je vais tenter la semaine prochaine de trouver un moment pour présenter un peu les orientations des prochains mois sur Petals ESB.


Some of you may have already worked with the Petals JMS component.
This connector works in two different modes. In the first one, said provider, the component exposes services. When invoked, these services post messages on a JMS queue or topic. In the second mode, said consumer, Petals listens to JMS queues or topics and propagates JMS messages as Petals messages intended to Petals services.

The Petals JMS connector is not part of the Petals distribution, for the moment. You have to get the source code from our SVN and compile it yourself.
To put it in the distribution, it would need to support the new Petals logging mechanism. Besides, we have many upgrades to perform on this component. However, it works and can be used in some cases.

Here comes the point where I talk about interactions with ActiveMQ (AMQ).
AMQ is pretty nice and easy to use. I think we can say this is one of the key JMS products in the open-source field. However, there are some limitations to know when using it with Petals. And this is not due to Petals.

Petals and JMS servers can interact through the Petals JMS component. To work, this component needs a JNDI. More exactly, JMS queues and topics must be made available through a JNDI server, so that both Petals and AMQ can read and write in them. Unfortunately, AMQ does not provide a real JNDI implementation. This results in a strong limitation: you cannot work with Petals ESB, AMQ and static queues or topics.

There are 3 workarounds:

  • Do not use AMQ’s JNDI implementation and use an external one.
  • Use dynamic queues or topics. This is a specific mechanism of AMQ. Basically, it consists in choosing dynamicQueues/yourQueue or dynamicTopics/yourTopic as your JMS destination.
  • Add a specific property in the JMS client (Petals JMS connector). Currently, the only solution is to patch the component. I have submitted a feature request to give more flexiblity in what we can pass to the initial context.

This information was also added to the documentation of the Petals JMS component.


 Hello everybody!

As you probably already know, we all at Petals Link have been acquired by LINAGORA. While this merge required some time and resources investment, it didn't prevent us to continue improving your preferred open source Enterprise Service Bus.

As such, we are happy to announce a new release of Petals ESB and its sidekick Petals Studio!

Petals ESB 4.1

This release focuses on three topics.

Performances, with improvements on retry policies, memory management and handling of large volumes of messages.

Administration, with several new controls on nodes from our command-line administration tool, together with history and auto-completion of commands.

Configurability, with fine-grained control on components parameters to better fit your specific needs in terms of performances, availability rates, message volumetry...

Detailed list is available on Petals ESB 4.1 release notes.

Petals Studio 1.3.2

This release is mainly intended to keep compatibility of Petals Studio with the latest Petals components. It also brings several bugfixes and improvments (see Petals Studio 1.3.2 release notes).

Both are waiting for you to try them: download Petals ESB 4.1 and Petals Studio 1.3.2.

We'd love to hear your feedback on the annoucement topic in our forum. We hope you like it!

Petals team @Linagora

Permalink | Leave a comment  »

 Hello everybody!

As you probably already know, we all at Petals Link have been acquired by LINAGORA. While this merge required some time and resources investment, it didn't prevent us to continue improving your preferred open source Enterprise Service Bus.

As such, we are happy to announce a new release of Petals ESB and its sidekick Petals Studio!

Petals ESB 4.1

This release focuses on three topics.

Performances, with improvements on retry policies, memory management and handling of large volumes of messages.

Administration, with several new controls on nodes from our command-line administration tool, together with history and auto-completion of commands.

Configurability, with fine-grained control on components parameters to better fit your specific needs in terms of performances, availability rates, message volumetry...

Detailed list is available on Petals ESB 4.1 release notes.

Petals Studio 1.3.2

This release is mainly intended to keep compatibility of Petals Studio with the latest Petals components. It also brings several bugfixes and improvments (see Petals Studio 1.3.2 release notes).

Both are waiting for you to try them: download Petals ESB 4.1 and Petals Studio 1.3.2.

We'd love to hear your feedback on the annoucement topic in our forum. We hope you like it!

Petals team @Linagora

Permalink | Leave a comment  »

One more Apache CXF and Heroku article to push Web services to the Java PaaS… In some previous articles I explained how to create JAXWS and JAXRS service by cloning/forking/whatever git repositories. This time it is almost the same but I created a maven archetype to generate tons of maven modules quickly and to integrate them in your maven-based projects (OK cloning a repository is faster, it does not download the entire Internet as Maven does…).

Let’s do it with a screen record to check how fast it is. With my poor Internet connection and some typos, I have something running on Heroku in less than 2 min 30…

Here are the commands used in the sample above:

The archetype source code is located at https://github.com/petalslink/petalscloud-maven-archetypes and deployed on OW2 repository. Once the project is generated from the archetype, one can add his own JAXWS-annotated services and associated Spring configuration (src/main/webapp/WEB-INF/beans.xml). Generated project is also available on github at https://github.com/chamerlingdotorg/maven-heroku-jaxws-sample.

Can it really be more easy?


Classé dans:Cloud, Java Tagged: Apache CXF, Apache Maven, Heroku, Java, jaxws, petalslink, Web service

Welcome

Archives

Categories

Latest Tweets

Page 1 of 3312345102030...Last »