Sistemi informativi/Comunicazione tra SI

I sistemi informativi hanno iniziato a formarsi come applicazioni monolitiche, cioè applicazioni singole che si appoggiavano direttamente sul sistema operativo, per poi evolversi con gli anni in sistemi multilivello che utilizzavano basi di dati per immagazzinare informazioni.

Con l'introduzione di livelli logici differenti, è nata la possibilità di far cooperare diversi sistemi informativi tra loro, per far questo sono stati introdotti diversi livelli di comunicazione, caratterizzate dal livello logico a cui operano.

Livelli di Comunicazione

• A livello di presentazione: se volessimo instaurare un colloquio tra due sistemi monolitici, per le caratteristiche dei sistemi in analisi, non è possibile separare l’interfaccia dalla logica applicativa, perciò l’unica possibilità è quella di creare delle finte interfacce (wrappers), che si appoggiano sul sistema stesso consentendo l’interazione reciproca mediante le schermate. Nel caso in cui il sistema non sia monolitico (e quindi sia possibile separare i vari livelli logici), si può comunque creare un wrapper che si appoggia sul livello di presentazione.
• A livello applicativo: nel caso in cui sia possibile separare il livello applicativo dall’interfaccia, è possibile anche adottare una soluzione migliore, che consiste nel far colloquiare direttamente i livelli applicativi (a patto che il sistema consenta tale comunicazione).
• A livello di dati: inoltre, se il livello dati è separato dagli altri, è talvolta (ma non sempre) possibile instaurare una comunicazione direttamente al livello dei dati. In generale, possiamo dire che tecnicamente è possibile far passare i dati direttamente da una base di dati ad un’altra, senza passare attraverso i livelli logici superiori, se si verificano le seguenti condizioni:

1. I dati devono essere rappresentati tutti nello stesso modo.
2. Bisogna effettuare dei controlli molto forti.

Nella maggior parte dei casi, queste due condizioni impediscono interazioni al livello dei dati.

Comunicazione tra sistemi informativi

Abbiamo appena visto come due sistemi informativi possono comunicare a vari livelli logici. Poniamoci ora il problema di definire come più sistemi informativi possono comunicare tra loro.

Comunicazione diretta

L’integrazione delle applicazioni potrebbe avvenire semplicemente realizzando sistemi separati che comunicano tra loro in maniera diretta. In sostanza quindi si deve definire un opportuno modo di interfacciamento per ogni coppia di sistemi informativi che devono colloquiare tra loro: si definiranno delle regole di comunicazione tra ogni singola coppia di sistemi informativi, e si definiranno i relativi moduli di comunicazione. Tale scenario, che storicamente è stato il primo ad essere adottato, risulta molto complesso da gestire, anche se consente di definire interfacce specifiche tra i vari sistemi (cosa che in alcune situazioni potrebbe essere utile).

Integrazione tramite Middleware

La comunicazione tra i moduli può anche essere resa possibile mediante l’uso di un middleware. Un middleware è un’infrastruttura che consente lo scambio di messaggi tra i vari moduli, secondo delle regole opportune. In questo modo, la comunicazione risulta virtualizzata: non si ha una comunicazione diretta tra due moduli, ma si passa attraverso il middleware. L’uso del middleware presenta come importante vantaggio la possibilità di fornire delle maggiori garanzie, ad esempio nel campo dell’affidabilità: il middleware potrebbe garantire al modulo mittente che il messaggio inviato venga ricevuto dal destinatario (sarà quindi il middleware a gestire l’eventuale ritrasmissione del messaggio). Lo svantaggio che ne deriva è invece rappresentato dalla scarsa flessibilità, e dalla necessità di definire degli adattatori in grado di unificare i formati dei dati e consentire così il colloquio tra i vari sistemi. Il sistema di middleware può anche essere usato per definire dei sistemi di notifica: quando vengono ricevuti alcuni tipi di messaggi, viene segnalato il corrispondente evento. A svolgere questo componente è un componente del middleware, detto message broker.

