JAX-WS用於調用Web服務的Asynchonous客戶端技術

Question

我正在使用JAX-WS對基於SOAP的Web服務進行一些研究，我發現了解客戶端部分非常復雜。 如果有人可以幫我解釋一些主題，我會非常感激。 我正在使用SOA書籍和Google，但我真的很困惑，所以我想在這里我可以得到更准確的答案，專注於我需要的東西。

因此，我們可以以同步和異步方式與Web服務進行通信。 同步通信缺乏雙方必須等待，直到處理結束。

異步客戶端允許我們使用2種編程模型以異步方式進行通信：1-回調和2-輪詢

• 疑問1：有人可以用簡單的方式向我解釋兩種模式的差異，優缺點（Callback and Pooling）

在談論異步通信時，我也明白生產者（Web服務）應該有一種方法，一旦處理完成就找到消費者（客戶端）。這就是為什么我們要解決。

• 疑問2：您能否簡要解釋一下尋址的工作原理？ 以及如何解決與回調和輪詢技術有關的問題？

還有一件事。 Dispatch API也讓我很困惑。 因為他們一直在談論動態客戶。

• 疑問3：如果Dispatch API一直在談論動態客戶端，那么它與異步通信的關系如何？
• 疑問4： Dispatch API的兩種使用模式（MESSAGE和PAYLOAD），用於什么，以及它們如何與JAXWS的異步通信模型相關？

Answer 1

1. 有人可以用簡單的方式向我解釋一下這兩個模型的區別，優缺點是什么（Callback and Pooling）
   

回調 ：實施不是直截了當的。
- 優勢：這種方法更加優雅/系統地適用於輪詢方法。
- 缺點：客戶端應該有一個機制，以便服務器可以使用回調來回調它。

輪詢 ：實施是直截了當的。
- 優點：由於技術的簡單性，它是通用的，即使是啟用了ajax的網頁也可以使用此技術來檢查請求的更新是否可用。
- 缺點：帶寬的巨大浪費，以及服務器客戶端計時問題，例如服務器持有響應多長時間，來自客戶端的輪詢請求尚未到來。

你能簡單解釋一下尋址是如何工作的嗎？ 以及如何解決與回調和輪詢技術有關的問題？

尋址使Web服務可以理解之前在消息傳遞系統和傳輸提供者之間共享的信息。 考慮這個用例，最初使用的傳輸將是HTTP，用於發送請求和響應。然后，您可能希望更改此傳輸的一部分，比如在發送響應時，僅更改為SMTP協議。 如果您正在使用ws尋址，那么與傳輸和尋址相關的全部信息將成為soap envolope本身的一部分，這將使您的Web服務能夠動態地將傳輸更改為響應發送。

Web服務尋址也可用於從服務器到客戶端的回調。 該服務在WSDL中通知它所需的回調的端口類型。 客戶端實現此端口類型，然后使用WS尋址通知回調端點的服務。

簡單來說，WS尋址為soap envolope添加了額外的標簽，其中包含僅存在於傳輸頭中的信息，如地址，地址，動作名稱等。

3.如果他們一直在談論動態客戶端，那么Dispatch API如何與異步通信相關？

Future<?> response = dispatch.invokeAsync(T, AsyncHandler);

invokeAsync方法是一種輪詢方法。 響應立即返回給用戶，並可以輪詢完成。 在此期間，客戶端程序可以執行其他工作.javax.xml.ws.Response實現J2SE 5.0中包含的java.util.concurrent.Future接口。 Response對象通過其get方法返回實際響應，該方法阻止響應未准備好返回。

4. Dispatch API的兩種使用模式（MESSAGE和PAYLOAD），用於什么，以及它們如何與JAXWS的異步通信模型相關？
消息傳遞模式與異步通信沒有直接關系。 消息傳遞模式定義Web服務請求中發送的信息量。 只有在使用SOAP綁定時才能使用MESSAGE MODE。