Pubblicazione / Sottoscrizione di un evento

Questo caso d’uso illustra un esempio di pubblicazione di un evento, da parte di un SIL Pubblicante, e la ricezione di esso da parte di un altro SIL ricevente, che si era precedentemente registrato nel gestore degli eventi. La Figura 2-57 illustra il caso d’uso che verrà descritto in questo paragrafo. Si suppone che un servizio di pubblicazione di uno specifico evento sia stato registrato nella porta di dominio del SIL pubblicante, come porta delegata. Si suppone anche, che il SIL che desidera ricevere tutti gli eventi pubblicati di una specifica categoria, si sia precedentemente registrato nella sua porta di dominio attraverso una porta delegata apposita. (vedi paragrafo 2.2.3).

Figura 2-57, Scenario esemplificativo di una pubblicazione e di una sottoscrizione ad un evento

La Figura 2-58 illustra la fase di pubblicazione di un evento, descrivendo i passi effettuati nell’architettura OpenSPCoop di una porta di dominio dove è stata registrata una porta delegata apposita per la gestione della pubblicazione.

2. Architettura del sistema OpenSPCoop 125

Figura 2-58, Step eseguiti all'interno dell'architettura di una porta di dominio che deve gestire la pubblicazione di un evento

Il SIL1 effettuerà l’invocazione del servizio ‘http://openspcoop/pubAnagrafe’, semplicemente interagendo con il punto di accesso alla sua porta di dominio.

Step 1. La richiesta del servizio, effettuata dal SIL1, arriva al modulo di Accettazione Richieste Interne, come fosse una richiesta ad un servizio Web, e cioè sotto forma di un pacchetto Soap. La gestione della richiesta arrivata, comporta controlli di autenticazione ed autorizzazione a livello di trasporto del mittente. Step 2. Se la richiesta supera i controlli, il componente si occupa di inserirla nella coda RequestOUT_Soap insieme con la parte finale dell’url invocata dal SIL (ServiceExample) e un identificativo del mittente. A questo punto il SIL1 ed il modulo hanno concluso il loro compito.

2. Architettura del sistema OpenSPCoop 126

Viene a questo punto chiamato in causa il modulo di Identificazione Porta Delegata.

Step 3. Il modulo prende il pacchetto dalla coda RequestOUT_Soap condivisa con il modulo precedente e ne preleva il messaggio Soap, e l’identificativo del servizio richiesto (pubAnagrafe).

Step 4. Viene utilizzato l’identificativo del servizio richiesto per accedere alla tabella locale, che elenca le porte delegate presenti nella porta di dominio, e ottenere le informazioni necessarie per identificare il servizio richiesto nel registro dei servizi (la chiave di accesso al registro è formata dai valori ‘EventManager, PubblicazioneEvento, Nascita’).

Step 5. Il pacchetto Soap viene infine posto nella coda RequestOUT_SoapToEGov condivisa con il modulo di controllo, insieme alle informazioni prelevate nella tabella locale (EventManager, PubblicazioneEvento, Nascita) e a informazioni sul mittente.

Viene adesso il turno del Modulo di Controllo.

Step 6. Un pacchetto viene prelevato dalla coda condivisa con il modulo ‘identificazione porta delegata’.

Step 7. Vengono prelevate le varie informazioni e-Gov, associate al servizio richiesto, nel registro dei servizi, utilizzando come chiave di accesso la tripla (EventManager, PubblicazioneEvento, Nascita) prelevata dalle proprietà presenti nel pacchetto. Non sono però gestite le varie funzionalità e-Gov associate al servizio poiché il modulo si accorge di dover gestire una particolare richiesta verso un gestore degli eventi che richieder una pubblicazione diretta di un evento.

Vengono effettuati controlli di sicurezza, quali ad es. l’autorizzazione del mittente nell’utilizzo della porta delegata richiamata. Inoltre vengono effettuati dei tracciamenti, attraverso la creazione di Log.

Step 8. Una volta creata la busta e-Gov, viene inserita nella coda RequestOUT_eGov.

Una volta creata, la spedizione della busta e-Gov al Gestore degli eventi viene effettuata dal modulo Inoltro Buste e-Gov.

2. Architettura del sistema OpenSPCoop 127

