Cette page sert de fil de discussion au sujet de la roadmap du studio.
Cela évitera aussi des échanges de mails intempestifs. Une fois cette page finalisée, les tâches retenues seront rajoutées dans JIRA.
Attention ! Certaines tâches sont déjà dans JIRA.

Cible : Petals Studio 1.3.0
Sortie probable : Janvier 2012 (liée à la sortie de Petals v4)

Tâches impératives

Intégration avec m2eclipse

• Enregistrer les artéfacts Maven de Petals dans m2eclipse.
  Il y a un point d'extension pour ça, mais il est buggué pour les contributions locales. => Patch ou contribution disponible sur un serveur HTTP.
• Revoir les wizards de création des composants et des SL pour utiliser m2eclipse.
  Ces wizards seront un raccourci plus convivial que celui de m2eclipse.
• Revoir les wizards de SU Java pour qu'elles s'appuient sur m2eclipse.
  Notamment, les POJO, JSR-181 et SOAP avec WS-Security.
• Revoir le packaging des projets Java pour les SU, composants et SL. Passer par m2eclipse (qui sera capable de filtrer les librairies de tests, contrairement au packaging actuel qui embarque toutes les librairies dans l'archive finale).

Mise à niveau des wizards pour les nouvelles versions de composant

Cela consiste à enregistrer les nouvelles versions des composants Petals, ainsi que leurs paramètres, dans le studio.
Prévoir une réunion avec l'équipe SCRUM en septembre sur le sujet pour se synchroniser.

Nouvelle interface graphique dans le BPEL Designer

• Ajouter un point d'extension dans le BPEL Designer pour rajouter des pages dans l'éditeur BPEL.
• Ajouter une page pour les partner links.
• Ajouter une nouvelle page pour définir la structure d'exécution du processus.

Cela consiste à implémenter ce qui a été décrit dans ce document.

Mise à niveau de la validation BPEL (Eclipse)

Vérifier qu'Eclipse valide convenablement des processus BPEL.
Calculer un delta entre ce que donne le validateur Eclipse et EasyBPEL.
Déterminer si garder EasyBPEL dans le studio est encore pertinent et agir en conséquence.

Si EasyBPEL doit être conservé, estimer si cela relève des besoins R&D ou produits.
Et essayer alors d'aligner EasyBPEL sur la version d'EasyWSDL à embarquer (voir plus haut).

XSLT Graphique

• Créer un widget qui permet d'associer des éléments XML à d'autres éléments XML (même si XSLT permet de faire du XML vers autre chose - exemple : du CSV).
• Essayer de définir un modèle générique d'arbre.
• Fournir une extension du modèle pour les entrées / sorties suivantes : fichier XML, document DOM, schéma XML (fichier XSD), schéma de l'opération d'un WSDL (1.1 pour le moment).
• EasyWSDL et EasySchema semblent de bonnes bases pour les XSD et WSDL. Vérifier la compatibilité des licences.

• A terme, cet outil est censé être proposé dans la Fondation Eclipse. Il n'est pas question de proposer un outil s'appuyant sur des librairies qui sortent du chapeau. Il faudra donc :
  • Mettre à jour le site de EasyWSDL chez OW2.
  • Mettre à jour le wiki sur EasyWSDL & co chez Petals Link.
  • Mettre en ligne, sur developpez.com par exemple, un (ou des) tutoriel(s) qui montre(nt) l'utilisation de EasySchema et EasyWSDL.

• Créer un assistant pour la création de XSLT, s'appuyant sur le coeur précédemment défini.
• Réutiliser le coeur précédent dans le BPEL Designer pour définir les mappings entre variables (assignations).

Intégration avec les serveurs Petals

• Supprimer les librairies du plugin *.server.
• Les remplacer par celles de l'API JMX de Petals.
• Mettre à niveau les interactions entre Eclipse et un serveur Petals.
• Rajouter ce qu'il faut pour pouvoir déployer des projets composants, SL, SU, SA sur un serveur Petals depuis le studio.

Internationalisation des plugins / features

Assurer l'internationalisation des plugins, des features et du RCP.
Proposer une traduction en français (Laurent est prêt à aider).
Rajouter le changement de langue dans un menu.

Automatisation des tests

Rajouter des tests SWT Bot pour tester tous les wizards du studio (SA, Composant, SL, tous les assistants SU).
Un plug-in de test par plugin, y compris pour les plug-ins des composants (*.services.bpel --> *.services.bpel.test).

Tâches expérimentales / réflexion

Construire graphiquement des chaînes d'intégration Petals

Solution alternative aux wizards pour les SU. Un peu similaire à l'éditeur EIP dans le principe.

On a une palette avec des composants Petals. Et on pose ces composants sur une zone de dessin. On relie les composants entre eux, les liens définissant des relations de fournisseur / consommateur. Chaque composant a des propriétés, qui définissent ce qui sera placé dans les SU de ces composants. Enfin, on peut définir à la volée et graphiquement des transformations XSL, en utilisant ce qui le coeur défini plus haut.

Le diagramme validé, on peut l'exporter soit en une série de projets Petals et Maven (intégration continue avec le plug-in Maven de Petals), soit une ou plusieurs SA.

Outils de tests des composants

• Développement de composants prévus pour le consulting. => Besoin impératif d'une solution de tests efficace.
• Après réflexion, le kernel en mémoire n'est pas prêt d'arriver, ou pas assez tôt en tout cas. => Tests ad-hoc à la compilation. On lance un Petals et on exécute des scénarios dessus.

• Si le scénario n'est que l'envoi de messages à un service donné, on peut étudier la possibilité d'éténdre les plug-ins Eclipse de SoapUI.
  • Contrainte : il faut tout déployer à la main avant.
  • SoapUI en lui-même est extensible (et LGPL). Je ne sais pas ce qu'il en est des plug-ins Eclipse. Au pire, patch + contribution.
  • L'extension de SoapUI lui-même ne concerne pas le studio... mais pourrait être implémentée (stagiaire ?).

• Sinon, il faut regarder quel outil peut être créé pour définir des scénarios plus élaborés.
  • Une partie Java pour des assertions et des utilitaires pour construire des scénarios : PetalsServiceTestCase extends XMLTestCase
  • Une partie avec des fichiers XML qui contiennent les propriétés des échanges à envoyer (payload, attachements, propriétés). Format pivot.
  • Un éditeur de type formulaire pour créer / éditer ces fichiers XML.
  • Dans la mesure où ce type de scénario peut nécessiter des déploiements ou des changements de cycle de vie, la librairie JMX de Petals sera nécessaire. On pourra envisager d'utiliser les tâches ANT de Petals. On peut utiliser ces tâches dans un script mais les librairies s'utilisent aussi directement en Java. Ainsi, on mutualisera du code.

Ensemble de modeleurs pour l'architecture

Ces modeleurs, ou ce modeleur avec plusieurs vues, pourra être utilisé par plusieurs types d'utilisateurs :

• Consultants.
• Architectes.
• Avant-vente.
• Toute personne amenée à travailler sur l'exploitation pour comprendre l'architecture.

Un méta-modèle commun

Ce méta-modèle est fait de 3 parties :

• Une partie topologie qui reprend exactement le schéma XML de la topologie de Petals.
• Une partie tableau blanc : sur notre topologie, on peut avoir des consommateurs et des providers virtuels, cad que l'on a placé sur notre schéma que pour raisonner. Cela correspond au premier modeleur.
• Une partie déploiement explicite, qui va permettre de définir les composants, SL, dépendances entre composants et SL, SA à déployer sur chacun des noeuds de la topologie.
• Une partie éléments externes, où l'on définit des disques, des applications, des services, des ressources externes et des load balancers.

Archi-Sketcher : un modeleur pour discuter et présenter des solutions d'architecture avec Petals

Avec cet éditeur, basé sur une partie du méta-modèle décrit précédemment, le but est de pouvoir présenter et discuter des architectures possibles avec Petals ESB.
Cet éditeur s'adresse aux consultants, architectes et équipes pour partager une vue commune en groupe. Typiquement, elle s'utiliserait avec un rétro-projecteur (cas consulting déjà rencontrés plusieurs fois).

Sur ce modeleur, on place des serveurs, puis des noeuds Petals que l'on répartit sur les serveurs.
On peut également faire apparaître des load balancers, qu'ils soient hardware (alteon & co.) ou software (Apache Mod Proxy Balancer...), des disques durs, potentiellement partagés, des bases de données (MySQL, Postgre, Oracle...), des serveurs d'applications (services Web, EJB...) ou encore des applications.

Ces éléments définissent une vue globale de l'architecture.
Dans un premier temps, on considère qu'un seul niveau devrait suffire pour tout décrire, mais dans la pratique, il faudra peut-être découper l'archi en plusieurs diagrammes ou prévoir plus tard des mécanismes d'introspection.

L'architecture en elle-même est sauvegardée en dur.
On peut ensuite rajouter dessus des éléments d'explication. Ainsi, on peut placer des consommateurs et des fournisseurs de services sur les noeuds. On différenciera des consommateurs (resp. fournisseurs) entre eux par des jeux de couleur. Un fournisseur que l'on répliquerait sur plusieurs noeuds n'aurait donc qu'une seule couleur. Le but n'est pas de présenter tous les fournisseurs / consommateurs de l'archi. Il s'agît au contraire de pouvoir expliquer pour un cas d'usage donné comment cela va fonctionner dans le bus.

Les derniers fournisseurs / consommateurs peuvent être sauvegardées dans le fichier.
Enfin, on peut vouloir dessiner des interactions entre fournisseurs et consommateurs, à l'aide de flèches.
Le modeleur fournira 2 boutons, un pour effacer juste les flèches, et un pour également dessiner les fournisseurs / consommateurs.

Exemple :

• Topologie de 4 noeuds, répartis sur 2 serveurs.
• 2 noeuds sont spécialisés pour accueillir les SU consumes, un par serveur. Idem pour les providers.
• On place un load balancer Apache en frontal des 2 noeuds consommateurs.
• On place un load balancer hardware entre les noeuds du bus.
• On place 2 serveurs d'appli (JBoss + WLS) en-dehors du bus.
• On place un load balancer hardware entre Petals (noeuds provider) et les 2 serveurs d'application.

• On ajoute ensuite un même consommateur (couleur : bleu) sur chacun des noeuds consommateurs.
• On met un même provider (couleur : orange) sur chacun des noeuds providers.
• On relie les providers au load balancer qui fait l'interface avec les serveurs d'appli. On relie aussi les consommateurs au load balancer Apache.

• Enfin, on décide d'expliquer, à l'aide de flèches, le cheminement possible de messages qui viendrait du load balancer Apache jusqu'à l'un des services déployés sur un serveur d'application.

Un tel éditeur sert juste à expliquer et présenter ce qu'il est possible de faire avec Petals.
Pour le consulting, cela me semble vraiment utile et plus simple qu'un bout de papier que l'on va gribouiller 50 fois (surtout quand on est plus de 4 autour de la table).

Un modeleur de topologie

Le modeleur de topologie peut partir d'un document vierge ou d'une instance du méta-modèle créé avec le modeleur précédent.
Il s'agît de rajouter les éléments nécessaires pour arriver à un fichier topology.xml complet pour Petals 3.
En sortie de ce modeleur, on est capable de générer un fichier de topologie pour toute un jeu de noeuds Petals.

Un modeleur de déploiement

Le dernier modeleur ne peut partir que d'une instance du modeleur de topologie.
Il s'agît de placer les composants, SL et SA à déployer sur tel ou tel noeud.
Pour chaque composant ou SL, on donnera la version et éventuellement l'ID (le nom) de l'artéfact.
On spécifiera aussi les dépendances entre composants et SL.
Enfin, on donnera le nom des SU et/ou SA à déployer sur tel ou tel noeud.

Le modeleur pourra signaler lorsqu'il manque des composants / SL et également mettre en valeur les éléments superflus.
De plus, il pourra vérifier qu'aucun conflit ne résultera de ce déploiement.
A la fin, on devrait être capable d'exporter ce diagramme vers un descripteur de déploiement d'une topologie. Avec un outil adapté, on pourrait ainsi automatiser le déploiement complet d'une architecture Petals.

Compléments

Chaque modeleur fournit un système de validation (unicité du nom du conteneur dans la topologie, présence d'un noeud maitre, pas de conflit de nom pour les artéfatcs de déploiement...).

Le méta-modèle est clairement associé à Petals ESB 3.x. Une mention explicite de petals-3x sera faite dans le namespace du méta-modèle.
Ce méta-modèle sera également versionné. Cette version apparaîtra aussi dans le namespace du méta-modèle. Cela permettra de le faire évoluer pour d'autres versions de l'outillage.

Lacunes

Actuellement, il n'est pas évident dans Petals de lier les artéfacts de déploiement avec les aspects fonctionnels.
Ainsi, il est difficile de déterminer les relations fournisseurs / providers depuis un modèle de déploiement (que contient la SA, que contient la SU...).
Dans l'attente d'une meilleure idée, ce lien ne sera pas traité par ces modeleurs.

Build d'installeurs

Mettre à jour le build pour :

• Créer un .deb ou .rpm pour Linux.
• Créer un installeur sous Windows.
• Créer un DMG pour Mac.

Pour plus tard...

Renommer les plugins / features / product

com.ebmwebsourcing.petals.* ==> org.ow2.petals.studio.*
Attention aux natures, builders, vues et perspectives !
Il faudra peut-être forcer une réinitialisation des perspectives au premier démarrage pour le prochain studio.

Assistant pour WS-Security

Rajouter une action pour générer et enregistrer des handlers WSS dans une SU SOAP.