Una nuova architettura per OpenSPCoop

Una nuova architettura per OpenSPCoop

Nel capitolo precedente abbiamo studiato quello che il panorama SOA ed ESB propone a soluzione dell'implementazione di SPCoop. A conclusione di questo studio abbiamo appurato che le architetture di tali soluzioni non sono ottimali per implementare le specifiche SPCoop. Rimane quindi preferenziale continuare lo sviluppo dell'architettura di OpenSPCoop maturata fino alla versione 1.0. Lo studio condotto ha comunque fornito interessanti punti di riflessione per poter migliorare la gestione dei messaggi modificando l'architettura di OpenSPCoop avvicinandola a sistemi che fanno delle porfomances il loro punto di forza.

In questo capitolo, per primo analizziamo il problema, esplicitando i motivi che ci hanno spinto a proporre una nuova architettura per l'implementazione di SPCoop. Vedremo quali vincoli sono stati imposti per questa proposta di modifica e infine un'accurata descrizione della nuova architettura, dove verranno valutati i vari comportamenti nei diversi scenari di comunicazione, i punti in cui si verificano dei miglioramenti rispetto alla precedente implementazione e dove paghiamo questi miglioramenti.

1 Analisi del problema

Come abbiamo spiegato nel capitolo precedente, durante lo sviluppo di OpenSPCoop sono emerse problematiche relative alla performance del sistema. La ricerca dei punti in cui la gestione dei messaggi di OpenSPCoop rallenta, ha mostrato che un notevole collo di bottiglia è costituito dall'accesso in database dovuto alla scrittura e lettura dei messaggi e all'uso delle code JMS nel modulo di controllo della Porta di Dominio OpenSPCoop. I diagrammi di sequenza e lo schema architetturale del modulo di controllo mostrano che un messaggio, di richiesta o risposta, viene immediatamente salvato su DB, poi i dati rilevanti per il processo di mediazione passano attraverso gli stadi di processamento tramite code JMS ed infine il messaggio viene riletto da database, modificato e inoltrato al destinatario. Questo garantisce una presa in carico del messaggio immediata da parte di chi lo riceve e, da parte del mittente, conferme di ricezione in tempi ridotti. Nel complesso, però, l'intero processo di mediazione risulta appesantito ed il servizio di presa in consegna fornito grava in questo senso. Per snellire il processo di mediazione dobbiamo agire appunto su questi due aspetti di OpenSPCoop: accesso a DB e overhead introdotto dal passaggio di processo in processo. Questo può essere effettuato solo modificando l'architettura. Vediamo come.

2 Requisiti della nuova architettura da realizzare

Prima di procedere con la presentazione della modifica proposta all'architettura di OpenSPCoop, elenco brevemente i vincoli imposti che la nuova architettura deve rispettare:

• Rispettare le specifiche SPCoop.
• Mantenere i servizi di presa in carico garantiti dall'architettura originale.
• Supportare i nuovi standard.
• Migliorare le performances delle operazioni di mediazione.
• Riuso del codice esistente per ridurre al minimo il processo di implementazione.

3 Descrizione dell'architettura proposta

L'idea alla base dell'architettura proposta è quella di limitare il salvataggio dei messaggi solo se si rivela necessario, cercando di effettuare una mediazione "al volo", senza ricorrere all'architettura SEDA. Affiancare quindi alla tradizionale architettura di mediazione di OpenSPCoop un canale più performante e preferenziale.

Ricordiamo come il componente di controllo della Porta di Dominio OpenSPCoop effettua la mediazione dei messaggi:

• Il messaggio viene ricevuto e salvato su DataBase.
• I dati rilevanti passano attraverso code JMS nei vari stadi di processamento.
• Il messaggio da inviare viene costruito partendo dall'originale nel Database e i dati risultanti dalle operazioni di modulo di controllo e inviato al destinatario.

In pratica viene fatto uno "Store and Foward" dei messaggi. Quello che si vuole implementare è sostanzialmente un "Foward and, maybe, Store" continuando a fornire gli stessi servizi qualitativi dell'architettura originale.

Dal punto di vista architetturale abbiamo quindi due modelli di gestione affiancati che costituiscono due canali di mediazione, il tradizionale ed il preferenziale.

Vediamo come questa architettura gestisce i vari paradigmi di comunicazione.

3.1 OneWay

