2015-05-20 211 views
4

我們需要保證發送Web服務請求。步驟如下:確保向Web服務發送請求

  1. 嘗試將請求發送到Web服務。同步或異步請求無關緊要。
  2. 如果服務由於某種原因(例如服務不可用)而未確認請求,我們會在一段時間內再次嘗試第1步(即有某種輪詢)。

問題在於執行步驟#2(即輪詢)。 這個用例看起來很常見,我認爲應該已經有解決方案了。所以我希望只向Web服務發送一個請求,所有其他邏輯(即其保證的交付)將由某個框架執行。

你知道這樣的解決方案嗎?

有「Guaranteed delivery」EIP模式和駱駝支持它。但是我沒有找到駱駝支持它的任何信息,以及它是否適合我們的情況。

我們的要求 - Java,SOAP,開源解決方案。 我們計劃使用Apache CXF,但它並不重要。

最後的話:分別提供 2偉大的答案:

  1. 春重試布萊恩·阿格紐。這是相當普遍的方法,不僅適用於Web服務。
  2. 來自Ashok Nanda的CXF故障切換。該解決方案就Web服務而言,完全符合我們的需求。

不幸的是我不能選擇兩個答案作爲最終讓我選擇了布萊恩的一個,因爲它是第一個,他提供了幫我看看另一個可能的問題:-) 謝謝你們一個真正偉大的解釋!

+0

我不會真的稱之爲「輪詢」,而只是「重試」。 (請小心如何解決何時重試,請注意。)我不確定你在這裏尋找什麼 - 模式或庫中現有模式的實現? –

回答

4

除了簡單地在某種循環中編寫請求,您可以查看框架,如Spring Retry

它將允許您定義您的重試策略,以考慮退避策略,超時以及何時/何時而不是嘗試重試。最後的因素是至關重要的。如果您無法連接,那麼重試是可行的。另一方面,如果您連接併發送請求但未能得到確認,那麼您需要了解重試是否合適。 idempotency of requests的概念在這種情況下很重要。

冪等HTTP方法是一種HTTP方法,可以稱爲多個 次沒有不同的結果。如果方法是 只調用一次或十次,這並不重要。結果應該是一樣的。 同樣,這隻適用於結果,而不適用於資源本身。這個 仍然可以被操縱(如更新時間戳,前提是這個 信息不在(當前)資源表示中共享。

+0

感謝您的快速響應和詳細的答案。它看起來像我們真正需要的。將檢查它並返回到這裏。 關於確認,我認爲服務首先確認即將到來的請求存儲在請求隊列中。然後纔開始處理請求。 在這種情況下,承認是我們唯一需要的。 我錯過了什麼嗎? –

+1

這聽起來正確。回覆。您的確認場景。想象一下,如果你發出你的請求,並且你在等待這個迴應。一段時間後,你會超時的連接。您必須詢問您是否可以重試該請求 –

4

在Apache的CXF,它是可以做到的消息傳遞重試時的目標端點是向下使用org.apache.cxf.clustering.RetryStrategy 類和擴展此。 請參考:http://cxf.apache.org/docs/failoverfeature.html

這是主要的運行時庫CXF,CXF-RT-功能 - clustering.jar的一部分,將在OSGi的/非OSGi的或駱駝的環境甚至工作。

+0

感謝Ashok!如果有可能將2個答案標記爲最終答案,我肯定也會選擇你的答案。 您的建議更適合網絡服務。 我已經用最終詞更新了上面的描述。 –