Salta la navigazione
In pratica la comunicazione tra gli applicativi avviene scambiando messaggi, attraverso degli appositi adattatori mediante un canale di comunicazione.
La connessione vera e propria tra l´applicativo ed il canale di comunicazione "il middleware" è attivata dagli adapter.
Questi oggetti mettono a disposizione:
- la connettività, aprendo un canale di connessione dall´applicativo al middleware di integrazione.
- una interfaccia di comunicazione tra la tecnologia dell´applicativo ed il canale di comunicazione
- la traduzione di formato laddove non sia possibile l´utilizzo dello standard HL7 .
Figura 3: Modello di soluzione
L´adattatore in questo tipo di implementazione si limita semplicemente a attivare un canale di comunicazione tra l´applicativo e lo strato software che si occupa dell´inoltro dei messaggi (middleware) e la conversione tra un formato (XML) e l´HL7 dove richiesto.
Vantaggi
- Flessibilità (l´inserimento di un nuovo applicativo nell´architettura o una sua sostituzione è possibile senza dover effettuare modifiche negli altri applicativi)
- Disaccoppiamento (le integrazioni tra gli applicativi avvengono tramite una middleware di integrazione che si occupa dello smistamento dei messaggi )
- Interfaccia tecnologica ( vengono offerti una serie di adattatori tecnologici tra cui web service , code ICAN , viste DB ecc )
- Centralizzazione ( gli accessi al Repository e alla Anagrafe Centrale vengono indirizzati da un unico adattatore e controllati dal middleware )
- Standard ( è possibile utilizzare messaggi HL7 o in altri formati esempio XML )
Limiti della soluzione
La piattaforma di integrazione come quella proposta nel progetto CRS-SISS è una soluzione general purpose che non è espressamente progettata per il mercato sanitario e per una integrazione HL7.
Questo tipo di soluzione, pur offrendo elevate funzionalità e prestazioni unite ad una discreta flessibilità , mostra dei limiti che se trascurati possono diventare i veri anelli deboli della catena.
In particolare per offrire prestazioni accettabili è necessario ospitare il software su Hardware dedicati e comunque performanti. La complessità di un sistema simile comporta generalmente un notevole dispendio di tempo e risorse sia durante l´installazione che durante la manutenzione.
Allo stesso modo l´architettura general purpose del sistema è un "adattamento" verso le applicazioni sanitarie.
Una applicazione che deve essere integrata generalmente ha bisogno di un adattatore ad hoc , questo adapter è un oggetto software, un programma, che tramite codice esegue la logica di connessione verso il middleware, la traduzione e l´inoltro del messaggio.
L´adapter ha al suo interno cablata la metodologia di connessione dell´applicazione verso il middleware , modificare il metodo di connessione vuol dire modificare l´adapter.
Svantaggi
Gli svantaggi di una soluzione general purpose sono riassumibili in:
- Hardware performante
- Elevati costi d´acquisto
- Complessità ( installazione e manutenzione )
- Implementazione ( lo sviluppo e la manutenzione degli adattatori necessitano di competenze specialistiche)
- Forte interdipendenza (è necessario sviluppare un adapter ad hoc per ogni applicazione )
- Elevati oneri manutenzione
- Scarsa riusabilità ( gli adattatori sono sviluppati ad hoc per ogni applicativo e fortemente legati al progetto )
Figura 3: Modello di soluzione