Service Broker 的優點
Service Broker 的功能為資料庫應用程式提供了許多重要的優點。這些功能和優點包括：
- 資料庫整合，增強應用程式效能並簡化管理。
- 訊息排序和協調，簡化應用程式開發
- 鬆散應用程式偶合，提供工作負載彈性。
- 相關的訊息鎖定，允許應用程式的一個以上執行個體處理同一佇列的訊息，而無需明確同步處理。
- 自動啟動，允許應用程式隨訊息容量擴充。
資料庫整合
Service Broker 的整合設計提供了應用程式效能和管理上的優勢。
與 SQL Server 整合允許在不增加負擔和外部份散式交易協調器之複雜性的情況下，進行交易式訊息傳送。應用程式會在單一資料庫交易中接收一或多則訊息、處理訊息並傳送回覆訊息。如果交易失敗，所有工作都會回復，且接收的訊息會返回佇列，以便再次嘗試處理它。應用程式認可交易之前，任何動作都不會生效。應用程式的狀態會保持不變。
當資料、訊息和應用程式邏輯都位於資料庫中時，管理要更為容易，因為此時應用程式的管理 (損毀復原、安全性、備份等) 會成為資料庫之例行管理的一部份，且管理員無需管理三個或四個不同的元件。
在傳統的訊息傳送系統中，訊息存放區和資料庫可能會不一致。例如，當從備份還原一個元件時，另一個元件也必須同時從備份還原，否則訊息存放區中的資訊會與資料庫中的資訊不相符。而 Service Broker 會在同一資料庫中保留訊息和資料，所以不一致性並不是問題。
一般開發環境也是資料庫整合的優點。利用開發人員對以訊息為基礎之程式設計的資料庫程式設計技術的熟悉，應用程式的訊息傳送部份和資料部份可在 Service Broker 應用程式中使用相同的 SQL Server 語言和工具。實作 Service Broker 服務的預存程序可以採用 Transact-SQL 或其中一種 Common Language Runtime (CLR) 語言來撰寫。資料庫以外的程式則使用 Transact-SQL 和熟悉的資料庫程式設計介面，如 ADO.NET。
此外，資料庫整合還啟用了自動資源管理。由於 Service Broker 在 SQL Server 執行個體的內容中執行，因此 Service Broker 可監視準備好從執行個體之所有資料庫傳輸的一切訊息。這可讓每個資料庫維護其自己的佇列，同時協助 Service Broker 管理整個 SQL Server 執行個體內資源的使用。
排序和協調訊息
在傳統的訊息傳送系統中，應用程式一直負責排序和協調可能未按順序到達的訊息。例如，應用程式 A 傳送訊息 1、2 和 3。應用程式 B 接收並確認了訊息 1 和 3，但在處理訊息 2 時發生錯誤。則應用程式 A 會重新傳送訊息 2，但是現在該訊息會在訊息 1 和 3 之後收到。在過去，開發人員必須撰寫應用程式以忽略訊息的順序，或在訊息 2 到達之前暫時快取訊息 3，讓應用程式能夠以正確的順序處理訊息。這兩種解決方案既不直接也不簡單。
傳統系統的另一個問題就是重複傳遞。在前一範例中，如果應用程式 B 收到訊息 2，但傳回應用程式 A 的收條訊息遺失了，應用程式 A 便會重新傳送訊息 2，導致應用程式 B 收到訊息 2 兩次。應用程式碼必須能識別或捨棄重複訊息，或重新處理重複訊息，而不產生負面影響。同樣，這兩種方法也難以實作。
訊息協調在過去也是難以處理的問題。例如，應用程式可能會向服務提交成百上千的要求。服務會平行處理要求，並在服務完成處理要求時立即傳回回應。因為每個要求所需的處理時間不同，所以應用程式接收回應的順序會與應用程式傳送外寄訊息的順序不同。但是，為了正確地處理回應，應用程式必須將每個回應與正確的外寄訊息關聯。在傳統的訊息傳送系統中，每個應用程式都管理此關聯，增加了開發應用程式的成本和複雜性。
Service Broker 則透過自動處理訊息順序、唯一傳遞和交談識別，解決了這些問題。一旦在兩個 Service Broker 端點之間建立交談，應用程式對每個訊息僅會接收一次，並依照傳送訊息的順序。您的應用程式可以精確單次循序處理訊息，而無需其他程式碼。最後，Service Broker 會在每則訊息中自動包含識別碼。應用程式也始終會判斷特定訊息所屬的交談。
鬆散偶合和工作負載彈性
Service Broker 提供起始應用程式和目標應用程式之間的鬆散偶合。應用程式可以傳送佇列上的訊息，然後繼續應用程式處理，同時依賴 Service Broker 來確保訊息到達其目的地。這種鬆散偶合提供了排程彈性。起始端可傳送多個訊息，而多個目標服務可平行處理這些訊息。每個目標服務都會以自己的速度處理訊息，這取決於目前的工作負載。
佇列也可讓系統更平均地散發處理，以降低伺服器所需的尖峰容量。這可提升資料庫應用程式中的整體輸送量和效能。例如，許多資料庫應用程式的交易都會在一天的某個時間激增，導致資源消耗的增加和回應時間的減慢。而使用 Service Broker，這些應用程式無需在業務交易提交至應用程式時執行其所有處理。而是由應用程式使用 Service Broker 將有關交易的資訊傳送至執行背景處理的應用程式。那些應用程式會在一段時間內可靠地處理交易，同時主要的輸入應用程式會繼續接收新的業務交易。
如果目的地無法立即使用，則訊息會保留在傳送資料庫的傳輸佇列中。在成功傳送訊息或交談的存留時間過期之前，Service Broker 會重試訊息，讓兩個服務間的可靠交談繼續進行，即使一個服務在交談期間的某一時刻暫時無法使用。傳輸佇列中的訊息是資料庫的一部份；即使執行個體容錯移轉或重新啟動，Service Broker 也會傳遞訊息。
相關的訊息鎖定
在傳統訊息傳送應用程式中，最困難的事情之一就是讓多個程式從同一佇列平行讀取。在傳統的訊息傳送系統中，當多個程式或多個執行緒從同一佇列進行讀取時，會以錯誤的順序處理訊息。Service Broker 則可透過交談群組鎖定來防止這種情況的發生。
考慮傳統的順序處理應用程式。在佇列上收到訊息 A (包含有關建立訂單標頭的指示) 和訊息 B (包含有關建立訂單行項目的指示)。如果這兩則訊息由不同的應用程式執行個體移出佇列並同時處理，則訂單行項目交易可能會嘗試先認可，但因訂單尚不存在而失敗。隨後，失敗又會導致交易回復，並重新佇列和處理訊息，這會浪費資源。在過去，程式設計人員解決此問題的方法是將訊息 A 和訊息 B 的資訊組合成單一訊息。雖然此方法對兩則訊息而言是很直接，但其無法擴充至涉及調整數十或數百則訊息的系統。
Service Broker 則透過關聯交談群組中的交談對話，解決了此問題。Service Broker 會自動鎖定同一交談群組中的所有訊息，以便這些訊息僅可由一個應用程式執行個體接收和處理。同時，該應用程式的其他執行個體會繼續移出佇列，並處理其他交談群組中的訊息。這可讓多個平行應用程式執行個體可靠而有效地運作，而無需在應用程式中包含複雜的鎖定程式碼。
自動啟動
Service Broker 其中一項最有用的功能就是啟動。啟動可讓應用程式動態地進行自我擴充，以配合到達佇列的訊息量。Service Broker 提供的功能可讓在資料庫內以及資料庫外執行的程式均從啟動中獲益。但是，Service Broker 不需要應用程式使用啟動。
Service Broker 會監視佇列中的活動，以判斷應用程式是否正在接收包含可用訊息之所有交談的訊息。Service Broker 啟動會在有工作需要佇列讀取器執行時啟動新的佇列讀取器。為了判斷何時存在需要佇列讀取器執行的工作，Service Broker 會監視佇列上的活動。當佇列讀取器的數目符合連入流量時，佇列會定期達到下列狀態：佇列為空，或佇列中的所有訊息都屬於其他佇列讀取器正在處理的交談。如果佇列在一段時間內未達到此狀態，Service Broker 會啟動應用程式的其他執行個體。
應用程式會對在資料庫中以及資料庫外執行的程式使用不同的啟動方法。對於資料庫中的程式，Service Broker 會啟動佇列指定之預存程序的其他副本。對於在資料庫外執行的程式，Service Broker 則會產生啟動事件。程式會監視此事件，以判斷何時需要其他佇列讀取器。
啟動期間，Service Broker 不會停止程式。而是撰寫啟動的應用程式，在一段時間沒有到達的訊息需要接收之後自動關閉。以此方式設計的應用程式，可允許應用程式執行個體的數目隨著服務流量的變更而動態增長或縮減。同樣，如果系統關閉或重新啟動，會自動啟動應用程式，以在系統重新啟動時讀取佇列中的訊息。
傳統的訊息傳送系統則不具有此行為，且通常是在某一給定時間特定佇列的專用資源太多或太少時停止。
請參閱
其他資源
Service Broker 架構
Introduction to Service Broker Programming