W WebSphere Application Server 8.5.5 JAX-WS sprawdź dwa otaczające mechanizmy, zanim zaufasz adresowi w kontekście żądania klienta. Właściwość IBM na poziomie JVM com.ibm.ws.websvcs.transport.enableProxyTunnel ma domyślnie wartość false; adres dla pojedynczego klienta nie włącza tunelowania. Wartości transportu HTTP w zestawie zasad także nadpisują wartości programowe, a te nadpisują właściwości systemowe JVM.

Dla wybranego istniejącego portu IBM dokumentuje tę konfigurację dla klienta przed wywołaniem:

import javax.xml.ws.BindingProvider;

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

Klucze HTTPS dotyczą punktów końcowych HTTPS; dla HTTP użyj odpowiednich kluczy IBM HTTP. Dozwolony publiczny punkt końcowy SOAP może użyć adresu HTTP z listy proxy HTTP dopiero gdy pozwolą na to odpowiednie zasady i mechanizmy tunelowania oraz gdy na tych poziomach nie skonfigurowano konta proxy. Uwierzytelnianie proxy ma osobne właściwości HTTP/HTTPS proxyUser i proxyPassword, niezależne od poświadczeń usługi SOAP.

To rozszerzenia WebSphere. Mapa BindingProvider w Metro, CXF lub innej implementacji nie czyni tych ciągów przenośnymi.

Utrzymuj różne równoczesne trasy na odpowiednio skonfigurowanych obiektach klienta, zamiast nadpisywać współdzielony kontekst portu podczas trwających wywołań. Dzięki temu adres jest ograniczony do rzeczywistego klienta, a otaczające mechanizmy JVM nie są traktowane jako lokalne dla klienta.

Powiązane artykuły