Protocolli di comunicazione di Service Broker
Service Broker utilizza un protocollo specifico per comunicare con le istanze remote di Service Broker. Le connessioni vengono gestite separatamente rispetto al normale pool di connessioni client. Per lo scambio di messaggi di Service Broker tra due istanze di SQL Server, è necessario che ogni istanza sia in grado di inviare traffico TCP/IP alla porta utilizzata dall'altra istanza per le comunicazioni di Service Broker. Per convenzione, per le comunicazioni tra istanze diverse di Service Broker viene in genere utilizzata la porta 4022. La porta effettivamente utilizzata, tuttavia, viene specificata al momento della creazione dell'endpoint.
Livelli del protocollo
Per le comunicazioni, in Service Broker viene adottato un approccio su più livelli. Ogni livello si basa sul livello sottostante per garantire l'affidabilità del recapito. Questo approccio consente alle applicazioni di operare senza conoscere la posizione del servizio remoto o il supporto fisico di trasporto utilizzato da Service Broker per le comunicazioni. Nella maggior parte dei casi, questi protocolli sono trasparenti per l'applicazione. È comunque utile comprendere il ruolo di ogni livello del protocollo per agevolare la risoluzione dei problemi di un'applicazione.
Il protocollo di livello più alto utilizzato da Service Broker è il protocollo di dialogo. Questo protocollo gestisce la trasmissione di messaggi in sequenza in modo da garantirne l'affidabilità. Il protocollo di dialogo genera numeri di sequenza per i messaggi e messaggi di acknowledgement, recapita i messaggi alle code appropriate e provvede alla frammentazione e al riassemblaggio dei messaggi. Gestisce inoltre l'autenticazione e la crittografia per il dialogo.
Per la trasmissione dei frammenti dei messaggi, il protocollo di dialogo utilizza il protocollo di Service Broker adiacente, che gestisce le trasmissioni di rete scambiate tra due istanze di Service Broker.
Il protocollo di Service Broker adiacente utilizza un protocollo di trasporto, ad esempio TCP/IP, per spostare i messaggi da un'istanza di Service Broker a un'altra.
Protocollo di dialogo
Per i messaggi di una conversazione il protocollo di dialogo gestisce il recapito di messaggi inviati una sola volta rispettando l'ordine di invio. Questo protocollo non descrive il formato utilizzato dai messaggi di Service Broker in rete, ma specifica i passaggi logici necessari per una conversazione affidabile. Il protocollo di dialogo gestisce le attività necessarie per garantire l'affidabilità del recapito, compresa la generazione e l'elaborazione dei messaggi di acknowledgement.
Ogni lato di una conversazione rappresenta un endpoint nel livello del protocollo di dialogo. Nella vista del catalogo sys.conversation_endpoints sono riportate informazioni sugli endpoint del protocollo di dialogo. Un endpoint di una conversazione ha una durata pari a quella della conversazione.
Protocollo di Service Broker adiacente
Il protocollo di Service Broker adiacente gestisce i meccanismi di comunicazione tra due istanze di SQL Server. Questo livello codifica ogni frammento di messaggio in un formato standard adatto per la trasmissione in rete. A differenza del livello del protocollo di dialogo, questo protocollo prevede la conoscenza del trasporto di rete utilizzato e la conseguente formattazione dei frammenti dei messaggi. In effetti, il livello del protocollo di Service Broker adiacente rappresenta un livello di astrazione tra il livello del protocollo di dialogo e il livello del protocollo di trasporto.
Ogni connessione di rete di Service Broker costituisce un endpoint nel livello del protocollo adiacente. La vista a gestione dinamica sys.dm_broker_connections contiene le informazioni sulle connessioni di rete di Service Broker. Service Broker gestisce la connessione di rete durante lo scambio attivo dei messaggi. Service Broker chiude la connessione di rete quando non vengono inviati o ricevuto messaggi tramite la connessione di rete per un breve intervallo di tempo.
Protocollo di trasporto
Il livello del protocollo di trasporto gestisce la trasmissione di rete vera e propria. Questo livello è esterno a Service Broker. I messaggi destinati a un'istanza di Service Broker in esecuzione in un'altra istanza di SQL Server, ad esempio, utilizzano il protocollo TCP/IP come livello di protocollo di trasporto.
Gli endpoint di Service Broker specificano le opzioni per il protocollo di trasporto. Per impostazione predefinita, SQL Server non contiene endpoint di Service Broker. Per ulteriori informazioni sulla creazione di un endpoint di Service Broker, vedere Procedura: Attivazione delle funzionalità di rete di Service Broker (Transact-SQL).
Elaborazione dei messaggi di Service Broker
Service Broker utilizza due categorie distinte di messaggi: i messaggi in sequenza, ovvero i messaggi che devono essere recapitati a un'applicazione una sola volta e rispettando l'ordine di invio, e i messaggi non in sequenza, ovvero i messaggi che possono essere elaborati immediatamente, indipendentemente dalla sequenza di arrivo.
I messaggi in sequenza vengono utilizzati da Service Broker per tutti i tipi di messaggi definiti dall'utente, i messaggi di fine dialogo e i messaggi di errore generati da un'applicazione. Ad ogni messaggio in sequenza è associato un numero di sequenza. Il numero di sequenza del messaggio viene creato e assegnato al messaggio dall'istanza di origine del messaggio stesso. L'istanza di Service Broker ricevente ordina i messaggi inviati a un'applicazione utilizzando il numero di sequenza dei messaggi stessi. Per ogni dialogo, il messaggio con il numero di sequenza inferiore viene sempre recapitato per primo all'applicazione. Il numero di sequenza dei messaggi viene utilizzato da Service Broker anche per individuare i messaggi duplicati. Quando il livello del protocollo di dialogo riceve due messaggi con lo stesso numero di sequenza nello stesso dialogo, i messaggi vengono considerati duplicati e uno viene scartato.
I messaggi non in sequenza vengono utilizzati da Service Broker per i messaggi di acknowledgement dedicati e i messaggi di errore generati da Service Broker. In Service Broker non vengono adottate precauzioni particolari per il recapito di un messaggio non in sequenza. Si noti, tuttavia, che i messaggi non in sequenza vengono creati da Service Broker in risposta ai messaggi in arrivo. Pertanto, in caso di perdita del messaggio non in sequenza, il mittente invia nuovamente il messaggio originale e il destinatario genera un altro messaggio non in sequenza.
Frammentazione dei messaggi
Service Broker suddivide in frammenti i messaggi in uscita e combina i frammenti in arrivo per ricostruire il messaggio originale. I messaggi di piccole dimensioni sono contenuti in un unico frammento mentre quelli di grandi dimensioni vengono suddivisi da Service Broker in numerosi frammenti.
La frammentazione dei messaggi presenta molteplici vantaggi. L'invio di un messaggio di grandi dimensioni suddiviso in piccoli frammenti determina un incremento della velocità complessiva e dell'affidabilità delle comunicazioni su reti relativamente lente e non affidabili, ad esempio le reti WAN. In caso di perdita di un frammento, viene ritrasmesso solo quel frammento particolare anziché l'intero messaggio. La suddivisione in frammenti dei messaggi di grandi dimensioni consente inoltre di ridurre il tempo necessario affinché un messaggio di piccole dimensioni raggiunga la destinazione. Service Broker consente di inviare un frammento contenente un messaggio completo di piccole dimensioni tra frammenti di un messaggio di grandi dimensioni. Questo comporta un lieve rallentamento del messaggio di grandi dimensioni ma consente di ridurre il tempo di attesa per la trasmissione del messaggio più piccolo.
Mentre un messaggio viene riassemblato, il messaggio parziale viene archiviato nella coda di destinazione. Se la coda di destinazione non è disponibile, viene archiviato nella coda di trasmissione. Un'applicazione non può ricevere un messaggio parziale. La colonna status di un messaggio parziale è impostata su 2 (disattivato). Questo valore viene inoltre utilizzato per i messaggi non ricevuti secondo l'ordine previsto.
Acknowledgement dei messaggi
Service Broker invia un acknowledgment per ogni messaggio ricevuto. Un acknowledgement può riguardare uno o più frammenti di messaggio. Se possibile, l'acknowledgement viene incluso nell'intestazione di un altro messaggio inviato nella stessa conversazione. Se non vi sono altri messaggi pronti per l'invio, Service Broker restituisce un messaggio di acknowledgement dedicato. L'acknowledgement dei messaggi viene gestito interamente da Service Broker. Questi messaggi non vengono ricevuti da un'applicazione che utilizza Service Broker.
I frammenti di messaggi per i quali il destinatario non ha inviato un acknowledgement vengono mantenuti dal mittente. Se non perviene alcun messaggio di acknowledgement per un periodo di tempo definito dal sistema, il mittente invia nuovamente il frammento di messaggio. Se durante il periodo di attesa non viene ricevuto alcun messaggio di acknowledgement, Service Broker aumenta in modo esponenziale il tempo di attesa prima del tentativo successivo, fino a raggiungere un limite massimo. Il tempo di attesa iniziale prima di un ulteriore tentativo corrisponde ad alcuni secondi. Il tempo di attesa massimo corrisponde a circa un minuto. Si noti che il tempo di attesa non deve necessariamente essere preciso. È infatti possibile che, in funzione del traffico di rete e di altre attività nell'istanza di SQL Server, un nuovo tentativo di invio di un frammento di messaggio venga prorogato di alcuni secondi dopo la scadenza del tempo di attesa.
In caso di perdita o di ritardo di un acknowledgement, il destinatario può ricevere messaggi duplicati. In questo caso, il destinatario invia l'acknowledgement del messaggio duplicato ma non recapita il messaggio duplicato alla coda.
Service Broker utilizza l'acknowledgement dei messaggi per garantire l'affidabilità della messaggistica senza transazioni distribuite. Il destinatario invia un acknowledgement solo dopo avere aggiunto il messaggio o il frammento alla coda. Il mittente mantiene il messaggio nella coda di trasmissione finché non riceve il relativo acknowledgement. Il mittente e il destinatario non condividono mai una transazione. Il protocollo garantisce, tuttavia, che il messaggio non venga rimosso dalla coda di trasmissione del mittente finché non giunge al destinatario.
Controllo dell'integrità dei messaggi
Il formato utilizzato da Service Broker per la trasmissione dei messaggi include il controllo dell'integrità per stabilire se un determinato messaggio ha subito modifiche o danneggiamenti durante il trasporto.
Il controllo dell'integrità dei messaggi è costituito da una firma MD5 per il contenuto del messaggio. La firma viene crittografata da SQL Server con la chiave della sessione per il messaggio e viene inclusa nelle intestazioni del messaggio.
Il destinatario decrittografa il messaggio, quindi confronta la firma nel messaggio con una nuova firma calcolata in base al contenuto effettivo ricevuto. Se le firme non corrispondono, il messaggio è stato danneggiato o manomesso durante la trasmissione. Il controllo di integrità ha quindi esito negativo. SQL Server elimina il messaggio e non invia l'acknowledgement al mittente. Quando un messaggio non supera il controllo di integrità, le relative informazioni vengono visualizzate nella classe di evento Broker:Corrupted Message.
Oggetti di trasmissione di Service Broker
Un oggetto di trasmissione di Service Broker è un oggetto in memoria che consente di gestire e registrare lo stato delle trasmissioni dei messaggi per un dialogo. Ogni endpoint di conversazione dispone di un oggetto di trasmissione.
Un dialogo richiede un oggetto di trasmissione quando vengono eseguite le operazioni seguenti:
Invio di un messaggio tramite la coda di trasmissione. Sono inclusi i messaggi seguenti:
Tutti i messaggi inviati a un'istanza remota di Motore di database
Messaggi a code inviate nell'istanza locale se non è possibile inserirli direttamente nella coda di destinazione
Ricezione di un messaggio remoto o di un messaggio proveniente da una coda di trasmissione locale.
Un oggetto di trasmissione viene creato la prima volta che viene richiesto da un dialogo. Service Broker utilizza lo stesso oggetto di trasmissione per le richieste successive di tale dialogo. Gli oggetti di trasmissione vengono modificati ogni volta che Service Broker deve registrare una modifica nello stato della trasmissione per il dialogo. Gli oggetti di trasmissione hanno una dimensione approssimativa di 1 KB.
Per liberare memoria, tramite Service Broker vengono periodicamente archiviati batch di oggetti di trasmissione inattivi nelle tabelle di lavoro di tempdb. Quando un oggetto di trasmissione viene modificato per la prima volta in memoria, viene contrassegnato come dirty. L'oggetto di trasmissione rimane contrassegnato in questo modo fino a quando non viene scaricato in una tabella di lavoro.
Gli oggetti di trasmissione non vengono utilizzati per l'invio o la ricezione di messaggi locali che possono essere inseriti direttamente nella coda di destinazione.
Flusso delle comunicazioni di rete
Nella figura seguente viene illustrata una vista di alto livello delle comunicazioni di rete di Service Broker tra due istanze di SQL Server.
.gif "Comunicazioni di rete di Service Broker tra due istanze")
Si noti che la conversazione è una connessione logica persistente. La conversazione può protrarsi per qualsiasi intervallo di tempo, nel corso del quale può utilizzare un numero qualsiasi di connessioni di rete.
Tra due endpoint di Service Broker vengono stabilite connessioni di rete che utilizzano il protocollo TCP/IP. In caso di inattività della connessione per un breve intervallo di tempo, SQL Server chiude la connessione di rete.
Per recapitare un messaggio, Service Broker lo mantiene nella coda di trasmissione per il database che l'ha inviato. Il destinatario recapita il messaggio direttamente alla coda per il servizio di destinazione. Se la coda non è attiva, il messaggio viene mantenuto temporaneamente nella coda di trasmissione per il database di destinazione. La coda per il servizio di invio non è coinvolta nell'operazione. La coda di trasmissione per il database che ospita il servizio di destinazione è coinvolta solo se la coda di destinazione non è attiva.