Kwa WebSphere Application Server 8.5.5 JAX-WS, angalia vidhibiti viwili vinavyozunguka kabla ya kutegemea anwani iliyo katika muktadha wa ombi la mteja. Sifa ya IBM katika ngazi ya JVM com.ibm.ws.websvcs.transport.enableProxyTunnel ni false kwa chaguo-msingi; anwani kwa kila mteja haiwezeshi handaki. Thamani za usafirishaji wa HTTP za seti ya sera pia hupitisha thamani za programu, na hizo hupitisha sifa za mfumo wa JVM.

Kwa bandari iliyopo iliyochaguliwa, IBM inaandika usanidi huu kwa kila mteja kabla ya wito:

import javax.xml.ws.BindingProvider;

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

Funguo za HTTPS zinatumika kwa vituo vya mwisho vya HTTPS; kwa HTTP tumia funguo za IBM HTTP zinazolingana. Kituo cha mwisho cha SOAP cha umma kilichoruhusiwa kinaweza kutumia anwani ya HTTP kutoka orodha ya proksi za HTTP tu baada ya sera inayotumika na vidhibiti vya handaki kuruhusu na ikiwa hakuna akaunti ya proksi iliyosanidiwa katika ngazi hizo. Uthibitishaji wa proksi una sifa tofauti za HTTP/HTTPS proxyUser na proxyPassword, zisizotegemea vitambulisho vya huduma ya SOAP.

Hizi ni viendelezi vya WebSphere. Ramani ya BindingProvider katika Metro, CXF au utekelezaji mwingine haifanyi nyuzi hizo kuwa zinazoweza kuhamishwa.

Weka njia tofauti za wakati mmoja kwenye vitu vya mteja vilivyosanidiwa ipasavyo badala ya kuandika upya muktadha wa bandari inayoshirikiwa wakati wito unaendelea. Hii huweka anwani kwa mteja halisi bila kuchukua vidhibiti vyote vya JVM vinavyozunguka kama vya ndani kwa mteja.

Makala zinazohusiana