Prüfen Sie bei WebSphere Application Server 8.5.5 JAX-WS zwei umgebende Steuerungen, bevor Sie sich auf eine Adresse im Anforderungskontext des Clients verlassen. Die IBM-Eigenschaft auf JVM-Ebene com.ibm.ws.websvcs.transport.enableProxyTunnel ist standardmäßig false; eine Adresse pro Client aktiviert kein Tunneling. Die HTTP-Transportwerte eines Policy-Sets überschreiben außerdem programmatische Werte, und diese überschreiben JVM-Systemeigenschaften.

Für den ausgewählten vorhandenen Port dokumentiert IBM diese clientbezogene Einrichtung vor dem Aufruf:

import javax.xml.ws.BindingProvider;

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

Die HTTPS-Schlüssel gelten für HTTPS-Endpunkte; verwenden Sie für HTTP die entsprechenden IBM-HTTP-Schlüssel. Ein zulässiger öffentlicher SOAP-Endpunkt kann eine HTTP-Adresse aus der HTTP-Proxy-Liste erst dann nutzen, wenn die geltende Policy und die Tunneling-Steuerungen es erlauben und auf diesen Ebenen kein Proxy-Konto konfiguriert ist. Die Proxy-Authentifizierung hat separate HTTP/HTTPS-Eigenschaften proxyUser und proxyPassword, unabhängig von den Anmeldedaten des SOAP-Dienstes.

Dies sind WebSphere-Erweiterungen. Eine BindingProvider-Map in Metro, CXF oder einer anderen Implementierung macht diese Zeichenfolgen nicht übertragbar.

Halten Sie verschiedene gleichzeitige Routen auf ordnungsgemäß konfigurierten Client-Objekten, statt einen gemeinsam genutzten Port-Kontext während laufender Aufrufe umzuschreiben. So bleibt die Adresse auf den tatsächlichen Client beschränkt, ohne alle umgebenden JVM-Steuerungen als clientlokal zu behandeln.

Ähnliche Artikel