Le principali strategie architetturali di integrazione sono:
- Portal Integration
- Enterprise Information Integration (EII)
- Enterprise Application Integration (EAI)
Mentre la Portal integration consiste nel mettere tutti i servizi in un'interfaccia comune dove dati e logica sono indipendenti da servizio a servizio, nella EAI viene condivisa la logica tra le applicazioni integrando anche le logiche già sviluppate. EII invece si occupa di fornire un unico metodo d'accesso a tutte le sorgenti dati disponibili.
Esistono due diversi tipi di approccio EAI:
- verticale decentralizzato, che consiste nella realizzazione punto punto di comunicazioni ad hoc tra le applicazioni da integrare;
- organico centralizzato, introducendo un middleware che si occupi di queste comunicazioni;
Punto punto
Un approccio verticale decentralizzato punto punto permette una connessione diretta e sincrona tra due applicazioni che possono anche condividere dati e regole di business, ma ha la necessità di conoscere e aggiungere la logica da condividere tra le applicazioni e di replicare e riallineare i dati tramite batch appositi.
Questo porta a costi aggiuntivi futuri per quanto riguarda manutenibilità e aggiornamenti del sistema. Questa metodologia non è applicabile su sistemi in cui il numero coppie di applicazioni da integrare è alto, perché porterebbe ad un sistema ad elevata complessità e poco manutenibile.
Middleware
I middleware sono sono software realizzati appositamente per fungere la funzione di intermediari fra strutture e programmi, premettendo la loro comunicazione a dispetto della diversità dei protocolli e dei sistemi operativi. Essi sono divisibili in 3 categorie:
Basic Middleware
Posseggono architetture per l'integrazione tra dati e applicazioni.
Platform Middleware
Application server J2EE, TP Monitor, ORB, vari Portal Server.
Integration Middleware
Connettono applicazione e database provenienti da architetture differenti.
Le strategie di approccio di un middleware sono:
- Diretto: viene utilizzata una semplice tecnologia di connessione lasciando allo strato applicativo l'incombenza di risolvere i problemi di integrazione. (Platform Middleware)
- Indiretto: consiste nell'introduzione di un livello intermedio evoluto che si occupi delle problematiche di comunicazione occupandosi sia delle connessioni che dell'integrazione dei dati (Basic e Integration Middleware)
Integration middleware
L'integration middleware deve essere l'unico canale di comunicazione tra applicativi disomogenei consentendo una gestione centralizzata di tutte le problematiche di integrazione. Consideriamo tre tipologie di Middleware integration:
Programmatic Integration Server
Riusare le funzionalità mainframe che vengono esposte con nuove tecnologie.
Integration Broker
Integrare applicazioni sviluppate per architetture diverse tra di loro. Tipicamente fornite dall'integration Broker, mettono a disposizione funzionalità più evolute rispetto al Programmatic Integration Server.
Enterprise Service Bus (ESB)
Simile a un integration broker ma basato su BUS e non su HUB. Gli ESB espongono le funzionalità tramite standard mentre gli IB lo fanno tramite tecnologie proprietarie. Inoltre l'ESB si basa su una architettura distribuita a bus condiviso, Service Oriented Architecture (SOA). Ossia tutte le applicazioni sono progettate come aggregazione di servizi, già pronte per l'integrazione.
In particolare i Middleware Integration forniscono le seguenti funzionalità :
- Resource Adapter (RA): risoluzione problemi di comunicazione, spesso forniti con l'EAI;
- Messaging brokers: funzionano come messaging layer sia point-to-point che publish/subscribe;
- Integration Broker: effettua il data mapping e intelligent routing sia content-based che publish-and-subscribe;
- Workflow: gestione dei messaggi e dei business-object durante l'esecuzione dei processi;
- Monitor delle attività di Business: analisi degli eventi per valutare accuratezza, qualità e sicurezza delle attività ;
Da integrazione ai servizi
Attualmente l'integrazione tra sistemi e servizi è per lo più gestita con batch asincroni di sincronizzazione (che non permettono l'accesso in tempo reale alle informazioni) e dall'implementazione di connessioni punto-punto tra servizi che comportano una complessità elevata e costi crescenti sia di manutenzione che di evoluzione del sistema.
Tecnologie di Messaging, Gateway e Middleware permettono di semplificare le problematiche di comunicazione e supporto di meccanismi sincroni e real-time, ma in assenza di una struttura centralizzata, l'uso di queste tecnologie non è sufficiente ad abbattere i costi e la complessità della Spaghetti Integration.
È ritenuto opportuno passare da una strategia verticale p2p ad una integrazione orizzontale come la SOA, orientata allo sviluppo di sistemi informativi complessi e estendibili, integrabili e facilmente manutenibili.
Fare integrazione con SOA è chiamato SOI (Service oriented Integration), cioè trasformare le funzionalità già presenti in servizi in modo da poterli trattare in modo omogeneo con tutti gli altri del sistema.
L'evoluzione da architetture di integrazione P2P a integrazione service-oriented, dimostra una maggiore maturità architetturale delle organizzazioni che non risentono più delle perdite derivanti da una integrazione sbagliata, ma anzi da una progettazione del sistema mirata all'evoluzione e all'integrazione.
Questi sono i principi che stanno alimentando la crescita dei sistemi Enterprise Service Bus ossia middleware di comunicazione orientati ai servizi.
La metodica consiste nell'identificare i punti di integrazione tra le applicazioni e pubblicare dei servizi comuni per l'utilizzo. In tal modo i servizi saranno riutilizzabili anche per altre applicazioni in future evoluzioni del sistema.
Questa approccio è l'opposto della metodologia "Rip and Replace" che consiste nell'avere un'unica applicazione che copra tutte le esigenze del sistema informativo. Tale sistema è fallito perché nei sistemi enterprise difficilmente un'unica applicazione riesce a coprire più del 40% delle necessità funzionali, risultano invece più efficaci strategie di "Wrap and re-engineer" e di "Leave-and-layer".
Wrap and re-engineer
Le applicazioni vengono richiamate da apposite interfacce più flessibili e riutilizzabili da altri sistemi.
Leave-and-layer
Consiste nel conservare l‘esistente portfolio dei servizi riconciliando le loro differenze (logica e dati) in un nuovo layer. Tale layer permette di riutilizzare quello precedente permettendo una razionalizzazione e consolidamento dello stesso mascherando logiche e dati all‘esterno degli endpoint da integrare.
Queste due metodologie permettono di fare coesistere sistemi eterogenei nel nuovo layer "service bus" permettendo anche una possibile integrazione incrementale delle nuove applicazioni.
In conclusione, si può affermare che essendo compatibile con tutte le strategie di integrazione esaminate, il Middleware Integration SOA risulta la scelta migliore nello sviluppo di applicazione complesse orientate all'integrazione.