Выбар проксі для аднаго кліента WebSphere 8.5.5 JAX-WS

Для WebSphere Application Server 8.5.5 JAX-WS праверце два знешнія сродкі кіравання, перш чым спадзявацца на адрас у кантэксце запыту кліента. Уласцівасць IBM узроўню JVM com.ibm.ws.websvcs.transport.enableProxyTunnel па змаўчанні мае значэнне false; адрас для асобнага кліента не ўключае тунеляванне. Значэнні HTTP-транспарту набору палітык таксама перавышаюць праграмныя значэнні, а тыя перавышаюць сістэмныя ўласцівасці JVM.

Для выбранага існуючага порта IBM дакументуе такую наладку для асобнага кліента перад выклікам:

import javax.xml.ws.BindingProvider;

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

Ключы HTTPS дзейнічаюць для канцавых пунктаў HTTPS; для HTTP выкарыстоўвайце адпаведныя ключы IBM HTTP. Дапушчаны публічны канцавы пункт SOAP можа выкарыстоўваць адрас HTTP са спісу проксі HTTP толькі пасля таго, як адпаведная палітыка і сродкі кіравання тунеляваннем гэта дазволяць і на гэтых узроўнях не наладжаны ўліковы запіс проксі. Аўтэнтыфікацыя проксі мае асобныя ўласцівасці HTTP/HTTPS proxyUser і proxyPassword, незалежныя ад уліковых даных службы SOAP.

Гэта пашырэнні WebSphere. Мапа BindingProvider у Metro, CXF або іншай рэалізацыі не робіць гэтыя радкі пераноснымі.

Трымайце розныя адначасовыя маршруты на належна наладжаных аб'ектах кліента, а не перапісвайце агульны кантэкст порта, пакуль ідуць выклікі. Так адрас абмяжоўваецца фактычным кліентам, і акаляльныя сродкі кіравання JVM не лічацца лакальнымі для кліента.