在上一篇文章中我們瞭解請求/響應模式的概念和適用場景：http://blog.csdn.net/lohocc/article/details/42743693
這一篇文章我們來對服務設計模式的請求/確認模式來做一個瞭解
Web服務如何保護系統，使其免受請求負載中峯值的影響；當底層系統不可用時，如何保證請求能夠得到處理？
在設計web服務時，客戶端與服務端的時間耦合度是一個關鍵的因素，當接收到請求就必須立馬處理，這樣的時間耦合度相對較高，這包括所有的應用程序必須正常運行（數據庫，原有的web程序等等）。高時間耦合度還會造成系統因爲峯值負載所帶來的過度的資源消耗的系統級錯誤。
我們使用請求/確認模式來代替請求/響應模式,在這種模式下，服務端會執行以下幾步操作：
1.接收請求
2.驗證客戶端證書（非必須）
3.授權客戶端可以執行的請求操作（非必須）
4.校驗請求（非必須）
5.生成請求標識符/URI
6.存儲並轉發消息
7.返回應答消息
我們來了解以下5-7的一個流程：客戶端通過所有的校驗後，服務會生成一個請求標識符或URI，這個是具有唯一性的鍵值，它可以供參與回話的各方在未來的交互中引用請求，創建後它（請求標識符/URI）就被附加到請求中，再議隊列或數據表的方式轉發到一個後臺異步的進程，請求處理器會處理客戶端的每一個請求，並把它轉發到相應的隊列中（等待進程去處理），在轉發完成後（此時放到隊列中的請求可能尚未處理），給客戶端返回一個狀態碼/文檔消息，文檔消息在消息體某個地方包含了請求標識符。
請求/確認的實現方式：
（1）輪詢：請求/確認/輪詢作爲請求/確認的一個變種，這種模式下要求客戶端定期輪詢另一個web服務，以獲取更新信息或處理結果，但是這種情況客戶端必須先從確認消息中取回一些輪詢的先決信息（如請求標識符），如果客戶端崩潰/斷網等等，只要在這些情況發生前已經從確認的消息中提取出了輪詢所需要的信息，並保存好，那麼在重新啓動/聯網後，也能取回服務端處理的最終結果。
請求/確認/輪詢的頻率如果不夠高，則會導致客戶端數據更新不夠及時，如果過高，又會導致服務端產生過度的負擔，產生大量的網絡流量。
（2）回調和轉發：與輪詢模式類似，只是這裏不會讓客戶端進行輪詢來獲取處理結果，而是請求處理器將結果信息推送回客戶端或轉發給其他參與者，後面這種屬於轉發模式，在進行回調時，服務端與客戶端角色互換，即原來發送請求的客戶端必須提供一個回調服務來接受服務端的回調。
回調模式下如果單一請求會產生多個更新，一個請求要發送給多個回調服務，如果請求結果需要多種格式化，那麼需要的系統資源將會高出原先的很多。
（3）發佈/訂閱模式：發佈/訂閱是一種經典的設計模式，在這種模式下，一個消息發送者（發佈者）先將消息傳輸給一箇中介，對消息感興趣的各方（訂閱者）可以從這個中介接收消息，同時有保證他們會彼此獨立，不會感知到其他各方的存在。
請求/確認/輪詢和請求/確認/轉發是兩種實現這種模式的方法。前面這種方法中，服務只負責接收消息，由服務來把處理的結果持久化（存入數據庫或文件系統中），訂閱者通過另一個服務把處理的結果取回來。後一種服務負責接收消息的發佈者，再將消息推送到訂閱者。
