Savon WSDL relatif: emplacement de l'adresse
Puis-je avoir l'emplacement soap: address dans un WSDL par rapport à l'emplacement WSDL, ou au moins par rapport au serveur? Par exemple, je veux écrire:
<soap:address location="https://exampleserver.com/axis2/services/ExampleService" />
comme:
<soap:address location="/axis2/services/ExampleService" />
Cela permettrait un déploiement plus rapide sur plusieurs serveurs, comme les serveurs de test. De plus, dans le cas de axis2c si je veux que mon service soit utilisé à la fois depuis HTTP ou HTTPS, la vie devient plus difficile pour les développeurs utilisant mon service car ils ne peuvent pas simplement importer le WSDL depuis son emplacement par défaut "? WSDL".
Le WSDL décrit aux clients les formats de message, les types, les paramètres, etc. nécessaires pour interagir avec le service Web. Ceci est ensuite utilisé par des outils comme WSDL2C pour générer le code nécessaire à l'interaction.
Mais même si vous exposez votre service sur HTTP ou HTTPS, le code de stub client sera le même. Vous ne régénérez pas vos talons client pour chaque adresse de point de terminaison . Le client reste le même, c'est le point d'accès qui change.
Cette adresse ne doit pas être codée en dur dans le code client généré, elle doit être une URL configurable à l'intérieur de l'application cliente.
Bien sûr, vous avez une URL spécifiée à l'intérieur du WSDL et c'est une nuisance lorsque vous déployez votre service Web dans le serveur de développement, puis à la mise en scène et ensuite en production. Les points de terminaison seront différents dans chaque environnement (peut-être multipliés par 2 pour HTTP + HTTPS) mais à ce stade, vos développeurs ne sont pas affectés car vous ne régénérez pas le code.
En ce qui concerne l'accès au service Web, vous auriez toujours des adresses différentes (pour les serveurs de développement, de transfert et de production) même si elles étaient relatives à quelque chose ou absolues. Je ne vois donc pas en quoi il est utile d'avoir une adresse relative à l'intérieur du WSDL car vous devez toujours gérer les points d'accès dans la configuration du client.
Il existe deux façons d'obtenir le WSDL.
Celui où un wsdl codé en dur est servi, par exemple:
https://hostname/contextname/services/myAPIService/myAPI.wsdl
et un autre où un wsdl généré est servi, par exemple:
https://hostname/contextname/services/myAPIService?wsdl
Si vous utilisez l'option dynamique, elle utilisera ce code:
req.getRequestURL().toString();
pour obtenir l'URL qui sera utilisée dans le WSDL généré. Ce code est dans la classe ListingAgent (dans le package org.Apache.axis2.transport.http).
D'après ce que vous avez mentionné dans votre question, si vous voulez avoir un emplacement relatif, cela doit être parce que vous souhaitez l'utiliser sur plusieurs serveurs, vous devez donc utiliser l'option dynamique.
Un problème que j'ai trouvé avec les options dynamiques est que si dans le WSDL d'origine l'emplacement utilise HTTP, alors dans celui généré, il utilisera toujours HTTP même si vous avez utilisé HTTPS pour y accéder. (Cela se produit dans la version 1.5 qui est celle que mon projet utilise)
Un autre problème est si vous utilisez un équilibreur de charge, car le WSDL généré sera généré avec l'emplacement du serveur final au lieu de l'équilibreur. Une option pour cela serait d'étendre les classes AxisServlet et ListingAgent pour remplacer le code mentionné ci-dessus.
Après une longue recherche, je suis presque sûr que l'attribut location de soap:address Doit être une URL absolue. Cela complique les choses si vous travaillez avec différents environnements, tels que le développement, les tests et la production.
Une solution de contournement serait peut-être de lire, côté client, la première partie de l'URL d'un fichier de configuration (par exemple https://exampleserver.com) Et la dernière partie du WSDL (par exemple /axis2/services/ExampleService) Et de combiner eux pour construire un chemin absolu. Le premier vous permettra de basculer entre les environnements.