Creazione di tipi di messaggi di Service Broker
Un tipo di messaggio definisce il nome di un tipo di messaggio specifico e la convalida che Service Broker esegue su tale tipo. Per determinare i tipi di messaggi che l'applicazione utilizzerà, è necessario pianificare innanzitutto le attività che l'applicazione deve eseguire e i dati necessari per eseguire ogni attività.
L'approccio più comune per un'applicazione è quello di strutturare i messaggi in modo che ogni messaggio includa le informazioni necessarie per un passaggio dell'attività. Quando ogni messaggio contiene le informazioni per un passaggio dell'attività, l'applicazione può ricevere facilmente il messaggio, completare il passaggio e inviare una risposta all'interno di una singola transazione. Di conseguenza per molte applicazioni il modo più semplice per determinare i tipi di messaggi e il contenuto del messaggio è quello di stabilire i limiti della transazione per le attività eseguite dall'applicazione stessa. Ogni passaggio distinto è una transazione e ogni transazione corrisponde a un tipo di messaggio scambiato tra i servizi. Altri tipi di messaggi sono rappresentati inoltre dalle informazioni sullo stato, dai risultati oppure dall'output.
I protocolli di comunicazioni di Service Broker sono progettati per funzionare con questo stile di messaggistica. Il protocollo di dialogo frammenta i messaggi di grandi dimensioni per il transito e garantisce che tali messaggi non impediscano la trasmissione di quelli di dimensioni ridotte.
Scelta di un tipo di convalida
La convalida specificata per il messaggio dipende dal contenuto del messaggio stesso. Una pratica comune è quella di utilizzare la convalida più restrittiva disponibile durante le operazioni di testing e quella meno restrittiva durante la distribuzione dell'applicazione per migliorare le prestazioni. È possibile ad esempio scambiare un documento XML tipizzato come il corpo di un messaggio che specifica una convalida di tipo NONE. In questo caso, l'applicazione convalida il messaggio durante l'elaborazione del codice XML.
Poiché il formato di rete per un messaggio include il nome del tipo di messaggio, i nomi dei tipi di messaggi vengono spesso scelti per evitare problemi relativi alle regole di confronto e conflitti di denominazione. Per ulteriori informazioni sulla denominazione, vedere Denominazione di oggetti di Service Broker.
Indicazione dell'esito positivo o negativo di un'operazione
Un'applicazione in genere non definisce nuovi tipi di messaggi per indicare l'esito positivo o negativo di un'operazione. È necessario utilizzare l'istruzione END CONVERSATION per indicare che la conversazione è completata e che l'attività ha avuto esito positivo. Se l'attività ha avuto esito negativo, includere l'opzione WITH ERROR per restituire un messaggio di errore nella conversazione.
In generale solo uno dei partecipanti alla conversazione deve terminare la conversazione quando l'attività è completata, mentre l'altro partecipante deve inviare solo un'istruzione END CONVERSATION in risposta a un messaggio End Dialog o Error. Nella documentazione per un servizio in genere viene specificato il partecipante che termina la conversazione quando quest'ultima è stata completata correttamente. La disponibilità di questa informazione consente di evitare che si verifichino problemi nel caso in cui nessun partecipante termini la conversazione o nel caso in cui un partecipante termini la conversazione mentre l'altro sta ancora eseguendo attività. Entrambi gli endpoint devono essere in grado di elaborare messaggi di errore poiché i messaggi interni di Service Broker vengono recapitati a entrambi gli endpoint. Se la durata del dialogo ad esempio scade prima che il dialogo sia chiuso, entrambi gli endpoint ricevono un messaggio di errore di Service Broker.
Entrambi i partecipanti possono terminare una conversazione restituendo un errore in qualsiasi momento. Per ulteriori informazioni sulla gestione dei messaggi di errore di Service Broker, vedere Gestione dei messaggi di errore di Service Broker.
Vedere anche