用於請求 - 響應的WCF或服務總線會話

Question

我正在使用內部部署服務總線1.1進行進程之間的通信。

我需要執行端點之間的請求響應方法，並需要決定是否使用WCF或總線（WCF的服務總線中繼當前不可用）。

• WCF是最容易通過生成的客戶端代理交談，潛在的與IIS主機（或自主機）和客戶端調用服務的版本複雜性。

• 對於服務總線，爲每個遠程服務創建兩個隊列（即 userService，userServiceResponse），然後使用會話。使用不同的命令靈活的版本控制這些隊列的管理可能變得複雜。

• 我的項目一切都在同一子網內，如果需要WCF終端可以直接相互交談

要幫我決定使用哪種技術，我的問題是：

1. WCF將用於請求響應服務總線？

2. 服務總線隊列中是否有任何庫實現 請求 - 響應消息傳遞（或任何健壯的代碼示例）？

3. 如果我們隊列中有多個發佈者，我們將如何返回給特定發件人的回覆？我們會有多個serviceReponse隊列，還是可以使用單個返回隊列？

Answer 1

服務總線的消息可以有用於該請求，其中服務將收到消息SessionID獨特的，用它做的東西，並使用具有在ReplyToSessionID相同ID的消息進行答覆。這允許接收基於會話ID請求方這樣

MessageSession sessionReceiver = _queueClient.AcceptMessageSession(_mySessionID,TimeSpan.FromSeconds(5)); 
sessionReceiver.Peek(); 

我覺得這裏最大的問題是同步VS異步是否要請求方坐下來，等待響應（WCF）或回稍後再檢查響應是否準備好，但Service Bus卻是一個商業決策。

link或MSDN article可能會幫助您開始使用SB的Req/Rep。

Answer 2

我不認爲決定使用哪種技術是商業決策。起初，這是技術性的。 我不會選擇一款非常依賴操作系統的產品，而最糟糕的是，它太早了。我們可以創建耦合（OS x總線），並跨越開採領域。 但是，這只是個人觀點，可能會有偏差，因爲我不是Azure SB專家。

我同意@Tom，你的決定更多地涉及同步/異步模型。

一些問題，我通常會決定這個問題之前回答：

1. 我們可以預覽請求/分鐘的速度和客戶端的數量？
2. 服務的性質是什麼？針對數據庫的重處理邏輯或簡單查詢？

如果您願意，我可以列出一些其他人，但這兩者可以輕鬆幫助您做出決定，迫使您進行廣泛的思考。