בחירת פרוקסי ללקוח WebSphere 8.5.5 JAX-WS אחד
החילו את מאפייני הפרוקסי המתועדים של WebSphere על הקשר הבקשה של לקוח JAX-WS במקום לשנות את הניתוב בכל ה-JVM.
ב-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 שסביבו כאל מקומיים ללקוח.