Conversazioni di dialogo

Si applica a:SQL ServerIstanza gestita di SQL di Azure

Tutti i messaggi inviati da Service Broker fanno parte di una conversazione. Un dialogo è una conversazione tra due servizi. Un dialogo è un flusso bidirezionale affidabile e permanente di messaggi tra due servizi.

I dialoghi garantiscono la consegna dei messaggi una sola volta e nell'ordine corretto (EOIO). I dialoghi usano l'identificatore di conversazione e i numeri di sequenza contenuti in ogni messaggio per identificare i messaggi correlati e recapitare i messaggi nell'ordine corretto. Un dialogo è un flusso affidabile e permanente di messaggi tra due servizi.

Una conversazione di dialogo ha due partecipanti. L'iniziatore avvia la conversazione. Il destinatario accetta una conversazione avviata dall'iniziatore. Il fatto che un partecipante inizi la conversazione determina i messaggi che il partecipante può inviare, come specificato nel contratto della conversazione. Il seguente diagramma mostra il flusso dei messaggi in un dialogo:

Le applicazioni si scambiano messaggi come parte del dialogo. Quando riceve un messaggio per un dialogo, SQL Server lo inserisce nella coda relativa al dialogo. L'applicazione riceve il messaggio dalla coda ed elabora il messaggio in base alle esigenze. Durante l'elaborazione, l'applicazione potrebbe inviare messaggi all'altro partecipante del dialogo.

Recapito affidabile

Le finestre di dialogo includono riconoscimenti automatici per la ricezione dei messaggi per garantire un recapito affidabile. Service Broker salva ogni messaggio in uscita nella coda di trasmissione fino a quando non riceve l’acknowledgment del messaggio da parte del servizio remoto. Gli acknowledgment automatici consentono di risparmiare tempo e risorse. Permettono infatti di evitare che un’applicazione debba inviare l'acknowledgment esplicito di ogni messaggio. Ove possibile, i messaggi di conferma sono inclusi nei messaggi di risposta della finestra di dialogo.

Durata del dialogo

I messaggi possono essere scambiati tra applicazioni durante il ciclo di vita del dialogo. La durata di un dialogo va dal momento in cui il dialogo viene creato dall'istanza locale di SQL Server fino a quando un'applicazione termina esplicitamente il dialogo o riceve un messaggio di errore associato al dialogo. Ogni partecipante è responsabile di terminare in modo esplicito la conversazione quando l'applicazione riceve un messaggio che indica un errore o la fine della conversazione. Nella maggior parte dei servizi, un partecipante è responsabile di indicare che la conversazione è completa e ha esito positivo, chiudendo la conversazione senza errori. Se questa operazione viene eseguita dal target o dall'iniziatore dipende dallo scopo della conversazione.

Il Service Broker locale per un'applicazione che avvia il dialogo crea un endpoint di conversazione per il dialogo quando l'applicazione avvia il dialogo. Il Service Broker locale dell'applicazione di destinazione crea un endpoint di conversazione per tale dialogo quando l'istanza riceve il primo messaggio in tale dialogo.

I dialoghi possono anche garantire che la durata di una conversazione non superi un limite specificato. L'applicazione di avvio può facoltativamente specificare una durata massima di dialogo. Sia il Service Broker locale che il Service Broker remoto tengono traccia di questo periodo di validità. Quando una finestra di dialogo rimane attiva alla durata massima, ogni lato della conversazione inserisce un messaggio di errore di timeout nella coda del servizio e rifiuta nuovi messaggi per la finestra di dialogo. Le conversazioni non vivono mai oltre la durata massima stabilita all'avvio del dialogo. Mentre un'applicazione può comunque ricevere messaggi per la conversazione al termine della conversazione, non è possibile che vengano ricevuti nuovi messaggi per tale conversazione. L'applicazione non può inviare messaggi sulla conversazione.

Le applicazioni sono responsabili dell'indicazione del termine di una finestra di dialogo terminando in modo esplicito il dialogo. Service Broker non termina mai un dialogo automaticamente. Il dialogo rimane nel database fino a quando un'applicazione non termina esplicitamente la conversazione. Pertanto, anche quando si verifica il timeout del dialogo o il broker segnala un errore, ogni partecipante della conversazione deve emettere in modo esplicito l'istruzione END CONVERSATION .

Timer della conversazione

Un timer di conversazione consente a un'applicazione di ricevere un messaggio in un momento specifico. Quando il timer della conversazione scade, SQL Server inserisce un messaggio per la conversazione nella coda per la conversazione nell'endpoint che ha avviato il timer della conversazione. Un'applicazione può usare un timer di conversazione per qualsiasi scopo. Il timer di conversazione viene usato comunemente, ad esempio, per rispondere ai ritardi nelle risposte del servizio remoto. o per creare un servizio che invia messaggi al servizio remoto a intervalli prestabiliti. Un servizio può, ad esempio, utilizzare un timer di conversazione per segnalare lo stato corrente di SQL Server a intervalli di alcuni minuti. Le applicazioni possono anche usare un timer di conversazione per attivare una stored procedure in un determinato momento. In questo modo Service Broker è in grado di supportare attività pianificate.

Ciascun partecipante di una conversazione può impostare un timer di conversazione per ogni conversazione. Il timer della conversazione non viene condiviso con l'altro partecipante e il timer della conversazione non influisce sulla durata della conversazione. Invece, alla scadenza del timer, il Service Broker locale aggiunge un messaggio di timeout alla coda del servizio locale. Un messaggio di timeout ha il nome del tipo https://schemas.microsoft.com/SQL/ServiceBroker/DialogTimer

Contenuti correlati

• 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)
• Messaggi di sistema broker