Progettiamo qualcosa di concreto

Ipotizziamo che per la nostra applicazione Quarkus sia richiesta la capacità di poter memorizzare le richieste/risposte JAX-RS (Java API for RESTful Web Services) che essa riceve. È inoltre richiesto che queste informazioni possano essere memorizzate su diversi supporti, come per esempio database SQL, database NoSQL o una coda AMQP (Advanced Message Queuing Protocol).

Al fine di rendere più chiaro il requisito, a seguire è illustrato il diagramma che mostra come dovrà essere il flusso dell’applicazione, i componenti interessati e loro relazioni.

Figure 1. Diagramma 2 - Flusso dell’applicazione Quarkus per lo storage delle richieste JAX-RS

Stando al Diagramma 2, le richieste HTTP (verso i servizi REST) provenienti per esempio da utenti, dispositivi mobili, browser web o qualunque altro tipo di client, sono intercettate ed elaborate dal filtro JAX-RS e successivamente pubblicate sull’Event Bus. I Consumer ricevono gli eventi per cui hanno la sottoscrizione, inviandoli poi, a seconda della configurazione e delle esigenze dell’applicazione, verso il Database SQL, Database NoSQL e la coda AMQP.

Ricordiamo che il filtro JAX-RS oltre a processare la request, processerà anche la response, motivo per cui gli eventi pubblicati sull’Event Bus saranno sia per la request sia per la response, di conseguenza ci saranno i rispettivi consumer. Il diagramma di sequenza a seguire aiuterà a capire meglio il ruolo del filtro JAX-RS.

*Diagramma 3* - Sequenza che illustra il flusso di dati attraverso un filtro JAX-RS all’interno dell’applicazione quando viene effettuata una richiesta da un client

Figure 2. Diagramma 3 - Sequenza che illustra il flusso di dati attraverso un filtro JAX-RS all’interno dell’applicazione quando viene effettuata una richiesta da un client

Il diagramma di sequenza precedente mostra il flusso di dati attraverso un filtro JAX-RS all’interno dell’applicazione quando viene effettuata una richiesta da un client.

Il Client effettua una richiesta all’applicazione.
L’applicazione, ricevendo la richiesta, la passa attraverso il Filter JAX-RS.
Il Filter JAX-RS inoltra la richiesta al Resource Endpoint appropriato.
Il Resource Endpoint elabora la richiesta e invia una risposta.
Il Filter JAX-RS riceve la risposta dal Resource Endpoint e la passa indietro all’applicazione.
Infine, l’applicazione invia la risposta al Client.

Il diagramma di sequenza a seguire aggiunge l’Event Bus e su questo sono pubblicati dal filtro JAX-RS i messaggi di richiesta e i messaggi di risposta (vedi step 4 e step 8) del servizio JAX-RS chiamato.

Figure 3. Diagramma 4 - Estensione del diagramma precendente con l’aggiunta delle interazioni con l’Event Bus

Quando i messaggi arrivano sul consumer, questi saranno elaborati dallo stesso e successivamente inviati al Dispatcher che sarà responsabile di veicolare il messaggio verso il corretto gestore (Event Handler) e quest’ultimo sarà l’effettivo responsabile dello store sul database SQL, NoSQL o sulla coda AMQP.

*Diagramma 5* - Utilizzo del Dispatcher per veicolare la richiesta di store delle richieste/risponste JAX-RS verso il sistema configurato.

Figure 4. Diagramma 5 - Utilizzo del Dispatcher per veicolare la richiesta di store delle richieste/risponste JAX-RS verso il sistema configurato.

Il blocco alt (abbreviazione di "alternative") del diagramma di sequenza precedente mostra come il Dispatcher inoltra l’evento all’Event Handler SQL, NoSQL o AMQP in base alla configurazione dell’applicazione. Nel diagramma di flusso precedente (diagramma 2), il Dispatcher è rappresentato dall’Inclusive Gateway (notazione BPMN). Le operazioni del blocco alt sono asincrone, per cui l’ordine l’ordine di esecuzione delle operazioni non è garantito. Una volta che l’Event Handler ha elaborato l’evento, notifica il Dispatcher dell’esito dell’operazione.