WCF 服務設計規範（六）：佇列服務、安全與服務匯流排最佳實踐

佇列服務

1. 用戶端調用前驗證佇列可用性：含死信佇列，使用 QueuedServiceHelper.VerifyQueues()。
2. 裝載時自動驗證：ServiceHost<T> 會自動檢測佇列可用性。
3. 避免同一服務同時支援佇列與非佇列模式：除特殊孤立場景外不建議混用。
4. 服務參與回放交易：確保訊息處理的交易完整性。
5. 回放交易中避免冗長處理：縮短交易持有時間，減少鎖定衝突。
6. 避免會話型佇列服務：佇列本質為無狀態，會話增加複雜度。
7. 單例佇列服務使用易失性資源管理器管理狀態：避免狀態序列化問題。
8. Per-Call 佇列服務明確設定無會話、Per-Call 模式：

   [ServiceContract(SessionMode = SessionMode.NotAllowed)]
   interface IMyContract { ... }
   [ServiceBehavior(InstanceContextMode = InstanceContextMode.PerCall)]
   class MyService : IMyContract { ... }
   

9. 單例佇列服務同樣禁止會話：同上設定 InstanceContextMode.Single。
10. 用戶端在交易範圍內呼叫佇列服務：保證送訊原子性。
11. 用戶端勿將佇列代理存為成員變數：代理應短暫建立、用畢釋放。
12. 避免過短的 TimeToLive：會抵消佇列服務「延遲傳遞」的優勢。
13. 避免非交易型佇列：交易型佇列提供可靠性保證。
14. 使用回應佇列時，服務參與回放交易並將回應訊息入佇。
15. 回應服務參與回應回放交易。
16. 佇列回應操作避免冗長處理。
17. MSMQ 3.0 推薦用回應服務處理服務失敗，而非毒藥佇列。
18. MSMQ 4.0 毒藥訊息預設用 ReceiveErrorHandling.Reject：除非有進階 Move 處理，避免 Fault 與 Drop。
19. MSMQ 4.0 考慮用回應服務處理回放失敗。
20. 非會話契約下，勿假設佇列調用有序。
21. 避免多端點共用同一佇列：造成訊息路由混亂。
22. 避免使用接收內容：增加複雜度且易出錯。

安全

1. 始終保護訊息，提供機密性與完整性。
2. 內網環境可用傳輸安全，前提保護等級設為 EncryptAndSign。
3. 內網避免模擬，將模擬等級設為 TokenImpersonationLevel.Identification。
4. 需模擬時，用戶端使用 TokenImpersonationLevel.Impersonation。
5. 使用宣告式安全框架，避免手動組態。
6. 切勿在服務類別直接套用 PrincipalPermission 屬性：永遠會失敗。
7. 服務建構函數避免執行需授權的敏感工作。
8. 避免要求特定使用者（不論是否帶角色）。
9. 用戶端回調操作不依賴角色型安全。
10. 網際網路用戶端強制使用訊息安全。
11. 允許用戶端協商服務憑證（預設行為）。
12. 自訂認證使用 ASP.NET Providers。
13. 開發自訂認證存儲時，實作為自訂 ASP.NET Provider。
14. 使用對等信任驗證憑證。

服務匯流排

1. 優先使用 TCP 轉送繫結：效能最佳。
2. 讓服務可被發現：支援動態端點解析。
3. 使用離散事件：而非連續資料流。
4. 緩衝區不是佇列：勿混淆語意。
5. 緩衝區場景避免原始 WCF 訊息，改用 BufferedServiceBusHost<T>/Client<T> 強型別結構化呼叫。
6. 使用訊息安全。
7. 服務匯流排驗證不用於使用者驗證：僅驗證呼叫應用程式身分。
8. 爭取匿名呼叫，由服務匯流排驗證呼叫端應用程式。