Scegliere se usare i messaggi o gli eventi
Si supponga di pianificare l'architettura di un'applicazione distribuita per la condivisione di musica. È necessario assicurarsi che l'applicazione sia il più possibile affidabile e scalabile e si prevede di usare tecnologie di Azure per creare un'infrastruttura di comunicazione solida.
Prima di poter scegliere la tecnologia di Azure corretta, è necessario conoscere ogni singola comunicazione che si scambiano i componenti dell'applicazione. Per ogni tipo di comunicazione, è possibile scegliere una diversa tecnologia di Azure.
La prima cosa da capire per una comunicazione è se invia messaggi o eventi. Questa informazione aiuta a scegliere il servizio di Azure appropriato da usare.
Strategie di comunicazione in Azure (API)
Che cos'è un messaggio?
Nella terminologia delle applicazioni distribuite, i messaggi hanno le caratteristiche seguenti:
- Un messaggio contiene dati non elaborati, generati da un componente e utilizzati da un altro.
- Un messaggio contiene i dati stessi, non solo un riferimento a tali dati.
- Il componente di invio si aspetta che il contenuto di destinazione elabori il contenuto del messaggio in un certo modo. L'integrità dell'intero sistema può dipendere dal fatto che sia il mittente che il destinatario eseguano un processo specifico.
Ad esempio, si supponga che un utente carichi un nuovo brano con l'app per dispositivi mobili per la condivisione di musica. L'app per dispositivi mobili deve inviare tale brano all'API Web eseguita in Azure. Deve essere inviato il file multimediale del brano stesso, non solo un avviso che indica che è stato aggiunto un nuovo brano. L'app per dispositivi mobili prevede che l'API Web archivi il nuovo brano nel database e lo renda disponibile ad altri utenti. Ecco un esempio di messaggio.
Che cos'è un evento?
Gli eventi hanno un peso minore dei messaggi e vengono prevalentemente usati per le comunicazioni in broadcast. I componenti che inviano l'evento sono detti componenti di pubblicazione e i destinatari sono noti come sottoscrittori.
Con gli eventi, i componenti di ricezione decidono a quali comunicazioni sono interessati e sottoscrivono tali eventi. La sottoscrizione viene gestita da un intermediario, ad esempio Griglia di eventi di Azure o Hub eventi di Azure. Quando le entità di pubblicazione inviano un evento, l'intermediario lo instrada ai sottoscrittori interessati. Questo criterio è noto come "architettura di pubblicazione-sottoscrizione" ed è il modo più comune per gestire gli eventi, anche se non è l'unico.
Gli eventi hanno le caratteristiche seguenti:
- Un evento è una notifica leggera che indica che è accaduto qualcosa.
- L'evento può essere inviato a più destinatari o a nessuno.
- Gli eventi sono spesso destinati a una distribuzione estesa, ovvero hanno un numero elevato di sottoscrittori per ogni origine di pubblicazione.
- Il componente di pubblicazione dell'evento non ha aspettative sull'azione eseguita da un componente di ricezione.
- Alcuni eventi sono unità discrete e non correlate ad altri eventi.
- Alcuni eventi fanno parte di una serie ordinata e correlata.
Si supponga, ad esempio, che il caricamento del file musicale sia stato completato e che il nuovo brano sia stato aggiunto al database. Per informare gli utenti del nuovo file, l'API Web deve informare gli utenti del front-end Web e dell'app per dispositivi mobili del nuovo file. Gli utenti possono scegliere se ascoltare o meno il nuovo brano, quindi la notifica iniziale non include il file musicale ma si limita a informare gli utenti che il brano è disponibile. Il mittente non ha aspettative specifiche su quello che faranno i destinatari in risposta a questo evento.
Questo scenario è un esempio di evento discreto.
Come scegliere tra messaggi o eventi
È probabile che una singola applicazione usi gli eventi per certi scopi e i messaggi per altri. Prima di scegliere, è necessario analizzare l'architettura dell'applicazione e tutti i relativi casi d'uso per identificare tutti i diversi scopi che hanno i relativi componenti per comunicare tra loro.
Gli eventi vengono più probabilmente usati per le trasmissioni e sono spesso temporanei. Questo significa che la comunicazione potrebbe non essere gestita da alcun destinatario se nessuno ha effettuato la sottoscrizione. È più probabile che vengano usati i messaggi quando l'applicazione distribuita richiede una garanzia di elaborazione della comunicazione.
Per tutte le comunicazioni prendere in considerazione la domanda seguente: Il componente di invio si aspetta che la comunicazione venga elaborata in un modo specifico dal componente di destinazione?
Se la risposta è sì, scegliere di usare un messaggio. Se la risposta è no, si potrebbe riuscire a usare gli eventi.
Capire come devono comunicare i componenti sarà utile per scegliere le modalità. Si inizierà prima di tutto con i messaggi.