In proxy kieze foar ien WebSphere 8.5.5 JAX-WS-klant
Pas de dokumintearre proxy-eigenskippen fan WebSphere ta op 'e oanfraachkontekst fan 'e JAX-WS-klant ynstee fan it routen fan 'e hiele JVM te feroarjen.
Kontrolearje foar WebSphere Application Server 8.5.5 JAX-WS twa omlizzende kontrôles foardat jo fertrouwe op in adres yn 'e oanfraachkontekst fan 'e klant. De IBM-eigenskip op JVM-nivo com.ibm.ws.websvcs.transport.enableProxyTunnel is standert false; in adres per klant skeakelt gjin tunnel oan. De HTTP-transportwearden fan in beliedsset oerskriuwe ek programmatyske wearden, en dy oerskriuwe JVM-systeemeigenskippen.
Foar de keazen besteande poarte dokumintearret IBM dizze opset per klant foar de oanrop:
import javax.xml.ws.BindingProvider;
BindingProvider binding = (BindingProvider) servicePort;
binding.getRequestContext().put("https.proxyHost", "proxy.example");
binding.getRequestContext().put("https.proxyPort", "8080");De HTTPS-kaaien jilde foar HTTPS-einpunten; brûk foar HTTP de oerienkommende IBM HTTP-kaaien. In tastien iepenbier SOAP-einpunt kin in HTTP-adres út 'e HTTP-proxylist brûke pas neidat it jildende belied en de tunnelkontrôles dat tastean en der op dy nivo's gjin proxy-account konfigurearre is. Proxy-autentikaasje hat aparte HTTP/HTTPS proxyUser- en proxyPassword-eigenskippen, ûnôfhinklik fan 'e SOAP-tsjinstgegevens.
Dit binne WebSphere-útwreidings. In BindingProvider-map yn Metro, CXF of in oare ymplemintaasje makket dy strings net oerdraachber.
Hâld ferskate tagelyk rûtes op goed konfigurearre klantobjekten ynstee fan in dielde poartekontekst te weromskriuwen wylst oproppen rinne. Sa bliuwt it adres beheind ta de werklike klant sûnder alle omlizzende JVM-kontrôles as klantlokaal te beskôgjen.