Nel precedente articolo sono state introdotte le principali strategie architetturali nell‘integrazione: Portal Integration (PI), Enterprise Application Integration (EAI) e Enterprise Information Integration (EII). Passiamo ad analizzare in dettaglio le architetture EAI.
Introduzione
E‘ importante notare che i tre approcci brevemente descritti in precedenza non sono in assoluta alternativa ma piuttosto complementari: l‘EII può ad esempio essere vantaggiosamente posta al servizio di soluzioni di portale e di workflow fornendo ad esse un accesso unificato a diverse sorgenti dati, con una tangibile semplificazione nella costruzione delle soluzioni stesse.
L‘Enterprise Application Integration si focalizza sull‘integrazione della logica applicativa. Lo scopo è la condivisione della logica di business tra applicazioni diverse o la composizione di “pezzi” di logica già sviluppati in processi nuovi.
Al contrario della PI, dove l‘integrazione è a livello di portale e dove sia i dati che la logica possono vivere indipendentemente, in questo caso parte della logica di business è necessariamente condivisa.
In questo articolo presentiamo in maggiore dettaglio le strategie di EAI, suddividendo ulteriormente la nostra classificazione.
Enterprise Application Integration
A livello di EAI, l‘integrazione di sistemi informativi eterogenei può essere realizzata con almeno due differenti strategie: l‘approccio verticale decentralizzato e l‘approccio organico centralizzato.
Il primo approccio prevede la realizzazione di collegamenti punto-punto che permettano di avere connessioni dirette tra le due applicazioni da integrare, ognuna delle quali può chiamare l‘altra mediante specifiche API.
Il secondo approccio prevede di introdurre nell‘architettura un opportuno strato di integrazione mediante l‘adozione di un Middleware di “disaccoppiamento”.
Vediamo ora di entrare ulteriormente nel dettaglio di questa due possibili classificazioni.
Integrazione Punto a Punto
Nell‘integrazione Punto-Punto si costruiscono le singole connessioni tra le Applicazioni da integrare gestendo volta per colta i problemi di comunicazione e di mapping dei dati.
L‘integrazione P2P è consigliabile laddove le necessità d‘integrazione siano puntuali e circoscritte.
Il vantaggio principale dell‘approccio P2P è che in questo modo si crea una connessione “stretta” e sincrona tra le due applicazioni, con la possibilità di integrare all‘interno del codice ed in modo mirato, non solo i dati con le necessarie conversioni, ma anche le regole di business.
Parliamo di integrazione P2P sia nel caso in cui applicativamente effettuiamo chiamate a livello di business da un‘applicazione all‘altra, esponendo logica “ad hoc” per l‘integrazione, sia nel caso in cui si cerchi di condividere dati senza però utilizzare uno strato di astrazione per l‘accesso ai dati (contrariamente ad esempio con quanto avviene con un approccio EII). In questo ultimo caso, similmente all‘integrazione P2P applicativa, spesso la logica di replicazione e di riallineamento è sviluppata con batch “ad hoc” per il problema specifico (quindi non riutilizzabile).
Connessioni applicative punto-punto
Soluzioni di questo tipo consistono nell‘identificare punti delle applicazioni in cui utilizzare / includere logica di altre applicazioni da integrare e nell‘implementazione diretta di questa integrazione. Questo si fa direttamente, risolvendo volta per volta i problemi di interoperabilità tecnologica, semantica dei dati e comunicazione.
Si tratta in sostanza dell‘integrazione tra applicazioni fatta “ad hoc”, spesso in maniera poco ingegnerizzata. Di fatto una soluzione di integrazione tra due applicazioni di questo tipo, raramente sarà riutilizzabile da altro software.
Ad esempio, posso pensare di includere una chiamata ad un‘API di una applicazione, ma dovrò conoscere il modo con questa applicazione espone i dati (sia dal punto di vista tecnologico che semantico) e dovrò aggiungere della logica alla mia applicazione per l‘elaborazione di questi dati. Inevitabilmente questo porta ad un forte accoppiamento (tightly coupled) di queste applicazioni, che in termini di manutenibilità ed evoluzione in genere porta a costi aggiuntivi nel futuro.
Dal punto di vista della complessità del sistema, se il numero di coppie di applicazioni da integrare è alto, questo può portare facilmente ad un sistema “non scalabile” dal punto di vista della complessità di gestione e di manutenzione.
File batch e allineamento dati
Molte applicazioni necessitano di accedere agli stessi dati. Per esempio è facile immaginare che nel caso di una società di servizi l‘entità “cliente”o “prodotto” sia presente in molte applicazioni.
Ad oggi spesso le applicazioni sono logicamente e fisicamente indipendenti perché la sincronizzazione fra due applicazioni avviene in processi separati e in maniera autonoma da quello che sta facendo l‘applicazione. Un esempio comune è dato dalla consistenza dei dati (data consistency) ottenuta tramite replicazione (data replication).
L‘integrazione tra programmi e dati può essere fatta tramite batch file transfer, cioè dei processi (batch) che hanno il compito di riallineare (in alcuni casi addirittura eliminando e re-inserendo) i dati da due fonti differenti.
In genere si parla poco di questo tipo di processi, ma nei sistemi informativi enterprise essi sono tuttora un importante mezzo di integrazione e rappresentano ancora una parte rilevante delle elaborazioni.
L‘argomento del trasferimento dei dati tra i vari sistemi di persistenza (datamart, database operazionali Enterprise datawarehouse, …) è delicato perché i dati possono essere presenti su più database ed essere disallineati, sia nel valore che nel significato. Occorre dunque sapere quali dati prendere da quali database operazionali e con quale semantica
Questo tipo di problemi è affrontato dagli strumenti che ricadono sotto la categoria architetturale di ETL (Extract, Trasform, Load): questi componenti prelevano i dati da un database, operano le opportune conversioni e li inviano a un altro archivio, preesistente o creato ad hoc. Sono più generici dei gateway, poiché hanno interfacce per dialogare con molti tipi di database. La tendenza di molti vendor è integrare nelle proprie offerte “pacchettizzate” (packaged) software sia di EAI “pura” (integrazione a livello applicativo) che di ETL (integrazione a livello di database), dato che i due ambiti si complementano senza sovrapporsi troppo.
P2P e “Spaghetti integration”
Lo svantaggio principale dell‘approccio P2P è che tale codice può essere complesso da sviluppare e va generato per ogni coppia di punti di integrazione. All‘aumentare delle applicazioni da integrare crescono anche le connessioni da implementare e l‘accoppiamento tra di esse con evidenti impatti sui costi di manutenzione.
A tendere, un‘architettura di questo tipo, degenera in un groviglio esponenziale di collegamenti e comporta complessità e costi di manutenzione ed evoluzione crescenti (spaghetti integration).
Molto difficilmente le soluzioni P2P realizzate saranno in qualche misura riusabili o adattabili.
Con la crescita delle applicazioni aziendali e la necessità di connettere molteplici applicazioni nello sviluppo di applicazioni Web, nel campo degli strumenti per l‘integrazione era necessario un salto in termini di funzionalità e velocità : è per questo che, rispetto ad approcci “tattici” ad hoc per le specifiche necessità punto-punto, sono nate le piattaforme EAI (Enterprise Application Integration) contraddistinte dalla presenza di un Middleware d‘integrazione che consenta un‘integrazione centralizzata, disciplinata e maggiormente standardizzata.
Integrazione Middleware Based
Per evitare i problemi sopra descritti, è opportuno definire nell‘architettura uno strato di Application Integration che permetta di centralizzare la gestione delle interconnessioni, evitando di demandare la gestione di questo problema alle applicazioni.
L‘adozione di tecnologie più sofisticate quali sistemi di Messaging, Gateway e Middleware di comunicazione non è però sufficente: nonostante consentano di semplificare le problematiche di comunicazione e supportino meccanismi sincroni e real-time, in assenza di una struttura centralizzata permanente e di una visione consistente delle problematiche di integrazione, la semplice adozione di queste tecnologie non riesce ad abbattere i costi e le complessità della “Spaghetti Integration”.
Definizione di un Middleware
Il termine Middleware genera spesso confusione. Letteralmente è lo strato software “posto nel mezzo”.
In linea con questa definizione, sono identificabili come Middleware un numero vastissimo di prodotti completamente differenti fra loro (es. Application Server, MOM, Screen Scraper).
Comunemente i Middleware sono suddivisi in tre macro-aree: Basic Middleware, Platform Middleware e Integration Middleware.
I Basic Middleware forniscono architetture consistenti per l‘integrazione tra dati ed applicazioni. Esempi di questa tipologia sono ad esempio i MOM (Webshpere MQ, Sonic MQ, TIBCO/Rendezvous, FioranoMQ, Bea MessageQ, …).
I Platform Middleware rappresentano la tipologia più complessa di Middleware.
All‘interno di questa classificazione possiamo inserire gli Application Server J2EE (IBM WebSphere, BEA WebLogic, JBoss, …), i TP Monitor (BEA Tuxedo, IBM CICS, IMS), gli ORB (Borland VisiBroker, IONA ORBIX) ed i vari Portal Server. Spesso gli Application Server forniscono, integrandole direttamente, funzionalità tipiche di TP e ORB.
Gli Integration Middleware sono infine pensati per connettere database ed applicazioni sviluppati su architetture differenti. Esempi di questa tipologia sono gli Integration Broker (IBM MQSeries Integrator; Tibco ActiveEnterprise, Microsoft BizTalk Server; Sonic ESB, Fiorano ESB …), i Business Process Managers (IBM MQSeries Workflow, Tibco InConcert2000, Vitria Technology BusinessWare Automator, Fiorano BIS, Bea WLI), i Gateways (MOM, Database e Platform) e gli Adapter.
Le più comuni funzionalità fornite da una Integration Suite sono:
- Resource Adapter (RA): risolvono i problemi di comunicazione. Quasi tutti i forni-tori EAI forniscono Adapter proprietari (sincroni ed asincroni) per la comunicazio-ne con specifici EIS.
- Messaging brokers: tipicamente operano come messaging layer (MOM) ed possono operare sia in modalità point-to-point che publish/subscribe.
- Integration Broker: si occupano del data mapping dei dati e dell‘intelligent routing (content-based e/o publish-and-subscribe). Di solito il data mapping è l‘operazione più costosa nell‘integrazione poichè tipicamente i dati acquisiti da un RA in un for-mato proprietario devono essere trasformati (sintatticamente e/o semanticamente) secondo le esigenze del business object richiedente.
- Workflow: in questo contesto si intende il coordinamento di business object e mes-saggi nell‘esecuzione di processi di business. I tool specializzati nella gestione del workflow di processi di business sono denominati Business Process Manager (BPM).
- Monitor delle attività di Business: analisi della storia degli eventi di business per tracciare l‘accuratezza, la qualità e la sicurezza delle attività di business istanziate.
Approccio diretto
L‘approccio più diretto prevede di utilizzare una semplice tecnologia di connessione (fornita dal middleware) demandando allo strato applicativo (possibilmente opportunamente inge-gnerizzato), i rimanenti problemi di integrazione (mapping, routing, transformation, …).
Un esempio interessante di soluzione di questo tipo è l‘utilizzo di connettori JCA e degli strumenti di sviluppo associati.
Tale approccio, Application server-based, prevede che nel Platform Middleware (l‘Applica-tion Server) risieda la logica di business e la logica di integrazione.
Approccio indiretto
L‘approccio Middleware-based è per così dire “meno-diretto”, infatti prevede l‘introduzio-ne di uno strato di Middleware più evoluto (nel senso che non si occupa unicamente di pro-blematiche di comunicazione). Tale strato, agendo da intermediario, centralizza sia le pro-blematiche puntuali di connessione che quelle più ampie d‘integrazione (mapping, routing, transformation, …).
Di fatto, l‘Integration Middleware assume il ruolo centrale dell‘architettura di integrazione e agisce come unica interfaccia verso il client, diventando il punto di normalizzazione tra i vari sistemi integrati. E‘ il punto centrale attraverso cui transita ogni richiesta di comunicazione tra sistemi applicativi disomogenei e dove le differenze (sintattiche e semantiche) vengono gestite e riconciliate (normalizzate).
Sul mercato sono individuabili almeno tre diverse tipologie di Middleware d‘integrazione:
- Programmatic Integration Server
- Integration Broker
- Enterprise Service Bus (ESB)
I Programmatic Integration Servers forniscono una soluzione “a basso costo”, “a basso rischio” e non intrusiva per l‘esposizione di Sistemi Legacy verso applicazioni sviluppate con nuove piattaforme.
L‘approccio non intrusivo dato da tali strumenti, si basa sul semplice riuso (wrapping) del Legacy “as is”. Ad esempio, si possono wrappare direttamente le funzionalità mainframe, lasciando quindi intatta la granularità delle funioni originali che però vengono esposte con nuove tecnologie per un uso “programmatico”.
Tale famiglia di prodotti, fornisce una via estremamente “tattica” alla realizzazione di Sistemi applicativi nuovi (dal punto di vista tecnologico e di obiettivi), sviluppati senza ristrutturazioni dei sistemi Legacy.
Generalmente tali prodotti forniscono un‘infrastruttura e strumenti di sviluppo/manutenzione proprietari.
Gli Integration Broker sono pensati per integrare applicazioni sviluppate su architetture eterogenee.
Queste funzionalità vengono tipicamente fornite (tutte o in parte) con tecnologie proprietarie dagli Integration Middleware.
Al contrario dei Programmatic Integration Servers, gli Integration Broker non rispondono soltanto ad esigenze di Legacy Integration, ma si rivolgono a scenari decisamente più ampi di Enterprise Application Integration. Per questo rispetto ai Programmatic Integration Server mettono a disposizione funzionalità più evolute e complesse.
Gli ESB sono una “rivisitazione” degli Integration Broker in ottica standard-based e basato non piu‘ su Hub ma su BUS.
Un Enterprise Service Bus (ESB) è un prodotto per l‘integrazione basato su standard di mercato e su un‘architettura orientata ai servizi.
Ma cosa differenzia gli ESB dai “normali” EAI Broker?
Innanzitutto c‘è una differenza dal punto di vista tecnologico: gli ESB espongono tramite “standard” funzionalità che i tradizionali Integration Broker fornivano tramite tecnologie proprietarie. Esempi di standard ampiamente utilizzati sono:JDBC, JCA, JMS, JMX , WSDL, UDDI, SOAP, JAX-RPC, JAXM, JAXR, SSAJ, XQuery, XPath, JBI, BP4WLS,…
La seconda differenza è architetturale: un ESB non si basa su un‘architettura “monolitica” di tipo Hub-and-spoke, ma su di una architettura distribuita a bus condiviso SOA (Service Oriented Architecture) oriented. In altre parole, in un‘infrastruttura ESB, tutte le applicazioni sono sviluppate come aggregazione di servizi, e quindi già disegnate per l‘integrazione.
Dall‘integrazione P2P ai servizi
Nella maggior parte degli scenari attuali, l‘integrazione tra programmi e dati è fatta tramite batch file transfer piuttosto che con meccanismi di accesso in tempo reale. Si implementano cioè connessioni punto a punto (via specifiche API) senza utilizzare un‘architettura/infrastruttura organica e centralizzata di integrazione.
Come già osservato, operare l‘integrazione tra applicazioni in un contesto simile comporta complessità e costi di manutenzione ed evoluzione via via crescenti, senza alcuna garanzia di raggiungere i risultati attesi.
L‘adozione di tecnologie più sofisticate quali sistemi di Messaging, Gateway e Middleware di comunicazione consentono di semplificare le problematiche di comunicazione e supportano meccanismi sincroni e real-time. In assenza di una struttura centralizzata permanente e di una visione consistente delle problematiche di integrazione, la semplice adozione di queste tecnologie non riesce ad abbattere i costi e le complessità della “Spaghetti Integration”.
Ad oggi è evidente la necessità di passare da una strategia di integrazione verticale P2P (più tattica) ad una strategia di integrazione “orizzontale” (più strategica).
La politica che ad oggi sembra essere più promettente per effettuare questo passaggio è quella di incapsulare le logiche di business da condividere e riusare in servizi SOA.
La caratteristica fondamentale di SOA è un forte pragmatismo, orientato soprattutto alla produzione di sistemi informativi complessi che siano nel contempo facilmente manutenibili, estendibili e integrabili.
Molti dei principi di SOA si sposano quindi alla perfezione con le problematiche di integrazione. In effetti, questi dettami discendono direttamente dalla consapevolezza che, se il sistema che si sviluppa ha successo, in futuro occorrerà estenderlo/integrarlo, oppure dal fatto che si ritiene necessario conservare gli asset dell‘organizzazione a fronte di una evoluzione tecnologica, in questo caso facendo esplicitamente integrazione.
La chiave di SOA è: l‘indipendenza dalla tecnologica e il disegno dei servizi stessi, che devono garantire un basso accoppiamento (loosely coupled) e avere un grado di astrazione tale da avere sia senso come servizio chiamabile singolarmente, che in composizione con altri servizi.
Fare integrazione con SOA (indicata spesso in letteratura con il termine SOI, Service Oriented Integration) significa cercare di trasformare le funzionalità già presenti in servizi, in modo da trattare poi i servizi “wrappati”in modo omogeneo con gli altri servizi.
Questa evoluzione da architetture di integrazione P2P a integrazione service-oriented è indice di una maggiore maturità architetturale delle organizzazioni che si rendono conto dei costi che derivano dall‘integrazione fatta male. Una delle chiavi di lettura di SOA può essere infatti il “disegno del sistema per l‘integrazione”.
In questa ottica oggi stanno avendo molto successo i middleware di comunicazione e integrazione “a servizi”: gli Enterprise Service Bus.
Il risultato è un servizio:
- estratto dalla logica che si vuole integrare, disegnato per il riuso (e non per un‘integrazione ad-hoc).
- disponibile a tutte le applicazioni in quanto “pubblicato” su un middleware di integrazione.
L‘approccio Rip-and-replace è stata la promessa dei sistemi ERP della seconda metà degli anni 90, quando si è tentato di avere un‘unica applicazione che coprisse tutti i requisiti del sistema informativo; l‘idea era che con un unico sistema si sarebbe evitata la Spaghetti Integration e consolidata l‘infrasturttura IT.
Questo approccio man mano che i sistemi informativi sono divenuti più complessi è parzialmente fallito perché è emerso il fatto che nei sistemi Enterprise una applicazione difficilmente riesce a coprire più del 40 percento delle necessità funzionali.
Il Rip and replace è quindi un “antidoto” parziale per la gestione dell‘eterogeneità e hai dai trade-off come la riscrittura massiva di codice nonchè nuove problematiche tecniche, sistemistiche e organizzative e … dispendioso in termini di budget.
Il Rip and replace può in certi casi ridurre il problema della spaghetti integration ma di certo non eleminarla.
La verità è che non esiste (e mai esisterà ) nessun vendor i grado di coprire il 100% dei bisogni d‘integrazione dell‘IT.
Piuttosto quindi che operare con una strategia “Rip and Replace”, è preferibile attuare strategie di Wrap and re-engineer e di Leave-and-layer, che siano più conservative sul pregresso e che siano compatibili con una logica a servizi.
Il wrapping di sistemi legaci (Legacy Integration) è ad oggi molto usato: lo si può trovare consigliato come modalità architetturale d‘integrazione, oppure presentato come pattern e/o come linea guida “SOA-enabling”. Inoltre, l‘avvento dei WebServices si sposa alla perfezione con questo tipo di strategia.
Questo permette di tenere il piede in due scarpe: salvaguardere il pregresso permettendo allo stesso tempo un‘apertura architetturale e/o tecnologica verso le nuove tecnologie
Il “leave and layer” consiste nel conservare l‘esistente portfolio dei servizi Legacy e di applicazioni esistenti , riconciliando le loro differenze (logica e dati) in un nuovo layer.
Tale layer permette di: riusare l‘esistente permettendo una razionalizzazione e consolidamento dello stesso mascherando logiche e dati all‘esterno degli endpoint da integrare. Si ottiene infine un un layer che funge da dorsale “nervosa” del sistema IT,
Utilizzare il Wrap and re-engineer e il Leave Layer in ottica di servizi SOA fornisce la possibilità di fare coesistere i sistemi eterogneeni tra di loro in un nuovo layer: il service bus.
Inoltre con questo approccio è possibile permettere un‘integrazione incrementale. Definita l‘architettura a servizi è possibile integrare man mano i sistemi (silos, isole informatiche, EIS, …) connettendoli al Service Bus.
SOA e Strategie di Integrazione
In generale SOA, come paradigma architetturale, proponendosi come obiettivo esplicito il disegno per l‘integrazione, può essere pensato come ortogonale rispetto alle specifiche istanze di strategie architetturali considerate.
Questo significa che, sia che si considerino sistemi in cui viene effettuata integrazione a livello di portale, di logica di business o di dati, è possibile (e consigliato) adottare una architettura a servizi.
Ad esempio, nel caso di PI possiamo comporre “viste” di servizi; nel caso di EAI, i servizi sono composti o orchestrati in altri servizi e infine in caso di EII, i servizi possono esporre logiche di accesso ai dati che mascherano la vera complessità dei sistemi sottostanti.
Conclusioni
In questo articolo abbiamo presentato in maggiore dettaglio la strategie di integrazione applicativa (EAI). In particolare abbiamo presentato una classificazione di queste strategie in integrazione punto-a-punto e middleware-based.
Abbiamo inoltre analizzato questi approcci in un ottica SOA, presentando l‘integrazione a servizi come una possibile evoluzione di integrazione P2P (ad-hoc) verso un‘integrazione orizzontale “middleware-based”.
In conclusione, abbiamo osservato che SOA è compatibile con tutte le strategie architetturali considerate (PI, EAI, EII): questo ne conferma ulteriormente la validità nello sviluppo di applicazioni complesse orientate all‘integrazione.
Bibliografia
[1] M. Piraccini, S. Rossini: “Architetture d‘Integrazione (I)” MokaByte 105 Marzo 2006
https://www.mokabyte.it/2006/03/integration-1.htm
[2] M. Piraccini, S. Rossini: “SOA: Introduzione” MokaByte 100 Ottobre 2005
https://www.mokabyte.it/2005/10/soa-1.htm
[3] M. Piraccini, S. Rossini: “SOA: Metodologia” MokaByte 101 Novembre 2005
https://www.mokabyte.it/2005/11/soa-2.htm
[4] M. Piraccini, S. Rossini: “SOA (III): Il Maturity Model” MokaByte 102 Dicembre 2005
https://www.mokabyte.it/2005/12/soa-3.htm
[5] M. Piraccini, S. Rossini: “SOA (IV) Roadmap” MokaByte 103 Gennaio 2006
https://www.mokabyte.it/2006/01/soa-4.htm
[6] M. Piraccini, S. Rossini: “SOA (V) SOI” MokaByte 104 Febbraio 2006
https://www.mokabyte.it/2006/02/soa-5.htm
[7] M. Piraccini, S. Rossini: “SOA (VI) ESB (I)” MokaByte 105 Marzo 2006
https://www.mokabyte.it/2006/03/soa-6.htm
[8] M. Piraccini, S. Rossini: “SOA (VII) ESB (II)” MokaByte 106 Aprile 2006
https://www.mokabyte.it/2006/03/soa-7.htm