Integrazione tramite Workflow

Un altro tipo di integrazione è quella che passa attraverso i sistemi di workflow. Tali sistemi vengono usati sia per la comunicazione interna all’azienda, sia per la comunicazione con l’esterno. L’integrazione a livello di workflow avviene mediante la codifica delle attività che costituiscono i processi. In sostanza, l’azienda viene suddivisa in macro-processi, secondo lo schema della catena del valore di Porter. Si definiscono poi i collegamenti tra i vari processi e i collegamenti verso l’esterno. Per fare ciò occorre specificare quali sono i dati che vengono scambiati (ma ad un livello di dettaglio molto diverso rispetto a quello del sistema a messaggi, ovvero con un’astrazione molto superiore), e i passi che devono essere compiuti per mettere in atto questa integrazione. Da un punto di vista tecnologico, l’approccio che possiamo usare è quello della modellizzazione, attraverso il BPMN (Business Process Modeling Notation). Il livello di astrazione delle attività nello schema BPMN resta generalmente abbastanza alto (anche se poi è possibile scomporre ogni attività in un nuovo schema BPMN che metta in evidenza le attività che a sua volta la costituiscono). Lo scenario di integrazione mediante modellazione dei processi è rappresentato nella figura seguente, che mette in evidenza come venga definito (mediante BPMN) un processo (workflow) che sia in grado di stabilire quando vengono invocate le varie applicazioni del sistema informativo.

Tecnologie per la comunicazione dei SI

Abbiamo già accennato al fatto che i sistemi informatici distribuiti necessitano di scambiare informazioni. Ora vediamo con quali tecnologie è possibile questo scambio di informazioni.

Remote Procedure Call(RPC)

Come funziona la RPC?

Il meccanismo di RPC si basa sullo scambio di informazioni tra un programma chiamante, allocato su un elaboratore, ed una procedura remota,allocata su un altro elaboratore, attraverso l'utilizzo di un protocollo di comunicazione. Il programma chiamante formula la propria richiesta ed impacchetta tramite l'operazione di marshalling i valori di input della propria richiesta assieme al nome della procedura che intende chiamare. Il messaggio raggiunge l'altro elaboratore attraverso il protocollo comunicativo, questo la riceve e per mezzo del dispatcher riconosce e seleziona la procedura chiamata. Il messaggio verrà privato del nome della procedura chiamata tramite l'operazione di unmarshalling e i dati di input verranno letti dalla procedura chiamata. Questa risponderà tramite un altro messaggio con i valori di output.

Pregi e difetti

La RPC è un buon modo di comunicazione per SI ad accoppiamento debole. La chiamata di una procedura remota però non è uguale alla chiameta di una procedura locale, ciò comporta alcuni problemi:

• limitazione ai formati dei dati (nel web risolto con XML)
• possibilità di invocazione concorrente della stessa procedura

Client-Server

La tecnologia client-server è un'altra tipologia di comunicazione utilizzata dai SI ad accoppiamento forte. Si basa su due tipologie di applicazione:

• applicazione server(o processo servente): è l'applicazione che offrire servizi. Può servire più applicazioni client, per fare questo può utilizzare tipi di protocolli asimmetrici che migliorano la velocità di risposta del server. Un server può basarsi su logica bloccante o non bloccante a seconda che esaudisca una richiesta alla volta oppure no. E' possibile che un server rimanga sempre attivo oppure si attivi ogni qual volta riceva una richiesta
• applicazione client(o processo cliente): è il processo che richiede i servizi. Generalmente si blocca in attesa dell'esaudimento della richiesta, questo va bene se la richiesta è del tipo transizionale, in altre situazioni è preferibile che non sospenda l'attività

Generalmente questa tecnologia si basa su un dialogo sincrono, cioè il server rimane in attesa di richieste, quando arriva una richiesta inizia la propria attività, nel frattempo il client che ha richiesto il servizio si mette in attesa della risposta del server.