Discussion :

[rgarnier]

Bonjour,

J'ai une appli delphi client/serveur classique avec laquelle on me demande d'accéder à des services web.

D'après les tests que j'ai pu faire, je dois importer le wsdl correspondant afin de pouvoir invoquer les actions de ce service web.

Ceci me semble hyper restrictif, car :
- si le service web évolue (ajout d'une actio par exemple), je dois recompiler mon appli.
- si je veux invoquer x services web différents, ça va vite devenir ingérable et je dois recompiler.
==> dans ces conditions là, autant appeler une URL avec des paramètres en entrée qui me renverra une grappe de données xml, au moins, si elle évolue, ça continuera à marcher.

N''existe-til pas un moyen d'avoir quelques chose de plus générique ? Puisque le fichier wsdl est disponible et contient l'ensemble des définitions, pourquoi ne pas l'interpréter 'à la volée'.

Bon, ma question me semble tellement évidente que je suppose que je suis passé à côté d'un truc évident aussi.
Merci de votre aide

[ShaiLeTroll]

Tu ne prendrais le problème à l'envers ?

Si tu utilises l'import de WSDL c'est justement pour un code robuste et statique !

Personnellement, quand je peux le faire, je réalise un Wrapper (DLL Win32 ou DLL COM selon l'humeur), cette DLL est mis en sur le site contenant le WebService (si j'en suis l'auteur ou un de mes collègues), ainsi, avant d'appeler le WebService, le programme demande à la DLL si il existe une version plus récente, je télécharge la DLL (en HTTP), et je la lance, ainsi je suis à jour quoi qu'il arrive, ... le seul problème c'est si les paramètres changent radicalement, ... j'avais pondu un petit système de version pour vérifier si les clients étaient compatible, si il ne l'était pas, cela proposait à l'utilisateur, l'abandon de l'appel et\ou le téléchargement, d'un nouvel exe complet (compatible avec la nouvelle DLL), plus l'application est modulaire, moins les changements sont difficiles, il faut parcontre bosser sur les systèmes de déploiment

En pratique, je n'ai pas le temps, j'importe une fois directement dans le programme, et lorsqu'il y a des modifications, je refait un import, et je recopie les changements dans l'unité de origine que je refonds de A à Z en général (suppression des URL constantes, encapsulation, ancêtre abstrait et polymorphisme pour des webservices similaires mais subtilement différent)

Par contre, que ce soit bien fait avec Wrapper ou directement dans l'Exe, la quantité de code à modifier est la même (voire plus importante avec le Wrapper car il faut parfois refaire les prototypes, j'utilise des paramètres tableau variant pour simplifier les appels à la façon PHP4 NuSOAP)

Sinon, je n'ai jamais pris le temps de faire un truc générique car ce que je recherchais était la simplicité de Code et la robutesse d'appel, puisque l'import d'un WSDL justement te permet d'avoir une interface qui permet d'avoir justement une robutesse dans l'application... mais cela serait très interessant, d'avoir un composant qui fourni un appel dynamique, en théorie ce n'est que du XML pour le SOAP, donc un script devrait être capable de générer le XML et d'envoyer à la sauvage via le TRIOHTTP

Et donc on en revient que le statique ne fonctionne pas, ce n'est pas un import qu'il faut faire mais une lecture via un IWSDLDocument ou TWSDLItems, à partir du quel tu reconstitue le XML SOAP attendu ...

[rgarnier]

Ok, merci pour tes infos.

Je vais me pencher sur le sujet, mais j'avoue être surpris que personne n'ai remonté cette problématique.