Step 9. Questo componente preleva un pacchetto dalla coda RequestOUT_eGov, e ne preleva la busta e-Gov presente.

Step 10. Viene controllato il destinatario della busta, e viene utilizzata la Tabella di Routing per capire a chi consegnare la Busta. In questo caso, la busta è destinata all’EventManager e dalla tabella di routing viene ottenuto l’indirizzo di accesso al Gestore degli Eventi.

Step 11. Viene pubblicata la busta e-Gov nella coda relativa all’evento ‘nascita’ all’interno dell’EventManager.

La Figura 2-59 illustra la fase di ricezione di un evento da parte di un sottoscritto, illustrandone gli step effettuati all’interno dell’architettura OpenSPCoop della porta di dominio del sottoscrittore.

Figura 2-59, Step eseguiti all'interno dell'architettura di una porta di dominio che deve gestire la ricezione di un evento in seguito ad una precedente sottoscrizione

2. Architettura del sistema OpenSPCoop 128

Step 1. La ricezione di eventi, attraverso OpenSPCoop, comporta la creazione di un Listener che si occupa di ricevere tutti i possibili eventi che interessano ai sottoscrittori che si sono registrati all’interno della porta di dominio (vedi paragrafo 2.2.3). In questo esempio, poiché esiste una porta delegata con servizio SottoscrizioneEvento ed azioni Nascita e Morte, assumiamo che OpenSPCoop apra un Listener (gestito dal modulo Ricezione Buste e-Gov) sugli eventi Nascita e Morte nel Gestore degli Eventi. Inoltre assumiamo che il SIL2 a cui è associata la porta delegata in questione possa ricevere l’evento attraverso una modalità di interazione PdD-to-SIL passiva, dove OpenSPCoop utilizza l’url di consegna fornita al momento della creazione della porta delegata Infine assumiamo che sia stato pubblicato un evento ‘Nascita’ e che quindi il Listener lo riceva.

Step 2. Il Modulo Ricezione Buste e-Gov, contiene i vari Listener collegati agli eventi nell’EventManager. Al momento della ricezione dell’evento, si occuperà di inserirlo nella coda RequestIN_eGov.

A questo punto entra in gioco il modulo di controllo.

Step 3. Il pacchetto viene prelevato dalla coda RequestIN_eGov. Dalle informazioni presenti nella busta e-Gov, il modulo capisce che si tratta di un evento. Riesce a dedurre questo, poiché vede che proviene dall’EventManager. A questo punto viene sbustata la busta e-Gov, e viene inserito l’evento Soap in un pacchetto, insieme alle informazioni prelevate dalla busta e-Gov, quali il ServiceProvider (EventManager) e il tipo di evento (azione).

Step 4. Il pacchetto viene inserito nella coda RequestIN_eGovToSoap condivisa con il modulo ‘Identificazione Porta Applicativa’.

Viene a questo punto chiamato in causa il modulo di Identificazione Porta Applicativa.

Step 5. Il modulo prende il pacchetto dalla coda condivisa con il modulo precedente e ne preleva il messaggio Soap, e l’identificativo del servizio richiesto (ServiceProvider, servizio, azione).

2. Architettura del sistema OpenSPCoop 129

Step 6. Poiché il ServiceProvider è l’EventManager, capisce che si tratta di un caso di gestione speciale, e invece di accedere come normalmente farebbe alla tabella dei profili delle porte applicative, accede a quella delle porte delegate, cercando l’entry con i seguenti valori:

‘ServiceProvider = EventManager’ ‘Servizio=SottoscrizioneEvento’ ‘Azione=Nascita’

Visto che una entry esiste, e che sono state specificate una url ed una modalità di consegna, vengono prelevate queste informazioni.

Step 7. Il Soap message viene imbustato in un pacchetto insieme all’url e alla modalità di consegna, e viene messo nella coda RequestIN_Soap.

Infine è il turno del modulo di Consegna Buste Soap.

Step 8. Questo componente prende un pacchetto dalla coda RequestIN_Soap, e ne preleva la busta Soap presente, l’url e la Modalità di Consegna.

Step 9. Siccome la modalità di consegna è HTTP viene creata una connessione HTTP all’url, e consegnata la busta Soap (l’evento).