En WebSphere Application Server 8.5.5 JAX-WS comprobe dous controis da contorna antes de confiar nun enderezo do contexto de solicitude do cliente. A propiedade de IBM a nivel de JVM com.ibm.ws.websvcs.transport.enableProxyTunnel vale false por defecto; un enderezo por cliente non activa o túnel. Os valores de transporte HTTP dun conxunto de políticas tamén anulan os valores programáticos, e estes anulan as propiedades do sistema JVM.

Para o porto existente seleccionado, IBM documenta esta configuración por cliente antes da invocación:

import javax.xml.ws.BindingProvider;

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

As claves HTTPS aplícanse aos extremos HTTPS; para HTTP use as claves IBM HTTP correspondentes. Un extremo SOAP público permitido pode usar un enderezo HTTP da lista de proxies HTTP só despois de que a política aplicable e os controis de túnel o permitan e de que non haxa ningunha conta de proxy configurada neses niveis. A autenticación do proxy ten propiedades HTTP/HTTPS proxyUser e proxyPassword separadas, independentes das credenciais do servizo SOAP.

Estas son extensións de WebSphere. Un mapa de BindingProvider en Metro, CXF ou outra implementación non fai portables esas cadeas.

Manteña as distintas rutas simultáneas en obxectos de cliente configurados axeitadamente en lugar de reescribir un contexto de porto compartido mentres hai chamadas en curso. Así o enderezo queda limitado ao cliente real sen tratar todos os controis JVM da súa contorna como locais ao cliente.

Artigos relacionados