Bonnes pratiques WSDL

Question

Je développe une application SOAP qui s’intègre à une tierce partie. Je pense que le WSDL de ce tiers est très étrange. Je suis assez nouveau dans SOAP, alors je ne veux pas leur demander de le réparer s'il n'est pas cassé. Voici certaines choses que j'ai remarquées et que je considère erronées à ce sujet, bien que je sois sûr que ce soit un document techniquement valide (d'où la raison pour laquelle j'ai écrit & "Meilleures pratiques &" Dans le titre). De plus, j'utilise gSOAP comme bibliothèque SOAP, ce qui explique peut-être pourquoi certaines de ces choses sont étranges (je suis encore plus récent sur gSOAP que sur SOAP en général).

1. ils ont des interfaces spécifiées pour SOAP 1.1 et SOAP 1.2 dans le même WSDL. Cela fait que gSOAP génère deux fois plus de classes que nécessaire, car je ne vais utiliser que 1.2.

2. tous leurs espaces de noms sont http://tempuri.org. Cela ne devrait pas être comme ça, non?

3. Bien qu'ils définissent un ensemble d'appels RPC, leur WSDL utilise le format de document. Je pense leur demander de passer au format RPC, car il semble que gSOAP ne génère pas de méthodes utilisant des paramètres de type C ++ pour le format de document. Au lieu de cela, il crée une nouvelle classe pour les données d'entrée et de réponse de chaque fonction API. Si je ne parviens pas à résoudre ce problème, il faudra que j'écrive une autre couche d'encapsulation autour des éléments gSOAP afin de fournir une API raisonnable au reste de mon application. De plus, AFAICT, le code XML qui va être utilisé va être exactement le même qu’il le fait maintenant s’ils passaient à RPC, je ne pense donc pas que ce serait difficile.

Les éléments

4. ont minOccurs = 0; cependant, lorsque je soumets des demandes sans elles, des erreurs sont renvoyées indiquant qu'elles sont obligatoires (parfois même des traces de pile d'exceptions de pointeur nul). Ils doivent les spécifier avec minOccurs = 1 s’ils sont requis, non?

5. presque toutes les fonctions de service Web spécifient une réponse qui comprend un entier indiquant la réussite (réellement un booléen) et une chaîne de message d'erreur. Devraient-ils utiliser les fautes SOAP pour cela? Je pense qu’il serait plus facile pour ma candidature de traiter si c’était une faute, car gSOAP me permettrait de comprendre cela très facilement (et d’imprimer le message d’erreur trivialement).

Bien sûr, je n’espère pas beaucoup que cette société tierce modifiera son WSDL simplement parce que je le lui ai demandé. Au moins, j'apprendrai quelque chose… pour autant que je sache, rien de tout cela n'est faux ni même douteux. Merci pour votre aide.

Answer 1

1 - Ils considèrent probablement cela comme une fonctionnalité. : -)

2 - C'est horrible.

3 - Beaucoup de gens le recommandent. C'est ce qu'on appelle le format enveloppé.

4 - Vous avez raison.

5 - Cela dépend. Théoriquement, vous avez probablement raison, mais dans la pratique, de nombreux toolkits SOAP ne prennent pas très bien en charge les erreurs SOAP. Ils ont donc peut-être délibérément choisi de ne pas utiliser d'exceptions.

Answer 2

J'aimerais être un peu plus général sur les meilleures pratiques pour la création de WSDL:

1. Premier contrat de développement
Contrairement à James, j’insiste beaucoup sur l’utilisation de la méthode Contract-First, car elle permet au développeur d’utiliser toutes les fonctionnalités de XML (restrictions, modèles, ...) et à partir de là, il est assez facile de générer du code pour n'importe quel langage de programmation. Une autre raison est que le schéma dans & Lt; wsdl: types & Gt; est le contrat entre les deux systèmes qui se parlent. Si le développeur crée le WSDL à partir de code, des dépendances techniques sur le langage de programmation spécifique peuvent être introduites (types de données, ...).

2. Style de document / littéral
La validation de SOAP codé en RPC peut être délicate, les requêtes XPATH et les transformations XSLT sont tout simplement impossibles également et ce style est de toute façon déconseillé. RPC / literal pose également des problèmes de validation du code XML (prise en compte de certaines conventions de dénomination) . Certains moteurs SOAP abandonnent les espaces de noms définis par un schéma, ce qui rend leur validation impossible.

