Condividi tramite

  • Articolo

Conversazioni di dialogo

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

I dialoghi consentono il recapito di messaggi inviati una sola volta rispettando l'ordine di invio e utilizzano l'identificatore di conversazione e i numeri di sequenza contenuti in ogni messaggio per identificare i messaggi correlati e recapitarli nell'ordine corretto. Un dialogo è costituito da un flusso di messaggi persistente e affidabile tra due servizi.

Una conversazione di dialogo ha due partecipanti. L'initiator inizia la conversazione. La destinazione accetta la conversazione avviata dall'initiator. Il fatto che un partecipante inizi la conversazione determina i messaggi che il partecipante stesso può inviare, in base a quanto specificato nel contratto della conversazione. Nella figura seguente viene illustrato il flusso di messaggi di un dialogo:

Flusso di messaggi tra initiator e database di destinazione

Nell'ambito del dialogo avviene uno scambio di messaggi tra applicazioni. Quando SQL Server riceve un messaggio, lo inserisce nella coda relativa al dialogo appropriato. L'applicazione riceve il messaggio dalla coda e lo elabora nel modo più opportuno. Durante l'elaborazione l'applicazione può inviare messaggi all'altro partecipante al dialogo.

Affidabilità del recapito

I dialoghi incorporano acknowledgement automatici di ricevuta dei messaggi per assicurare l'affidabilità del recapito. Service Broker salva ogni messaggio in uscita nella coda di trasmissione finché il messaggio non viene riconosciuto dal servizio remoto. Gli acknowledgement automatici consentono di risparmiare tempo e risorse. Permettono infatti di evitare l'acknowledgment esplicito di ogni messaggio ricevuto da parte delle applicazioni. Se possibile, i messaggi di acknowledgement vengono inclusi nei messaggi restituiti per il dialogo.

Nota

Service Broker gestisce internamente i messaggi di acknowledgement, che non vengono inseriti in alcuna coda e non vengono recapitati all'applicazione.

Service Broker non considera un errore l'impossibilità di raggiungere un servizio remoto. In questo caso, i messaggi per il servizio non raggiungibile vengono mantenuti da Service Broker finché il servizio non è di nuovo raggiungibile o la durata del dialogo non scade.

Lo scambio di messaggi tra applicazioni è possibile per tutta la durata del dialogo, che inizia dal momento in cui il dialogo viene creato dall'istanza locale di SQL Server fino al momento in cui un'applicazione termina esplicitamente il dialogo o riceve un messaggio di errore associato al dialogo. Ogni partecipante è responsabile della conclusione esplicita della conversazione quando l'applicazione riceve un messaggio che indica un errore o la fine della conversazione stessa. Nella maggior parte dei servizi, a uno dei partecipanti è delegato il compito di terminare la conversazione senza errori, indicandone la conclusione. L'esecuzione di questa operazione da parte della destinazione o dell'initiator dipende dello scopo della conversazione.

L'istanza locale di Service Broker per l'applicazione di origine crea un endpoint di conversazione per il dialogo quando questo viene iniziato dall'applicazione. L'istanza locale di Service Broker per l'applicazione di destinazione crea un endpoint di conversazione per il dialogo quando l'istanza riceve il primo messaggio del dialogo.

È inoltre possibile stabilire che la durata di una conversazione non superi il limite specificato, indicando facoltativamente la durata massima per il dialogo tramite l'applicazione di origine. Sia l'istanza locale che l'istanza remota di Service Broker tengono traccia di tale durata. Quando un dialogo rimane attivo fino alla durata massima, ogni lato della conversazione inserisce un messaggio di errore di timeout nella coda del servizio e rifiuta eventuali nuovi messaggi relativi al dialogo. La durata delle conversazioni non supera mai il limite massimo stabilito all'inizio del dialogo. Si noti che un'applicazione può continuare a ricevere messaggi per una conversazione già terminata ma non può ricevere alcun nuovo messaggio né inviare messaggi relativi alla conversazione.

Alle applicazioni è delegato il compito di indicare il completamento di un dialogo terminandolo in modo esplicito. Service Broker non termina mai un dialogo automaticamente. Il dialogo rimane nel database fino alla conclusione esplicita della conversazione da parte di un'applicazione. Per questo motivo, anche in caso di timeout del dialogo o di errore segnalato da Service Broker, ogni partecipante alla conversazione deve generare esplicitamente l'istruzione END CONVERSATION.

Timer di conversazione

Un timer di conversazione consente alle applicazioni la ricezione di un messaggio a un'ora specifica. Quando il timer di conversazione scade, SQL Server inserisce un messaggio nella coda della conversazione in corrispondenza dell'endpoint di avvio del timer di conversazione. Un'applicazione può utilizzare il timer di conversazione per qualsiasi scopo, ad esempio per gestire i ritardi nelle risposte dal servizio remoto oppure per creare un servizio per l'invio di messaggi al servizio remoto a intervalli predefiniti. 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 inoltre utilizzare un timer di conversazione per attivare una stored procedure a una certa ora. In questo modo Service Broker è in grado di supportare attività pianificate.

Ogni partecipante a una conversazione può impostare un solo timer per conversazione. Il timer non viene condiviso con l'altro partecipante e non influisce sulla durata della conversazione. Al contrario, alla scadenza del timer l'istanza locale di Service Broker aggiunge un messaggio di timeout alla coda del servizio locale. Il nome del tipo di messaggio di timeout è https://schemas.microsoft.com/SQL/ServiceBroker/DialogTimer