對話交談
Service Broker 傳送的所有訊息都是交談的一部份。對話是兩個服務之間的交談。對話是兩個服務間可靠而永續性的雙向訊息資料流。
對話提供精確單次循序 (EOIO) 訊息傳遞。它會使用每個訊息中包含的交談識別碼和序號,來識別相關訊息並按正確的順序傳遞訊息。對話是兩個服務間可靠而永續性的訊息資料流。
對話交談有兩個參與者。「起始端」(Initiator) 會開始交談。「目標」則接受起始端開始的交談。如交談合約所指定,參與者是否開始交談,決定著參與者可以傳送的訊息。下圖顯示對話的訊息流程:
應用程式會作為對話的一部份來交換訊息。當 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
請參閱
概念
其他資源
BEGIN DIALOG CONVERSATION (Transact-SQL)
BEGIN CONVERSATION TIMER (Transact-SQL)
END CONVERSATION (Transact-SQL)
SEND (Transact-SQL)
RECEIVE (Transact-SQL)
sys.transmission_queue (Transact-SQL)