Cominciamo dal paradigma OneWay. Vediamo tramite un diagramma di attività come la nuova architettura effettua la mediazione dei messaggi. Il diagramma di attività è un diagramma definito all'interno dello UML e definisce le attività da svolgere per realizzare una data funzionalità. Può essere utilizzato anche in fase di design per dettagliare un determinato algoritmo. Più in dettaglio un Diagramma di Attività definisce una serie di attività o flusso, anche in termini di relazioni tra di esse, chi è responsabile per la singola attività ed i punti di decisione. Il flusso è rappresentato tramite delle frecce orientate, che indicano la sequenza temporale con cui devono essere effettuate le diverse attività. È previsto un simbolo per indicare l'inizio del flusso ed un altro per indicarne il termine. Le attività possono essere anche rese in parallelo, in questo caso il punto di divisione (fork) è rappresentato da frecce divergenti rispetto al segmento. Nel caso le attività siano alternative, cioè svolte o meno rispetto ad una scelta, il punto di decisione è rappresentato da dei rombi da cui partono i flussi alternativi. Il punto di ricongiungimento (join) è reso tramite un segmento su cui le frecce si ricongiungono.

E' importante notare che il processo è thread-based, in contrapposizione con il processo tradizionale basato sui principi dell'architettura SEDA. Quindi tutta la logica viene svolta da un unico processo nella sua interezza. Ricevuto un messaggio SOAP questo viene imbustato trasformandolo in una Busta eGov e inoltrata alla Porta di Dominio Destinataria. Qualora si verificasse un problema di comunicazione, il sistema procede alla presa in consegna del messaggio, salvandolo su database e costruendo le informazioni necessarie per l'inoltro da inserire nella coda JMS InoltroBusteEGov. Logicamente, quindi, il messaggio passa dal canale preferenziale al canale tradizionale, sfruttandolo per garantire la persistenza dei messaggi. Il lavoro svolto negli stadi fin qui attraversati viene conservato nel processo di transizione da un canale all'altro. I messaggi gestiti dal canale preferenziale non attraversano code JMS, quindi non si accodano ai messaggi in transito. Questo ha due implicazioni: non introduciamo l'overhead dovuto al frazionamento del processo di mediazione e riduciamo drasticamente il numero di accessi a database per salvare le informazioni sullo stato del messaggio, ma rinunciamo a eventuali politiche di load balancing o di priorità.

La nuova gestione a livello di processo modifica conseguentemente anche il livello di scambio di messaggi.

Come si nota dal diagramma di sequenza, in caso di successo il SIL Mittente non riceve subito l'ack SOAP dalla Porta di Dominio. La comunicazione quindi viene sospesa in attesa che il processo di mediazione sia portato a termine, al contrario del canale tradizionale che, a seguito della ricezione del messaggio, si occupava subito della presa in consegna e comunicava al mittente l'ack SOAP di conferma. In questo scenario non viene fatto nessun accesso a database, quindi, nel complesso, il processo di mediazione risulta più snello e rapido. Di contro, sarà chi invia il messaggio a dover attendere un tempo maggiore prima di ricevere la conferma SOAP, quindi, localmente, il processo risulta più lento.

Analizziamo adesso i casi di insuccesso parziale:

Qualora si verificassero degli errori di comunicazione, il sistema provvede alla presa in consegna del messaggio. Il messaggio viene quindi salvato su Database effettuandone la presa in consegna. Infine viene inviato l'ack SOAP al SIL Mittente. Quando la comunicazione riprenderà, i nodi successivi potranno ancora sfruttare il canale preferenziale, confermando la totale trasparenza del servizio agli altri nodi.

Anche in questo scenario il sistema garantisce la presa in carico del messaggio in caso di errore di comunicazione e provvedere all'ack SOAP. E' interessante notare come l'insorgere di errori di comunicazione influenzano la percezione della qualità del servizio per chi invia un messaggio secondo il paradigma OneWay. Se la comunicazione non ha errori, la ricezione del messaggio verrà confermata più tardi. Questo può sembrare controproducente, ma, visto nell'insieme, il sistema ne trae beneficio. Inoltre, come vedremo, l'uso dei due canali è configurabile, adattandosi alle esigenze funzionali dei SIL che ne fanno uso.

3.2 Request/Response Sincrono

Analizziamo il caso in cui alla richiesta inviata dal SIL Mittente segua una risposta del SIL Destinatario. Andiamo ad analizzare il diagramma di attività dello scenario in questione.

Anche in questo caso abbiamo un'architettura thread-based come per il caso del OneWay, ma la gestione dei messaggi è naturalmente diversa. Nel caso del sincrono, se la comunicazione ha dei problemi di connessione nel tratto della richiesta, il processo complessivo termina totalmente, comunicando al SIL Mittente l'errore.

