For WebSphere Application Server 8.5.5 JAX-WS må du kontrollere to omkringliggende styringer før du stoler på en adresse i klientens forespørselskontekst. IBM-egenskapen på JVM-nivå com.ibm.ws.websvcs.transport.enableProxyTunnel er false som standard; en adresse per klient aktiverer ikke tunnellering. HTTP-transportverdiene i et policy-sett overstyrer også programmatiske verdier, og de overstyrer JVM-systemegenskaper.

For den valgte eksisterende porten dokumenterer IBM denne oppsettet per klient før kallet:

import javax.xml.ws.BindingProvider;

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

HTTPS-nøklene gjelder for HTTPS-endepunkter; for HTTP bruker du de tilsvarende IBM HTTP-nøklene. Et tillatt offentlig SOAP-endepunkt kan bruke en HTTP-adresse fra HTTP-proxylisten først når gjeldende policy og tunnellstyringene tillater det, og når det ikke er konfigurert noen proxykonto på disse nivåene. Proxyautentisering har separate HTTP/HTTPS-egenskaper proxyUser og proxyPassword, uavhengig av SOAP-tjenestens påloggingsinformasjon.

Dette er WebSphere-utvidelser. Et BindingProvider-kart i Metro, CXF eller en annen implementasjon gjør ikke disse strengene flyttbare.

Hold ulike samtidige ruter på riktig konfigurerte klientobjekter i stedet for å skrive om en delt portkontekst mens kall kjører. Slik begrenses adressen til den faktiske klienten uten å behandle alle omkringliggende JVM-styringer som klientlokale.

Relaterte artikler