Commençons par planter le décor. Il s'agit d'interroger des W-S depuis mon application Flex. Les W-S en question se trouvent être des W-S Java. On s'en fiche me diront certains d'entre vous, Java ou autre, c'est pareil et bien avec Flex Builder rien n'est moins sûr...

Ma démarche est dite bottom-up. Pour faire simple, cela veut dire que je pars d'une API Java existante et que je l'expose en W-S SOAP. Je développe donc l'API en question, et utilise JAX-WS pour en faire des W-S. Ce choix n'est pas innocent, en effet, JAX-WS est l'implémentation de référence JEE pour les W-S. Une fois mes services déployés sur le serveur (Tomcat en l'occurence) je vérifie bien sûr leur fonctionnement. Pour cela, j'utilise tout d'abord "le web service explorer" d'Eclipse et comme ce dernier ne me plaît pas, je me mets en chasse d'un meilleur outil de test de W-S (sans non plus passer par la case plus rude JMeter) et jette mon dévolu sur SOAPUI. Je re-tests mes services et tout va bien, ca fonctionne sans problème.

Je me lance donc dans la réalisation d'une GUI Flex vraiment simple pour mes services. Le but étant surtout de valider l'architecture. Je cherche sur le net des infos sur la consommation de W-S avec Flex. Et là, grosse surprise, il n'y a pratiquement aucun site potable qui traite du sujet. Quand je dis potable, je veux dire : qui comprend ce qu'est un web service SOAP. Et oui, la plupart des sites montrent des exemples de consommation des W-S qui s'appuient sur la capacité de Flex a créer des objets à la volée lors de l'exécution. Le seul gros problème de ce genre de méthode c'est que du coup, les objets n'existent qu'à l'exécution ! Ca devient tout de suite plus dur de développer sans l'aide du compilateur... Surtout qu'on ne sait pas ce que contiennent les objets retournés par les W-S à moins de regarder en mode debug ce qu'il se passe, d'utiliser un proxy pour voir passer les enveloppes SOAP ou pire, de se prendre pour Neo et de lire directement le WSDL !

Il fallait se rendre à l'évidence, l'écrasante majorité des sites traitant de Flex + SOAP sont complètement à côté de la plaque. Certains toutefois, mentionnent l'import de WSDL depuis Flex Builder pour générer les stubs de W-S, mais bizarrement, c'est tout le temps du "HelloWorldService". A croire que personne à réussi à faire fonctionner quoi que ce soit de plus complexe. Mais moi j'ai pas peur, donc me voilà tentant ma chance avec l'outil d'import de Flex Builder. Je lui indique l'emplacement de mon WSDL. Il charge les XSD. Génère les interfaces, les objets métiers, les stubs. Tout est là. Je relie ces stubs à ma GUI et je lance le tout. Résultat : ca ne marche pas :-(

Je me dis : "ok, ca marche avec Eclipse, SOAPUI, mais pas avec Flex Builder". N'ayant pas de Visual Studio sous la main, pas possible de tester avec le client SOAP .NET. Pour trouver la source du problème, je relance le serveur Java en debug mode cette fois et avec un joli breakpoint bien placé. Je re-test, et là, une fois arrêté sur le point d'arrêt, je regarde les paramètres et rien. Juste rien. "null" partout. La grande classe.

Je décide donc d'intercaler un TCP Monitor en frontal du serveur Java pour capturer les enveloppes SOAP envoyées à mon gentil Tomcat. Je test avec Eclipse et SOAPUI et leur message SOAP est en tout point unique. Je test avec l'application Flex et là, oh surprise ! le message SOAP est incorrect et ne suit pas ce qui est décrit par le WSDL (j'ai fais le Neo pour en être sûr :-)).

Là bien sûr, je commence à insulter Flex Builder, normal.

Au detour d'un commentaire dans le code généré, je trouve une petite phrase mentionnant que le code est généré avec Apache Axis 2. J'entends sur mon épaule droite : "non, ne test pas avec Axis 2, tu vas te faire du mal". Ecoutant plutôt le démon sur mon épaule gauche, je test quand même. Et c'est repartit avec Axis 2 : modification du code, génération des W-S, déploiement, restart Tomcat. Je redemande à Flex Builder de générer les stubs, et déjà, je m'aperçois que les classes générées n'ont rien à voir...hum hum...

Je test mes W-S Axis avec Eclipse et SOAPUI, ca marche toujours et je tiens à préciser que les enveloppes SOAP envoyées sont les mêmes que précédemment avec des services JAX-WS. Normal me direz-vous, le code à la source des W-S est le même lui. Je re-test mon application Flex et là, ca marche ! Flex Builder ne sait donc importer que des WSDL servis par Axis 2. -_-"

Pour résumé : Il est aujourd'hui impossible en Flex de consommer (comme il se doit) des web-services SOAP réalisés avec JAX-WS qui est (juste) la norme JEE pour les web-services. C'est moche. Pire ! Il n'est indiqué nul part que Flex Builder ne sait générer du code propre que pour Axis. Bref, j'en veux vraiment à Adobe sur ce coup là. Surtout qu'en cherchant en page 10 et supérieures sur Google, on trouve des "bugs reports" sur le JIRA d'Adobe sur l'import de WSDL qui sont en statut "close" sans aucune justification. C'est pour le moins cavalier. Open source mais pas trop...

Il ne reste que 2 options à ma disposition : Faire du web-service mais devoir utiliser Axis ou faire autre chose que du Web-Service et donc me priver de l'interopérabilité et du typage le plus fort possible.

J'avais déjà rencontrer de sérieux problèmes avec des W-S PHP appelés depuis du Flex, mais je mettais ça sur le compte de PHP (normal :-D). Je commence à me dire que les W-S et Flex ne représentent vraiment pas une solution suffisamment stable pour la production. Si quelqu'un à un feed-back sur l'appel de W-S .NET depuis du Flex, ca m'intéresse.

C'était ma première grosse déception en Flex. Espérons qu'Adobe fera quelques efforts sur l'import de WSDL pour Flex Builder 4 et qu'ils ne s'entêtent pas à privilégier l'utilisation du "remoting" plutôt que les W-S, pour espérer au final vendre plus de Adobe LiveCycle.