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.

Publicités

Petals Studio 1.1 releasé. Et maintenant ?

Une nouvelle release

Et bien voilà. Petals Studio 1.1 est disponible.
Bon, ça fait un mois déjà. Mais sa documentation, elle, n’est disponible que depuis la semaine dernière. J’ai eu un peu de mal à la compléter.

Les principales évolutions sont illustrées ici.
Cette version s’inscrit évidemment dans la continuité de ce qui a été fait depuis bientôt 3 ans.

A l’origine, c’est surtout Adrien Louis, alors architecte et formateur sur Petals ESB, qui a poussé l’outillage.
Cela a abouti à la création de plug-ins Eclipse, qui se présentaient uniquement sous la forme d’assistants de création. Le but de ces plug-ins, c’était de faire gagner du temps. Les utilisateurs de Petals étaient censés savoir ce qu’ils faisaient et maitriser tout ce qu’ils touchaient. L’outillage apportait juste un gain de temps.

Évidemment, avec le temps et la multiplication des technologies impliquées dans Petals, les outils ont dû évoluer pour élargir la base d’utilisateurs. Aujourd’hui, il est possible d’appréhender certains composants Petals directement par l’outillage. Pour d’autres par contre, la documentation du composant reste nécessaire. Mais ça évolue, tout doucement. C’est dans ce contexte qu’est sortie la version 1.1 du studio. SCA, JSR-181, XSLT, Validation, sont les principaux composants à bénéficier de simplifications dans cette release.

Et maintenant ?

Si près de 6 mois ont séparé la version 1.0 de la 1.1, la prochaine release du studio est prévue pour la fin de l’année, soit 3 mois d’écart. L’objectif de cette release est de gagner en « productivité ». En clair, il faut corriger certaines lourdeurs.

C’est une nécessité qui est apparue récemment, suite à quelques démonstrations.
Du côté des utilisateurs et de nos consultants, ça n’apparaissait pas comme des points bloquants, mais cela s’est avéré être un obstacle pour certains débutants.

La liste des corrections impératives est courte :

  • Faciliter le choix d’opérations à invoquer (plutôt que de les taper à la main).
  • Créer un éditeur texte avancé pour BPEL (accélérera la correction des erreurs – notamment pour tous les noms qualifiés).
  • Créer un éditeur graphique pour chainer des EIP (le diagramme s’exportera en un lot de projets SU pour EIP).

Et si le temps le permet, d’autres nouveautés suivront. J’en ai déjà implémentées quelques-unes.
Bref, rien de révolutionnaire : on continue sur notre lancée.