Release de Petals ESB 4.1

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.

Publicités

Un joli progrès dans Petals Studio

Parmi les évolutions en cours dans le studio, en voici une qui va résolument faire gagner du temps aux utilisateurs.
Il s’agît d’afficher les opérations disponibles pour consommer un service dans Petals.

Pour rappel, consommer un service revient à invoquer l’une de ses opérations.
Dans certains cas, il est possible de déduire l’opération à invoquer depuis la requête (par exemple avec le mécanisme des actions SOAP). Dans d’autres cas, on a besoin d’indiquer dans la configuration du consommateur quelle opération invoquer. Jusqu’à présent, il fallait remplir cette partie à la main dans le studio. Sachant qu’un nom d’opération est un nom qualifié (avec un espace de nom), cela restait une tâche très lourde.

Désormais, il ne reste plus que certains cas pour lesquels cela devra être rempli à la main.
Avec le recul, il est facile de dire que cela aurait dû être fait dés le début. Mais ça n’a pas été le cas.
Lors de la définition d’un consommateur, si l’on s’aide de la boite de sélection de service…

… et si ce service est décrit par un WSDL, alors à la fin, on retrouve une liste déroulante avec toutes les opérations de ce service.
Pas la peine de se préoccuper du Message Exchange Pattern (MEP), celui-ci est géré en arrière-plan.

Dans le cas où ce service n’a pas de WSDL, les champs doivent être remplis manuellement.

Deux précisions tout de même :

  • Selon le composant associé à un service, il est possible, même sans WSDL, d’avoir une liste déroulante des opérations disponibles.
    Ainsi, pour un service de validation XML (SE Validation) ou un service de transformation XSL (SE XSLT), il y aura une liste déroulante à la fin de l’assistant, même si ce service n’a pas de WSDL.
  • De plus, certains consommateurs posent une limite sur l’invocation de service. Par exemple, pour l’invocation d’un service suite à la réception d’un email (BC Mail), le message d’invocation sera forcément envoyé en InOnly (le service invoqué ne devra pas répondre). Autrement dit, notre consommateur ne pourra invoquer que des opérations en InOnly. Pour faciliter cela, l’assistant va filtrer les opérations à afficher en fonction du MEP d’envoi. Dans le cas du composant Mail, seules les opérations du WSDL associée au mode d’envoi InOnly seront affichées dans la liste déroulante.

Enfin, il y a un autre assistant qui a profité de ces améliorations, et c’est celui du composant EIP.
La boite de configuration d’un EIP s’appuie désormais sur des fonctions plus avancées, qui doivent permettre d’aller plus vite en réduisant les erreurs possibles.

Certes, cet assistant risque d’être moins utilisé avec l’éditeur graphique à venir pour les EIP.
Mais c’est une évolution d’appoint appréciable.