Invocazione di un Servizio

In questo scenario esemplificativo dell’architettura OpenSPCoop una porta di dominio invierà una singola richiesta di servizio ad un’altra porta dominio senza restare in attesa di alcuna risposta (profilo di collaborazione impostato a MessaggioSingoloOneWay). La Figura 2-53 illustra l’astrazione di questo particolare caso d’uso.

2. Architettura del sistema OpenSPCoop 119

La Figura 2-54 illustra la gestione della richiesta effettuata da un sistema informativo locale nell’architettura OpenSPCoop.

Figura 2-54, Gestione dell’invocazione di Servizio effettuata all'interno dell'architettura di una porta di dominio ‘Mittente’

Il SIL1 effettuerà l’invocazione del servizio ‘http://openspcoop/ServiceExample’, 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 120

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 (ServiceExample).

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 ottiene le informazioni necessarie per identificare il servizio richiesto nel registro dei servizi (Chiave di accesso data dai valori ‘SIL2, Anagrafe, ModificaDati’ ).

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 (SIL2, Anagrafe, ModificaDati) ed a informazioni sul mittente.

Viene adesso il turno del Modulo di Controllo.

Step 6. Un pacchetto viene prelevato dalla coda RequestOUT_SoapToEGov condivisa con il modulo di controllo. 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 7. Vengono prelevate le varie informazioni e-Gov, associate al servizio richiesto, nel registro dei servizi, utilizzando come chiave di accesso la tripla (SIL2,Anagrafe,ModificaDati) prelevata dalle proprietà presenti nel pacchetto. Sono quindi gestite le varie funzionalità e-Gov associate al servizio come per esempio l’affidabilità della consegna e la richiesta di un riscontro. Dal registro dei servizi viene prelevato anche l’url della porta di dominio destinataria a cui è destinata la busta.

Step 8. Una volta creata la busta e-Gov, viene inserita nella coda RequestOUT_eGov insieme all’url della porta di dominio a cui è destinata.

Una volta creata, la spedizione della busta e-Gov alla porta di dominio destinataria viene effettuata dal modulo Inoltro Buste e-Gov.

Step 9. Questo componente prende un pacchetto dalla coda RequestOUT_Egov, e ne preleva la busta e-Gov presente e l’url a cui è destinata.

2. Architettura del sistema OpenSPCoop 121

Step 10. La Tabella di routing, in questo contesto potrebbe non venire utilizzata poiché si tratta di una invocazione di servizio verso una url precedentemente letta dal registro dei servizi (step 7). Potrebbe comunque essere forzato il suo utilizzo nel caso si voglia redirigere qualunque busta spedita dalla porta di dominio verso un proxy o relay intermedio.

Step 11. Viene spedita la busta e-Gov alla porta di Dominio Destinataria.

La Figura 2-55 illustra invece i passi effettuati, nell’architettura OpenSPCoop, da una busta SPCoop ricevuta da una porta di dominio che include un service provider che eroga il servizio richiesto nella busta (esiste una porta applicativa apposita).

Figura 2-55, Gestione dell’invocazione di Servizio effettuata all'interno dell'architettura di una porta di dominio ‘Destinataria’

Step 12. La busta e-Gov arriva al modulo di Ricezione Buste e-Gov, 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.

2. Architettura del sistema OpenSPCoop 122

Step 13. Se la richiesta supera i controlli, il componente si occupa di inserirla nella coda RequestIN_eGov. A questo punto il modulo ha concluso il suo compito.

Viene adesso il turno del Modulo di Controllo.

Step 14. Un pacchetto viene prelevato dalla coda RequestIN_eGov.

Step 15. Vengono prelevate le varie informazioni e-Gov, associate al servizio richiesto, nel registro dei servizi, utilizzando come chiave di accesso la tripla (Destinatario, Servizio, Azione) prelevata dalla busta e-Gov presente nel pacchetto. Viene effettuata la validazione del pacchetto effettuando un controllo di conformità del messaggio con lo standard busta SPCoop e verificando che il contenuto del messaggio sia ben formato e sintatticamente corretto. Vengono inoltre effettuati controlli di sicurezza, quali ad es. l’autorizzazione del mittente nell’utilizzo del servizio richiamato. Inoltre vengono effettuati dei tracciamenti, attraverso la creazione di Log. Dopodichè viene controllato la presenza eventuale di messaggi di Fault nella lista Eccezioni della busta e-Gov. Inoltre sono gestite le varie funzionalità e-Gov associate al servizio come affidabilità della consegna e ricezione di un riscontro. Infine avviene lo sbustamento della busta e-Gov.

Step 16. Una volta sbustata la busta e-Gov, viene inserita nella coda RequestIN_eGovToSoap, insieme alla tripla che identifica il servizio applicativo richiesto. Nel nostro caso d’uso la tripla è composta dai seguenti valori: [ SIL2, Anagrafe, ModificaDati ].

Viene quindi il turno del modulo di Identificazione Porta Applicativa.

Step 17. 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).

Step 18. La tripla viene utilizzata per accedere alla tabella locale, che elenca le porte applicative presenti nella porta di dominio, e ottiene le informazioni necessarie per effettuare l’invocazione del servizio applicativo, e cioè una url di consegna ed una modalità di consegna

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

2. Architettura del sistema OpenSPCoop 123

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

Step 21. Siccome la modalità di consegna è WSDL viene invocato il ServizioWeb, relativo al WSDL prelevato attraverso l’url di consegna, consegnando la busta Soap. La Figura 2-56 illustra tutto il caso d’uso nel suo insieme.

! ! "#$ #%" & & ' ()*+, -& # & + # + . ' ()*+ -& # + . * / ' ()*+, * -& # & +, . &0+ -& . ' &0+ -& . &0+, -& . & 1 ' &0+, -& . ' &0+ * , -& # & +, . ! ! "#$ #%" ()*+, -& . ()*+ -& . 1 , & / ,/ & 1 , , &1 , &1 " # $ % & ' ( ) 0 3 , ) 3 * 3 , 4 , 3 " , 3* + 3 , + - ,&4 3 ,& 6 3 ) 3 . ! ! "#$ #%" & & ' ()*+ -& # + . ' ()*+, -& # & + # + . * / ' ()*+, * -& # & +, . &0+, -& . ()*+, -& . &0+ -& . & 1 ()*+ -& . ' &0+ * , -& # & +, . ! ! "#$ #%" ' &0+ -& . ' &0+, -& . 1 , & / ,/ & 1 , , &1 , &1 " # $ & . ( ") " " , + * % ' , 3,&8 , 3 1 3 1 6 39 , ) 3 " , + *

2. Architettura del sistema OpenSPCoop 124