No WebSphere Application Server 8.5.5 JAX-WS, verifique dois controlos envolventes antes de confiar num endereço no contexto de pedido do cliente. A propriedade IBM ao nível da JVM com.ibm.ws.websvcs.transport.enableProxyTunnel é false por omissão; um endereço por cliente não ativa o túnel. Os valores de transporte HTTP de um conjunto de políticas também substituem os valores programáticos, e estes substituem as propriedades de sistema da JVM.

Para a porta existente selecionada, a IBM documenta esta configuração por cliente antes da invocação:

import javax.xml.ws.BindingProvider;

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

As chaves HTTPS aplicam-se aos pontos finais HTTPS; para HTTP use as chaves IBM HTTP correspondentes. Um ponto final SOAP público autorizado só pode usar um endereço HTTP da lista de proxies HTTP depois de a política aplicável e os controlos de túnel o permitirem e de não haver nenhuma conta de proxy configurada nesses níveis. A autenticação do proxy tem propriedades HTTP/HTTPS proxyUser e proxyPassword separadas, independentes das credenciais do serviço SOAP.

Estas são extensões do WebSphere. Um mapa BindingProvider em Metro, CXF ou noutra implementação não torna essas cadeias portáveis.

Mantenha as diferentes rotas simultâneas em objetos de cliente configurados adequadamente em vez de reescrever um contexto de porta partilhado enquanto decorrem chamadas. Assim o endereço fica limitado ao cliente real sem tratar todos os controlos da JVM em seu redor como locais ao cliente.

Artigos relacionados