作爲一個「事務」的兩個SOAP服務的首選設計

Question

我正在設計一個服務，它依賴於兩個（甚至有時甚至是三個）SOAP服務進行更新。流動例如可以是這樣的：

1. 系統我的SOAP客戶端調用customerUpdate一個
2. 在系統B我的SOAP客戶端調用customerUpdate

大多數情況下，這工作正常，系統會非常穩定（99％的正常運行時間是目標），但總是會有1％。我怎樣才能使這個接近交易。

我一直在尋找一些文學或一些類似的設計經驗，但迄今沒有成功。

問題是我應該如何通知我的服務的調用者如果SOAP調用1正常，但調用2失敗。

到目前爲止，我看到了以下解決方案：

• 我作出這樣告訴發生了什麼用戶一個錯誤信息：系統A更新，但系統B沒有。他們必須重新發送以更新兩個系統。
• 我爲失敗時的更新創建一個隊列，並給出一個SOAP響應，告訴用戶系統B離線/無響應但將被更新，系統A已更新。

有沒有人偶然發現這種情況下的測試設計模式？或者也許有經驗的人可以指出我正確的方向，哪一個應該是首選？哪一個更容易維護？

我知道這可能會導致更多的討論，而不是有針對性的問題，但我希望這是可以的。

Answer 1

至於你的第一個解決方案，這可能並不普遍適用。 例如，如果您有withdraw和deposit和deposit失敗，則不得重複第一個操作。 無論如何，它會讓你的調用者正確地做對。

至於你的第二個解決方案，所有的服務都必須記錄失敗的操作。除了呼叫者被留在「在交易中喪失」狀態。

一般的做法是讓transaction控制兩種操作。對於某些WS-Transaction實現，請參見here 。

如果您不能擁有SOAP交易，我將只提供一個 SOAP函數，它代表服務器端的調用者處理所有受影響系統的事務處理，例如通過使用XA數據源。如果你看看你的例子，無論如何，它可能是一個邏輯操作 。

更新

如果你選擇你的第一個解決方案，考慮增加一個獨特的，自制的事務ID給每個SOAP消息。這應該爲服務器端提供一個通用的方法來丟棄重複的消息（例如通過實現事務日誌）。