انتخاب پروکسی برای یک کلاینت JAX-WS در WebSphere 8.5.5

در 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 هستند. نگاشت BindingProvider در Metro، CXF یا پیاده‌سازی دیگر این رشته‌ها را قابل حمل نمی‌کند.

مسیرهای هم‌زمان متفاوت را روی اشیای کلاینت درست پیکربندی‌شده نگه دارید، نه اینکه هنگام اجرای فراخوانی‌ها زمینه درگاه مشترک را بازنویسی کنید. این کار نشانی را به کلاینت واقعی محدود می‌کند، بدون آنکه همه کنترل‌های JVM پیرامون آن محلی برای کلاینت شمرده شوند.