Triar un proxy per a un client JAX-WS de WebSphere 8.5.5

Per a WebSphere Application Server 8.5.5 JAX-WS, comproveu dos controls de l'entorn abans de confiar en una adreça del context de petició del client. La propietat d'IBM a nivell de JVM com.ibm.ws.websvcs.transport.enableProxyTunnel val false per defecte; una adreça per client no activa el túnel. Els valors de transport HTTP d'un conjunt de polítiques també anul·len els valors programàtics, i aquests anul·len les propietats del sistema JVM.

Per al port existent seleccionat, IBM documenta aquesta configuració per client abans de la invocació:

import javax.xml.ws.BindingProvider;

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

Les claus HTTPS s'apliquen als punts de connexió HTTPS; per a HTTP feu servir les claus IBM HTTP corresponents. Un punt de connexió SOAP públic permès pot usar una adreça HTTP de la llista de proxys HTTP només després que la política aplicable i els controls de túnel ho permetin i que no hi hagi cap compte de proxy configurat en aquests nivells. L'autenticació del proxy té propietats HTTP/HTTPS proxyUser i proxyPassword separades, independents de les credencials del servei SOAP.

Aquestes són extensions de WebSphere. Un mapa de BindingProvider a Metro, CXF o una altra implementació no fa portables aquestes cadenes.

Mantingueu les rutes concurrents diferents en objectes de client configurats adequadament en lloc de reescriure un context de port compartit mentre hi ha crides en curs. Així l'adreça queda limitada al client real sense tractar tots els controls JVM del seu entorn com a locals del client.