À l'aide du style Document / literal, le corps SOAP est entièrement traité en tant que document XML, qui peut être validé, transformé et interrogé de manière standard.

3. Séparation des préoccupations
Séparez la définition de schéma du fichier WSDL lui-même en utilisant & Lt; import .. & Gt; et < include .. > directives. Cela favorise la réutilisation des schémas et la séparation des espaces de noms dans différents fichiers .xsd et réduit également la taille du fichier;)

Answer 3

Cela me semble que le tiers avec lequel vous essayez de vous connecter ne connaît pas non plus les services Web.

D'après votre description, cela semble très typique d'une implémentation de service Web Microsoft ASP.NET, le tiers écrit un peu de VB ou de C # pour interfacer ce qu'il a à offrir, le transmet à un serveur ASP.NET et l'appelle jour, en fonction du moteur ASP.NET pour générer automatiquement le WSDL sur demande.

Vous pouvez leur demander de ne pas fournir les définitions de SOAP 1.1, mais je ne pense pas qu'ils vous aideront, car ils ne savent pas comment. Vous pouvez leur demander pourquoi l’espace de nommage est tempuri.org et je suis sûr que leur réponse ressemblera à & «Nous devrons examiner cela &»; quand ils veulent vraiment le dire & "C'est ?? &"; parce qu'ils ne savent pas pourquoi non plus.

L'espace de noms est contrôlé par une directive du compilateur dans le code et tempuri.org est la valeur par défaut de Microsoft (ne rappelez pas ce qu'il est appelé atm, désolé). Bien sûr, la valeur de l’espace de noms n’a pas beaucoup d’importance (mis à part le fait de paraître bizarre), car elle a simplement pour but de fournir un identificateur de chaîne unique pour la résolution des noms de variables. Peut-être que les autres choses peuvent être contrôlées de la même manière, je ne sais pas, je ne connais pas vraiment les services Web, ASP.NET ou quoi que ce soit, ce n’est pas moi-même un grand fan de technologie.

Answer 4

Rencontrez-le tout à l'heure et trouvez que le préfixe doit être écrit correctement, le préfixe doit être un travail. suivez DEUX soulignements continus 'youtns__methodname "

par exemple

typedef double xsd_double;
int ns__add(xsd_double a, xsd_double b, xsd_double &result);
int ns__sub(xsd_double a, xsd_double b, xsd_double &result);
int myns__sqrt(xsd_double a, xsd_double &result);

cela générera deux fichiers wsdl après avoir exécuté soapcpp2: ns.wsdl et myns.wsdl

Mais est-ce que vous définissez votre méthode comme ceci (un trait de soulignement)

int ns_add(xsd_double a, xsd_double b, xsd_double &result); // wrong 

spapcpp2 ne génèrera rien.

Answer 5

Ce que vous avez rencontré est la paresse typique des tiers lors de la création de leurs services Web. J'imagine que vous n'aurez pas beaucoup de chance à les raisonner, mais vous pouvez modifier le WSDL à la main pour supprimer les définitions 1.1.

Answer 6

Tout d’abord, personne n’écrit réellement WSDL - il est généré par des outils. Les outils de vos fournisseurs insèrent probablement les URL CORRECT pour l’espace de noms et ont probablement des boutons radio disant: V1.0, V1.1, les deux. Le fournisseur possédait probablement du code non SOAP existant et utilisait des outils pour en faire un service SOAP.

Personne n'écrit WSDL, vous ne devriez donc pas le lire! Procurez-vous un ensemble d'outils décent, quelque chose comme SOAPUI décodera le WSDL et vous permettra de le parcourir sans que votre tête explose. C'est Java, mais c'est le meilleur outil de test, quel que soit le langage dans lequel vous codez.

Mon expérience SOA se situe principalement en Java, où vous avez l'embarras du choix en matière de bibliothèques et d'outils. C ++ est probablement moins mature dans ce domaine, mais il semble que le problème réside dans le choix de l'outil plutôt que dans le WSDL. Dans le monde réel, on vous présentera un WSDL moins parfait. Votre outil devrait donc être capable de le gérer de manière raisonnable.