একটি WebSphere 8.5.5 JAX-WS ক্লায়েন্টের জন্য প্রক্সি নির্বাচন
পুরো JVM-এর রাউটিং বদলানোর বদলে WebSphere-এর নথিভুক্ত প্রক্সি বৈশিষ্ট্যগুলো JAX-WS ক্লায়েন্টের অনুরোধ প্রসঙ্গে প্রয়োগ করুন।
WebSphere Application Server 8.5.5 JAX-WS-এর ক্ষেত্রে ক্লায়েন্টের অনুরোধ প্রসঙ্গের কোনো ঠিকানার উপর নির্ভর করার আগে দুটি পারিপার্শ্বিক নিয়ন্ত্রণ যাচাই করুন। IBM-এর JVM-স্তরের com.ibm.ws.websvcs.transport.enableProxyTunnel ডিফল্টে false; প্রতিটি ক্লায়েন্টের জন্য আলাদা ঠিকানা টানেলিং চালু করে না। পলিসি সেটের HTTP পরিবহন মান প্রোগ্রামেটিক মানকেও অগ্রাহ্য করে, আর সেগুলো JVM সিস্টেম প্রপার্টিকেও অগ্রাহ্য করে।
নির্বাচিত বিদ্যমান পোর্টের জন্য IBM কল করার আগে এই ক্লায়েন্টভিত্তিক সেটআপ নথিভুক্ত করেছে:
import javax.xml.ws.BindingProvider;
BindingProvider binding = (BindingProvider) servicePort;
binding.getRequestContext().put("https.proxyHost", "proxy.example");
binding.getRequestContext().put("https.proxyPort", "8080");HTTPS কী-গুলো HTTPS এন্ডপয়েন্টের জন্য প্রযোজ্য; HTTP-এর জন্য সংশ্লিষ্ট IBM HTTP কী ব্যবহার করুন। অনুমোদিত একটি পাবলিক SOAP এন্ডপয়েন্ট HTTP প্রক্সি তালিকা থেকে HTTP ঠিকানা ব্যবহার করতে পারে কেবল তখনই, যখন প্রযোজ্য পলিসি ও টানেলিং নিয়ন্ত্রণ তা অনুমতি দেয় এবং সেই স্তরে কোনো প্রক্সি অ্যাকাউন্ট কনফিগার করা না থাকে। প্রক্সি প্রমাণীকরণের HTTP/HTTPS proxyUser ও proxyPassword আলাদা বৈশিষ্ট্য, যা SOAP পরিষেবার শংসাপত্র থেকে স্বাধীন।
এগুলো WebSphere-এর এক্সটেনশন। Metro, CXF বা অন্য বাস্তবায়নে BindingProvider ম্যাপ ওই স্ট্রিংগুলোকে বহনযোগ্য করে না।
বিভিন্ন সমকালীন রুট যথাযথভাবে কনফিগার করা ক্লায়েন্ট অবজেক্টে রাখুন, কল চলাকালে কোনো ভাগ করা পোর্ট প্রসঙ্গ পুনরায় লিখবেন না। এতে ঠিকানাটি প্রকৃত ক্লায়েন্টেই সীমিত থাকে এবং তার চারপাশের সব JVM নিয়ন্ত্রণকে ক্লায়েন্ট-স্থানীয় ধরা হয় না।