對話交談
Service Broker 所傳送的所有訊息都是交談的一部分。對話是指兩個服務之間的交談。對話是兩個服務之間可靠而永續性的雙向訊息資料流。
對話提供精確單次循序 (EOIO) 訊息傳遞。它會使用每個訊息中包含的交談識別碼和序號，來識別相關訊息並按正確的順序傳遞訊息。對話是兩個服務間可靠而永續性的訊息資料流。
對話交談有兩個參與者。「起始端」(Initiator) 會開始交談。「目標」則接受起始端開始的交談。如交談合約所指定，參與者是否開始交談，決定著參與者可以傳送的訊息。下圖顯示對話的訊息流程：
.gif "起始端與目標之間的訊息流程")
應用程式會做為對話的一部份來交換訊息。當 SQL Server 收到對話的訊息時，SQL Server 會將訊息排入對話的佇列中。應用程式則從佇列收到訊息，並視需要進行處理。在處理期間，應用程式可能會將訊息傳送至對話中的另一個參與者。
可靠傳遞
對話會併入自動訊息收條，以確保可靠傳遞。Service Broker 會將每個外寄訊息儲存在傳輸佇列中，直到遠端服務認可該訊息為止。這些自動收條使應用程式不必明確認可每則訊息，既節省時間又節省資源。如果可能，收條訊息會做為對話之傳回訊息的一部份包含其中。
[!附註]
Service Broker 會在內部處理收條訊息。這些訊息不會出現在佇列中，也不會傳遞給應用程式。
Service Broker 不會將無法連上遠端服務視為錯誤。如果無法連上遠端服務，Service Broker 會保留該服務的訊息，直到可以連接該服務或對話存留時間過期為止。
對話存留時間
在對話存留時間期間內，訊息可以在應用程式間交換。對話的存留時間從本機 SQL Server 執行個體建立對話時開始，持續到應用程式明確結束對話或收到與對話相關聯的錯誤訊息為止。當應用程式接收到表示錯誤或交談結束的訊息時，每個參與者都可負責明確結束交談。在多數服務中，一個參與者會負責在不發生錯誤的情況下結束交談，表示交談成功完成。此動作是由目標還是起始端來完成，要視交談的目的而定。
當起始應用程式開始對話時，該應用程式的本機 Service Broker 會建立對話的交談端點。當執行個體收到對話的第一個訊息時，目標應用程式的本機 Service Broker 會建立對話的交談端點。
對話還可以保證交談的存留時間不超過指定的限制。起始應用程式可以選擇性地指定對話的存留時間上限。本機 Service Broker 和遠端 Service Broker 都會追蹤此存留時間。如果對話在到達存留時間上限時仍在使用中，則交談的每一端都會在服務佇列中排入一個逾時錯誤訊息，並拒絕對話的新訊息。交談決不會超過對話開始時建立的存留時間上限。請注意，雖然在交談結束之後，應用程式仍可以接收交談的訊息，但不會有該交談的新訊息到達。應用程式無法傳送有關該交談的訊息。
應用程式負責明確結束對話，表示它們已完成對話。Service Broker 永遠不會自動結束對話。對話會一直留在資料庫中，直到應用程式明確結束交談為止。因此，即使對話逾時或 Broker 報告錯誤，交談的每個參與者還是必須明確發出 END CONVERSATION 陳述式。
交談計時器
「交談計時器」可以讓應用程式在指定時間接收訊息。當交談計時器過期時，SQL Server 會將交談的訊息插入至交談的佇列，即啟動交談計時器的端點處。應用程式可以將交談計時器用於任何目的。常見的一種用途是回應遠端服務回應的延遲。另一常見用途是建立服務，以設定的間隔將訊息傳送至遠端服務。例如，服務可以使用交談計時器，每隔幾分鐘報告一次 SQL Server 目前的狀態。應用程式還可以使用交談計時器，在特定時間啟動預存程序。這可讓 Service Broker 支援排程的活動。
交談的每個參與者可以為每個交談設定一個交談計時器。交談計時器不會與其他參與者共用，也不會影響交談的存留時間。不過，當計時器過期時，本機 Service Broker 會在本機服務的佇列中加入一個逾時訊息。逾時訊息的類型名稱為 https://schemas.microsoft.com/SQL/ServiceBroker/DialogTimer