Informazioni su code, argomenti e sottoscrizioni del bus di servizio
Le entità di messaggistica che costituiscono le funzionalità di messaggistica di base nel bus di servizio sono code, argomenti e sottoscrizioni e regole/azioni.
Code
Le code consentono un recapito dei messaggi di tipo FIFO (First In, First Out) a uno o più consumer concorrenti. Ovvero, i destinatari in genere ricevono ed elaborano i messaggi nell'ordine in cui sono stati aggiunti alla coda. Inoltre, un solo consumer di messaggi riceve ed elabora ogni messaggio. Poiché i messaggi vengono archiviati in modo permanente nella coda, i producer (mittenti) e i consumer (destinatari) non devono elaborare i messaggi contemporaneamente.
Un vantaggio correlato è quello del livellamento del carico, che permette ai producer e ai consumer di inviare e ricevere i messaggi a velocità diverse. In molte applicazioni, il carico del sistema varia nel tempo. Tuttavia, il tempo di elaborazione necessario per ogni unità di lavoro normalmente è costante. L'intermediazione di producer e consumer di messaggi con una coda significa che l'applicazione consumer deve essere solo in grado di gestire il carico medio anziché i picchi di carico.
L'uso di code per l'intermediazione tra producer e consumer di messaggi fornisce un accoppiamento intrinseco libero tra i componenti. Poiché i producer e i consumer non sono a conoscenza l'uno dell'altro, un consumer può essere aggiornato senza alcun effetto sul producer.
È possibile creare code usando i modelli del portale di Azure, di PowerShell, dell'interfaccia della riga di comando o di Resource Manager. Inviare e ricevere quindi i messaggi usando i client scritti in C#, Java, Python e JavaScript.
Modalità di ricezione
È possibile specificare due modalità diverse in cui il bus di servizio riceve i messaggi: Ricezione ed eliminazione o Blocco di visualizzazione.
Ricezione ed eliminazione
In questa modalità, quando il bus di servizio riceve la richiesta dal consumer, contrassegna il messaggio come utilizzato e lo restituisce all'applicazione consumer. Questa modalità è il modello più semplice ed è adatta per scenari in cui l'applicazione può tollerare la mancata elaborazione di un messaggio in caso di errore. Si consideri, ad esempio, uno scenario in cui il consumer invia la richiesta di ricezione e quindi si arresta in modo anomalo prima dell'elaborazione. Appena il bus di servizio contrassegna il messaggio come utilizzato, l'applicazione inizia a utilizzare i messaggi al riavvio. Il messaggio utilizzato prima dell'arresto anomalo viene perso.
Blocco di visualizzazione
In questa modalità il processo di ricezione diventa un'operazione in due fasi, che rende possibile il supporto di applicazioni che non sono in grado di tollerare messaggi mancanti.
Trova il messaggio successivo da consumare, lo blocca per impedire ad altri consumer di riceverlo e lo restituisce all'applicazione.
Al termine dell'elaborazione del messaggio, l'applicazione richiede al bus di servizio di completare la seconda fase del processo di ricezione. Quindi, il servizio contrassegna il messaggio come utilizzato.
Se l'applicazione non è in grado di elaborare il messaggio per qualche motivo, può richiedere al bus di servizio di abbandonare il messaggio. Il bus di servizio sblocca il messaggio e lo rende disponibile per essere nuovamente ricevuto dallo stesso consumer o da un altro consumer concorrente. In secondo luogo, è presente un timeout associato al blocco. Se l'applicazione non riesce a elaborare il messaggio prima della scadenza del timeout del blocco, il bus di servizio sblocca automaticamente il messaggio rendendolo nuovamente disponibile per la ricezione.
Argomenti e sottoscrizioni
Una coda consente l'elaborazione di un messaggio da parte di un singolo consumer. A differenza delle code, gli argomenti e le sottoscrizioni consentono di eseguire una comunicazione uno-a-molti, secondo un modello di pubblicazione e sottoscrizione. È utile per il ridimensionamento a un numero elevato di destinatari. Ogni messaggio pubblicato viene reso disponibile per ogni sottoscrizione registrata con l'argomento. Il server di pubblicazione invia un messaggio a un argomento e uno o più sottoscrittori ricevono una copia del messaggio, in base alle regole di filtro impostate per queste sottoscrizioni. Per limitare i messaggi da ricevere, le sottoscrizioni possono usare altri filtri.
I server di pubblicazione inviano messaggi a un argomento nello stesso modo in cui inviano messaggi a una coda. Tuttavia, i consumer non ricevono messaggi direttamente dall'argomento. I consumer ricevono invece i messaggi dalle sottoscrizioni dell'argomento. Una sottoscrizione dell'argomento è simile a una coda virtuale che riceve copie dei messaggi inviati all'argomento. I consumer ricevono messaggi da una sottoscrizione in modo identico al modo in cui ricevono messaggi da una coda.
La procedura per la creazione di un argomento è simile a quella per la creazione di una coda, descritta nella sezione precedente. È possibile creare argomenti e sottoscrizioni usando i modelli del portale di Azure, di PowerShell, dell'interfaccia della riga di comando o di Resource Manager. Inviare quindi messaggi a un argomento e ricevere messaggi dalle sottoscrizioni usando i client scritti in C#, Java, Python e JavaScript.
Regole e azioni
In molti scenari, i messaggi con caratteristiche specifiche devono essere elaborati in modi specifici. Per abilitare questa elaborazione, è possibile configurare le sottoscrizioni in modo che trovino i messaggi che presentano le proprietà desiderate e apportare quindi alcune modifiche a tali proprietà. Mentre nelle sottoscrizioni del bus di servizio tutti i messaggi vengono inviati all'argomento, l'utente può copiare solo un subset di tali messaggi nella coda virtuale delle sottoscrizioni. Questo filtraggio viene eseguito usando i filtri della sottoscrizione. Queste modifiche sono chiamate azioni di filtro. Quando viene creata una sottoscrizione, è possibile specificare un'espressione filtro che opera sulle proprietà del messaggio. Le proprietà possono essere sia proprietà di sistema (ad esempio, Label) che proprietà personalizzate dell'applicazione (ad esempio StoreName). In questo caso, l'espressione filtro SQL è facoltativa. Senza un'espressione filtro SQL, qualsiasi azione di filtro definita in una sottoscrizione viene eseguita su tutti i messaggi di tale sottoscrizione.