Se il problema si presenta nella trasmissione della risposta, allora devono essere eseguite delle procedure per utilizzare la risposta già elaborata qualora il mittente eseguisse la stessa richiesta, evitando che il SIL destinatario la processi due volte qualora fosse configurata una consegna "ALPIUUNAVOLTA".

La gestione di questo tipo di errori è già implementata nell'architettura tradizionale di OpenSPCoop, quindi l'implementazione del canale preferenziale dovrà solamente replicare lo stato del messaggio del canale tradizionale al momento dell'errore per assicurarsi una corretta gestione.

La componente di controllo della Porta di Dominio OpenSPCoop originale invece gestisce i messaggi tutti allo stesso modo, indipendentemente dal tipo di comunicazione, quindi salva sia i messaggi di richiesta che di risposta. In questa situazione quindi i benefici sono fruibili sia localmente sia globalmente. La gestione più snella della comunicazione e un tempo di risposta globalmente più rapido è godibile anche dal mittente, dovendo in ogni caso restare in attesa della risposta.

3.3 Gestione della memoria

L'architettura proposta, come mostrato, snellisce la gestione della mediazione dei messaggi da parte dei componenti di controllo nelle Porte di Dominio OpenSPCoop, introducendo al più un ritardo nei feedback verso il mittente nel caso di un messaggio nel profilo OneWay. C'è però un problema nuovo che l'architettura proposta introduce e che va adeguatamente gestito. L'architettura originale salvava tutti i messaggi ricevuti su database, e in memoria si limitava a tenere solo le informazioni necessarie alla mediazione. Nel canale preferenziale, introdotto dalla nuova architettura, il messaggio, per evitare gli accessi a DB, viene tenuto in memoria con tutte le complicazioni che ne derivano. E' quindi necessario introdurre un meccanismo che gestisca l'utilizzo del canale preferenziale filtrando i messaggi in ingresso smistandoli tra i due canali.

A tal proposito verrà effettuato un controllo a runtime che filtri i messaggi indirizzati al canale preferenziale in base alla dimensione del messaggio in transito, per evitare che messaggi troppo grandi, ad esempio con attachments di grandi dimensioni, saturino la memoria a disposizione. Inoltre un'altra selezione viene fatta in base al servizio richiesto a livello di configurazione della Porta di Dominio. Come anticipato, localmente il canale preferenziale può introdurre un ritardo nella comunicazione della ricezione del messaggio, quindi spetta a chi gestisce la Porta di Dominio determinare quale soluzione sia più appropriata per il servizio richiesto.

3.4 Errori di comunicazione

Quando abbiamo introdotto la nuova gestione dei messaggi e le modifiche alla gestione dei protocolli di comunicazione, sono emersi scenari parzialmente fallimentari dovuti ad errori di comunicazione. Come mostrato nel caso della una comunicazione sincrona, può capitare che mentre il messaggio viene mediato, una delle connessioni pendenti già attraversate cada e la risposta non possa più essere consegnata.

Questi parziali fallimenti possono far nascere una serie di questioni sul comportamento di OpenSPCoop per tentare di portare a termine comunque la comunicazione in momenti successivi. Abbiamo, infatti, una situazione in cui il messaggio è stato consegnato, ma il SIL Mittente crede che l'invio sia fallito. Se il SIL invia nuovamente la richiesta il messaggio può essere consegnato due volte.

Ovviamente la specifica SPCoop tratta questi problemi e la soluzione consiste in una serie di servizi addizionali forniti dall'infrastruttura, configurabili secondo le esigenze degli utenti, quali la Gestione dei Duplicati e la Correlazione Applicativa, che permettono, ad esempio, di garantire che una richiesta non venga consegnata due volte, come potrebbe accadere nel caso fallimentare precedentemente illustrato. La Porta di Dominio, per far questo, riconosce il secondo messaggio come duplicato e recupera la risposta precedentemente ricevuta da consegnare al mittente. L'importante è sottolineare che queste funzionalità aggiuntive e sistemi di gestione degli errori sono già presenti nell'implementazione della Porta di Dominio OpenSPCoop e che la nuova architettura non introduce nuovi scenari fallimentari da dover gestire. Grazie alla possibilità di spostare logicamente il messaggio dal canale preferenziale a quello tradizionale, la nuova architettura eredita completamente le funzionalità implementate nella vecchia architettura. E' comunque da evidenziare che nel caso di comunicazioni con profilo OneWay, situazioni di connessioni pendenti che si interrompono, avranno un'incidenza maggiore, causata dalle connessioni tenute aperte più a lungo: