Service Broker 的作用為何？
Service Broker 可以協助開發人員建立非同步、鬆散偶合的應用程式，使獨立的元件可以在其中一起運作來完成工作。這些應用程式元件會交換包含完成工作所需資訊的訊息。本主題描述 Service Broker 的下列層面：
交談
訊息排序和協調
交易式非同步程式設計
對鬆散偶合之應用程式的支援
Service Broker 元件
交談
Service Broker 圍繞傳送和接收訊息的基本功能而設計。每個訊息都會形成交談的一部分。每個交談都是一個可靠、永續性的通訊通道。每個訊息和交談都具有 Service Broker 強制使用的特定類型，以協助開發人員撰寫可靠的應用程式。
新的 Transact-SQL 陳述式可讓應用程式可靠地傳送及接收這些訊息。一個應用程式將訊息傳送至「服務」(一組相關工作的名稱)。另一個應用程式則從「佇列」(內部資料表的檢視) 接收訊息。
同一工作的訊息是同一交談的一部份。在每個交談中，Service Broker 都會保證應用程式只接收每個訊息一次，並依照傳送訊息的順序接收。實作服務的程式可以將相同服務的相關交談關聯到「交談群組」中，如＜Service Broker 的優點＞中所述。
憑證式安全性可以協助您保護機密訊息並控制對服務的存取。例如，將 Service Broker 視為郵遞服務。若要與遠方同事進行交談，您可以透過郵遞服務傳送郵件來進行通訊。郵遞服務會排序並傳遞郵件。接著，您和您的同事會從信箱擷取郵件、讀取郵件、撰寫回應，然後傳送新的郵件，直到交談結束為止。當您和您的同事處理其他工作時，郵件傳遞會非同步發生。
.gif "兩個使用者透過郵遞服務交換郵件。")
程式可以將 Service Broker 當做郵遞服務使用，以支援與其他程式進行非同步交談。Service Broker 訊息的功能類似郵件。Service Broker 服務是郵局將郵件遞往的地址。佇列則是郵件傳遞後保留郵件的信箱。應用程式會接收訊息、處理訊息並傳送回應。
當應用程式將訊息傳送到 Service Broker 服務時，它可以與交談另一端之應用程式的實作詳細資料隔離。接收應用程式可以動態進行重新設定，或取代為新的程式碼，而不影響傳送應用程式。接收應用程式甚至可以暫時關機；唯一的影響是，Service Broker 會不斷將新訊息加入到佇列中，直到重新啟動接收應用程式為止。
訊息排序和協調
Service Broker 處理佇列是一種常見的資料庫程式設計技術，它與傳統產品的不同主要在於兩個方面：
Service Broker 佇列已整合到資料庫中。
佇列會協調並排序相關訊息。
整合的佇列表示資料庫的定期維護和管理，也包括 Service Broker。通常，管理員沒有與 Service Broker 相關的例行維護工作。
Service Broker 架構提供簡單的 Transact-SQL 介面來傳送和接收訊息，還提供了對訊息傳遞和處理的一組有力保證。Service Broker 保證程式只接收交談中的每個訊息一次，並依照傳送訊息的順序，而不是訊息進入佇列的順序接收。傳統的佇列產品會以訊息進入佇列的順序提供訊息。這需要應用程式決定訊息的順序和群組。Service Broker 還保證兩個佇列讀取器無法同步處理相同交談的訊息或相關交談之相同群組的訊息。
每個 Service Broker 交談都具有兩端：開始交談的一端稱為起始端；另一端則稱為目標端。兩端各有一個服務；分別是起始端服務與目標端服務。每個服務都有一個相關聯的訊息佇列。
以下說明在典型對話交談中交換訊息：
在起始端：
程式開始交談。
程式會建立包含執行工作所需資料的訊息。
程式會將訊息傳送到目標端服務。
在目標端：
訊息會放在與目標端服務相關聯的佇列中。
程式會從佇列接收訊息，然後執行工作。
程式會藉由將訊息傳送到起始端服務來回應。
在起始端：
回應訊息會放在與起始端服務相關聯的佇列中。
程式會接收回應，然後進行處理。
在起始端結束交談前會重複這個循環，因為它沒有其他要求可以傳送到目標端。
Service Broker 支援在每個交談中設定從 10 (高) 到 1 (低) 的優先順序。這可以確保優先順序低的工作不會阻擋優先順序較高的工作。Service Broker 系統可以設定為提供各種服務層級。如需詳細資訊，請參閱＜交談優先權＞。
Service Broker 會處理與撰寫訊息應用程式相關的最困難工作。這些困難的工作包括訊息協調、可靠的訊息傳遞、鎖定，以及啟動佇列讀取器。這可讓資料庫開發人員專注於如何解決商務問題。
交易式非同步程式設計
在 Service Broker 基礎結構中，應用程式間的訊息傳遞是「交易式」和「非同步」的。因為 Service Broker 訊息傳送為交易式，所以如果交易回復，交易內的所有 Service Broker 作業都將回復。其中包括傳送以及接收作業。在非同步傳遞中，當應用程式繼續執行時，Database Engine 會處理傳遞。為提升延展性，Service Broker 提供了一個機制，可以在需要處理佇列的程式來完成某些有用的工作時，自動將其啟動。如需詳細資訊，請參閱＜Service Broker 啟動＞。
非同步程式設計可以協助開發人員撰寫使用佇列的應用程式。許多資料庫應用程式都包括資料表，這些資料表可當作資源允許時要完成的工作佇列。佇列可以提供資料庫應用程式的兩個優點：
將應用程式的工作要求放入佇列後，應用程式就可以立即回應互動使用者。應用程式不必等到所有與要求相關聯的工作完成後再回應。提供資源時，就會處理佇列的要求。這可讓資料庫保持對互動使用者的回應，並有效使用可用的資源。
與單一要求相關的工作有時候可以分割為多個工作單位，當做個別的交易處理。在這個情況下，資料庫應用程式可以將要求放入佇列中，藉以啟動每個工作單位。Service Broker 延伸了這個概念，讓應用程式可以在個別電腦的多個 Service Broker 執行個體上分散工作。
針對佇列中的序列和處理序項目正確地撰寫應用程式的程式碼通常很複雜。開發人員可以使用 Database Engine 內建的 Service Broker 功能來簡化成功實作資料庫佇列所需的程式碼。
對鬆散偶合之應用程式的支援
Service Broker 支援鬆散偶合的應用程式。鬆散偶合的應用程式由多個獨立傳送和接收訊息的程式組成。這類的應用程式必須包含相同的已交換之訊息的定義，而且必須針對服務間的互動，定義相同的整體結構。不過，應用程式不必在相同時間執行，也不必在相同的 SQL Server 執行個體中執行或共用實作詳細資料。應用程式不需要了解交談中其他參與者的實體位置或實作。
Service Broker 元件
Service Broker 有三種類型的元件：
**交談元件。**交談群組、交談和訊息會形成 Service Broker 應用程式的執行階段結構。應用程式會做為交談的一部份來交換訊息。每個交談都是一個交談群組的一部分，而一個交談群組可以包含多個交談。每個 Service Broker 交談都是一個對話。對話就是兩個參與者實際交換訊息的交談。如需有關交談元件的詳細資訊，請參閱＜交談架構＞。
**服務定義元件。**這些是設計階段元件，指定應用程式所使用之交談的基本結構。它們定義應用程式的訊息類型、應用程式的交談流程，以及應用程式的資料庫儲存體。如需有關服務定義元件的詳細資訊，請參閱＜服務架構＞。
**網路和安全性元件。**這些元件會定義在 Database Engine 執行個體之間交換訊息所使用的基礎結構。為了協助資料庫管理員管理不斷變更的環境，Service Broker 可讓管理員獨立於應用程式碼之外設定這些元件。如需有關網路和安全性元件的詳細資訊，請參閱＜網路和遠端安全性＞。
服務定義元件、網路元件和安全性元件都是資料庫和 SQL Server 執行個體之中繼資料的一部分。交談群組、交談和訊息是資料庫所包含之資料的一部份。