Savon WSDL relatif: emplacement de l'adresse

Puis-je avoir le savon:emplacement de l'adresse dans un document 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" />

:

<soap:address location="/axis2/services/ExampleService" />

Cela permettrait d'accélérer le déploiement de plusieurs serveurs, comme les serveurs de test. Aussi, dans le cas de axis2c si je veux que mon service soit utilisé à la fois à partir de l'adresse HTTP ou HTTPS, la vie devient plus difficile pour les développeurs utilisant mon service comme ils ne peuvent pas simplement importer le fichier WSDL à partir de son emplacement par défaut "?WSDL".

source d'informationauteur Mihai

  1. 7

    Le WSDL décrit aux clients les formats de message, les types de paramètres, etc nécessaires pour interagir avec le service web. C'est ensuite utilisé par des outils tels que WSDL2C pour générer le code nécessaire à l'interaction.

    Mais même si vous exposer à votre service sur HTTP ou HTTPS, le stub client code sera le même. Vous n'avez pas de régénérer votre client talons pour chaque adresse de point de terminaison. Le client reste le même, c'est le point d'accès que les changements.

    Cette adresse ne doit pas être codé en dur dans le code client généré, il doit être configurable URL à l'intérieur de l'application client.

    Sûr, vous avez une URL spécifiée dans le fichier WSDL, et c'est une nuisance lorsque vous déployez votre service web dans le serveur de dev, puis à la mise en scène et à côté de la production. Les paramètres seront différents dans chaque environnement (peut-être multiplié par 2 pour HTTP + HTTPS), mais à ce moment, les développeurs ne sont pas affectés parce que vous n'avez pas de régénérer le code.

    Quand il s'agit de l'accès au service web, vous auriez encore des adresses différentes (pour les dev, la mise en scène et les serveurs de prod) même si c'est par rapport à quelque chose ou absolue. Donc je ne vois pas en quoi il est utile d'avoir une adresse relative à l'intérieur de l'WSDL depuis que vous avez encore à gérer les points d'accès dans la configuration du client.

  2. 4

    Il y a deux façons d'obtenir le WSDL.

    Où codé en dur wsdl est servi, par exemple:

    https://hostname/contextname/services/myAPIService/myAPI.wsdl

    et une autre où un wsdl généré est servi, par exemple:

    https://hostname/contextname/services/myAPIService?wsdl

    Si vous utilisez l'option dynamique, il va utiliser ce code:

    req.getRequestURL().toString();

    pour obtenir l'URL qui sera utilisé dans le WSDL généré. Ce code est dans la classe ListingAgent (dans le package org.apache.axis2.de transport.http).

    De ce que vous avez mentionné dans votre question, si vous voulez avoir de la localisation relative, il doit être parce que vous voulez l'utiliser dans de multiples serveurs, de sorte que vous devez utiliser l'option dynamique.

    Un problème que j'ai trouvé avec la dynamique et les options, c'est que si à l'origine, WSDL, l'emplacement est à l'aide de HTTP, puis dans l'généré il sera toujours utiliser HTTP, même si vous avez utilisé le protocole HTTPS pour l'accès. (Ce qui se passe en version 1.5 qui est celui que mon projet est d'utiliser)

    Un autre problème est que si vous utilisez un équilibreur de charge, parce que le WSDL généré sera généré à l'emplacement de la finale serveur au lieu de la balancer. Une option serait d'étendre les classes AxisServlet et ListingAgent pour remplacer le code mentionné ci-dessus.

  3. 3

    Après une longue recherche, je suis presque sûr que soap:address's location attribut doit être une URL absolue. Cela devient plus difficile si vous travaillez avec des environnements différents, tels que le développement, de test et de production.

    Peut-être une solution de contournement serait de lire, sur le côté client, la première partie de l'URL à partir d'un fichier de configuration (par exemple,https://exampleserver.com) et la partie finale du WSDL (par exemple /axis2/services/ExampleService) et de les combiner pour construire un chemin d'accès absolu. L'ancien vous permettra de basculer entre les environnements.