Choisir un proxy pour un client WebSphere 8.5.5 JAX-WS

Pour WebSphere Application Server 8.5.5 JAX-WS, vérifiez deux contrôles environnants avant de vous fier à une adresse du contexte de requête du client. La propriété IBM au niveau JVM com.ibm.ws.websvcs.transport.enableProxyTunnel vaut false par défaut ; une adresse par client n'active pas le tunnel. Les valeurs de transport HTTP d'un jeu de politiques remplacent aussi les valeurs programmatiques, et celles-ci remplacent les propriétés système de la JVM.

Pour le port existant choisi, IBM documente cette configuration par client avant l'appel :

import javax.xml.ws.BindingProvider;

BindingProvider binding = (BindingProvider) servicePort;
binding.getRequestContext().put("https.proxyHost", "proxy.example");
binding.getRequestContext().put("https.proxyPort", "8080");

Les clés HTTPS s'appliquent aux points de terminaison HTTPS ; pour HTTP, utilisez les clés IBM HTTP correspondantes. Un point de terminaison SOAP public autorisé ne peut utiliser une adresse HTTP de la liste de proxys HTTP qu'après que la politique applicable et les contrôles de tunnel l'autorisent et qu'aucun compte proxy n'est configuré à ces niveaux. L'authentification proxy dispose de propriétés HTTP/HTTPS proxyUser et proxyPassword distinctes, indépendantes des identifiants du service SOAP.

Ce sont des extensions WebSphere. Une table BindingProvider dans Metro, CXF ou une autre implémentation ne rend pas ces chaînes portables.

Gardez les différentes routes simultanées sur des objets clients correctement configurés au lieu de réécrire un contexte de port partagé pendant que des appels s'exécutent. L'adresse reste ainsi limitée au client réel, sans traiter tous les contrôles JVM environnants comme locaux au client.