Sviluppo di un’architettura per l’integrazione di servizi di comunicazione in ambito bancario, secondo il modello UCC

Il problema più critico, soprattutto in contesti bancari, riguarda la gestione dei dati: informazioni di sicurezza, limiti di visibilità e validità, trasmissioni e allineamenti. Se a queste difficoltà si aggiunge la necessità di dover gestire l‟interazione fra applicazioni differenti, che necessitano di stessi dati e che, in alcuni casi, pretendono che tali dati siano in formati differenti, il problema diviene di critica risoluzione.

Una soluzione di integrazione a soli componenti (senza lo sviluppo di GLUE-CODE, GLUE-APPLICATION ed ADAPTER) non sarebbe possibile soprattutto per questo vincolo: la comunicazione fra i componenti, la sincronizzazione (possibile attraverso memorizzazione dei dati, in modo persistente o in sessione) e l‟elaborazione sarebbero processi impossibili.

Per questo deve esistere una “memoria” all‟interno del sistema complessivo d‟integrazione, per alcuni aspetti necessariamente speculare rispetto alla memoria dell‟insieme di server del SaaS, per altri aspetti volutamente diversa. Le informazioni di stato possono essere classificate, a livello gerarchico più alto, nelle seguenti partizioni:

• Soft State: o stato volatile, associato a oggetti (quindi classi Container, HashMap, Liste di Oggetti,…) o variabili di sessione (HttpSession, Cookies)
• Hard State: o stato persistente, associato a scrittura da DB ovvero su file

La scelta di adoperare una memorizzazione Soft State o Hard State dipende, chiaramente, dalle circostanze di utilizzo, dalla validità dell‟informazione, dagli scopi che si intende perseguire, ma è interessante sottolineare che le due soluzioni non sono mutuamente esclusive. Vi sono, cioè, particolare contesti in cui è necessaria una duplicazione dei dati, su DB ed in sessione.

Si pensi al caso di richiesta di assistenza da parte di un cliente registrato. Il sistema, a partire dalla chiave che identifica l‟utente nel DB, preleva l‟insieme dei dati dell‟utente. Successivamente ad altre interrogazioni (necessarie, ad esempio, per prelevare l‟indirizzo della coda personale di riferimento o i dati dell‟assistente a cui l‟utente è associato), vengono prelevato altri dati, semanticamente legati all‟utente. Viene creata una specie di tabella virtuale (simile alla vista in un contesto di sole basi di dati) e spostata in sessione. Così, successive operazioni (tipo la prenotazione di un MEETING sul Calendar) possono usare il SOFT-STATE per inserire all‟interno delle email e del Calendar le informazioni in memoria, senza dover di nuovo interrogare il DB.

Altra classificazione delle informazioni di stato riguarda la località. Gli stati possono essere locali al MiddleServer ovvero presenti solo in remoto.

• Stato locale: trasposizione dei dati presenti in remoto su WebEx, accorpati per semantica ed integrati con ulteriori informazioni derivanti da richieste ad altri servizi Web (ad esempio integrazione dei dati dei BUDDIES con informazioni sulla presence dedotte dall‟utilizzo di API di AOL).

• Stato remoto: memorizzazione dei dati (dati personali, email, dati relativi a Meeting) sul server di WebEx ovvero sui Calendar dei dipendenti

Nella figura seguente la divisione dei moduli per funzionalità discrimina anche il tipo di memorizzazione dei dati. Il modulo addetto alla gestione delle memoria si occupa della memorizzazione dei dati nell‟opportuna struttura, dall‟accesso al DB, ai file, del mantenimento in sessione, del download via FTP e del salvataggio in locale. Il modulo addetto alla gestione dell‟elaborazione usa gli stati (soft e hard) per discriminare il processo elaborativo da innescare.

Infine, il modulo addetto alla comunicazione viene interpellato dai moduli elaborativi, in funzione degli stati interni del server e del valore dei dati provenienti da DB o da strutture volatili.