Per WebSphere Application Server 8.5.5 JAX-WS controllare due controlli circostanti prima di affidarsi a un indirizzo nel contesto della richiesta del client. La proprietà IBM a livello di JVM com.ibm.ws.websvcs.transport.enableProxyTunnel è false per impostazione predefinita; un indirizzo per client non abilita il tunneling. I valori di trasporto HTTP di un set di policy sovrascrivono anche i valori programmatici, e questi sovrascrivono le proprietà di sistema della JVM.

Per la porta esistente selezionata, IBM documenta questa configurazione per client prima della chiamata:

import javax.xml.ws.BindingProvider;

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

Le chiavi HTTPS si applicano agli endpoint HTTPS; per HTTP usare le chiavi IBM HTTP corrispondenti. Un endpoint SOAP pubblico consentito può usare un indirizzo HTTP dal elenco di proxy HTTP solo dopo che la policy applicabile e i controlli del tunnel lo consentono e se a quei livelli non è configurato alcun account proxy. L'autenticazione proxy dispone di proprietà HTTP/HTTPS proxyUser e proxyPassword separate, indipendenti dalle credenziali del servizio SOAP.

Queste sono estensioni WebSphere. Una mappa BindingProvider in Metro, CXF o un'altra implementazione non rende portatili quelle stringhe.

Mantenere le diverse rotte concorrenti su oggetti client configurati in modo appropriato invece di riscrivere un contesto di porta condiviso mentre le chiamate sono in corso. Così l'indirizzo resta limitato al client effettivo senza considerare tutti i controlli JVM circostanti come locali al client.

Articoli correlati