Vir WebSphere Application Server 8.5.5 JAX-WS moet jy twee omliggende beheerpunte nagaan voordat jy op 'n adres in die kliënt se versoekkonteks staatmaak. IBM se JVM-vlak com.ibm.ws.websvcs.transport.enableProxyTunnel is by verstek false; 'n adres per kliënt skakel nie tonneling aan nie. Die HTTP-vervoerwaardes van 'n beleidstel oorheers ook programmatiese waardes, en dié oorheers weer JVM-stelsel-eienskappe.

Vir die gekose bestaande poort dokumenteer IBM hierdie opstelling per kliënt voor die aanroep:

import javax.xml.ws.BindingProvider;

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

Die HTTPS-sleutels geld vir HTTPS-eindpunte; gebruik die ooreenstemmende IBM HTTP-sleutels vir HTTP. 'n Toegelate openbare SOAP-eindpunt kan 'n HTTP-adres uit die HTTP-instaanbedienerlys gebruik net nadat die toepaslike beleid en tonnelbeheer dit toelaat en geen instaanbediener-rekening op daardie vlakke opgestel is nie. Instaanbediener-verifikasie het aparte HTTP/HTTPS proxyUser- en proxyPassword-eienskappe, onafhanklik van SOAP-diensgeloofsbriewe.

Hierdie is WebSphere-uitbreidings. 'n BindingProvider-kaart in Metro, CXF of 'n ander implementering maak daardie stringe nie oordraagbaar nie.

Hou verskillende gelyktydige roetes op behoorlik opgestelde kliëntobjekte eerder as om 'n gedeelde poortkonteks te herskryf terwyl oproepe loop. Só bly die adres beperk tot die werklike kliënt sonder om al sy omliggende JVM-beheerpunte as kliënt-plaaslik te beskou.

Verwante artikels