Condividi tramite

  • Articolo

Creazione di applicazioni mediante Service Broker

Service Broker può essere utilizzato da qualsiasi programma in grado di eseguire istruzioni Transact-SQL. Un'applicazione di Service Broker può essere implementata come programma in esecuzione all'esterno di SQL Server o come stored procedure in linguaggio Transact-SQL o .NET.

Un programma che utilizza Service Broker è costituito di solito da un numero di componenti che interagiscono per svolgere un'attività. Un programma che inizia una conversazione crea e invia un messaggio a un altro servizio, può attendere una risposta o chiudersi immediatamente, utilizzando un altro programma per elaborare la risposta. Il programma riceve un messaggio in arrivo dalla coda del servizio di destinazione di una conversazione, legge i dati del messaggio, esegue l'elaborazione necessaria e quindi crea e invia il messaggio di risposta appropriato, se necessario.

Service Broker estende Transact-SQL. Per l'utilizzo con Service Broker un'applicazione non deve necessariamente disporre di una libreria o di un modello di oggetti particolare. ma invia una serie di comandi Transact-SQL a SQL Server ed elabora i risultati di tali comandi. Un'applicazione può essere attivata da Service Broker, essere eseguita come servizio in background o come processo pianificato o può essere avviata in risposta a un evento. Per ulteriori informazioni sulle strategie di avvio di un'applicazione che utilizza Service Broker, vedere Scelta di una strategia di avvio.

Per informazioni sulla creazione di applicazioni con Service Broker, vedere Vantaggi della programmazione con Service Broker.

Panoramica delle applicazioni di Service Broker

Nella figura seguente viene illustrata l'interazione che si verifica all'interno di un'applicazione che utilizza Service Broker:

Relazioni e flusso di messaggi nelle conversazioni

Come illustrato nella figura, vengono creati innanzitutto i tipi di messaggi SubmitExpense, AcceptDenyExpense e ReimbursementIssued. In base a questi tipi di messaggi viene creato il contratto ProcessExpenses e viene fornito uno schema per impostare il completamento di un'attività di rimborso spese mediante una conversazione. Il contratto ProcessExpenses regola tutte le conversazioni tra il servizio ProcessExpense e il servizio SubmitExpense. Il contratto ProcessExpenses e i tipi di messaggi utilizzati devono esistere nei database di tutti i servizi con conversazioni basate su questo contratto.

Service Broker archivia i messaggi inviati al servizio SubmitExpense nella coda di quest'ultimo. La stored procedure ExpenseSubmission riceve i messaggi dalla coda in questione, li elabora e, se è necessaria una risposta, li invia a un altro servizio.

Service Broker archivia i messaggi inviati al servizio ProcessExpense nella coda di quest'ultimo. La stored procedure ExpenseProcessing riceve i messaggi dalla coda in questione, li elabora e, se è necessaria una risposta, li invia a un altro servizio.

Una conversazione tra questi due servizi sarebbe strutturata come segue:

  • Un utente invia una richiesta di rimborso spese mediante un'interfaccia utente. L'applicazione esegue la stored procedure ExpenseSubmission che crea un messaggio SubmitExpense. Il servizio SubmitExpense avvia una conversazione con il servizio ProcessExpense e quindi invia il messaggio SubmitExpense al servizio ProcessExpense.

  • Service Broker riceve il messaggio SubmitExpense per il servizio ProcessExpense e inserisce il messaggio nella coda ExpenseQueue. La coda ExpenseQueue attiva la stored procedure ProcessExpense che annulla l'accodamento del messaggio SubmitExpense e lo elabora. La stored procedure ProcessExpense crea quindi un messaggio AcceptDenyExpense e lo invia al servizio SubmitExpense. Se viene negata l'autorizzazione al rimborso spese, la stored procedure ProcessExpense termina la conversazione.

  • Service Broker inserisce il messaggio AcceptDenyExpense per il servizio SubmitExpense nella coda di quest'ultimo. Se la stored procedure ProcessExpense termina la conversazione, Service Broker inserisce un messaggio EndDialog nella coda Expenses. La coda attiva la stored procedure ExpenseSubmission che annulla l'accodamento del messaggio AcceptDenyExpense e lo elabora. Se la stored procedure ExpenseSubmission individua un messaggio EndDialog nella coda, termina la conversazione.

  • Se la richiesta di rimborso spese viene accettata, il servizio ProcessExpense crea e invia un messaggio ReimbursementIssued con la conferma dell'emissione del pagamento della spesa e quindi termina la conversazione. Service Broker inserisce questi messaggi nella coda del servizio. La coda attiva la stored procedure ExpenseSubmission che elabora il messaggio ReimbursementIssued. La stored procedure elabora quindi il messaggio EndDialog e termina la conversazione.