lunedì 14 febbraio 2011

Un'introduzione alle EAI (Enterprise Application Integration)

Sempre più si sente parlare in ambito IT di integrazione di sistemi informativi: si pensi per esempio a diversi sistemi che devono scambiarsi informazioni tra loro, ma spesso sono completamente eterogenei per tecnologie, funzionalità, ambienti in cui vivono. Lo scenario è quello in cui diverse applicazioni (con scopi, tempistiche e tecnologie eterogenee), sviluppate magari in .NET piuttosto che in Java o C/C++, devono interagire tra loro su macchine differenti (p.es. 32/64 bit) e su SO differenti.
Per ovviare a tali problematiche si ricorre spesso a piattaforme standard di integrazione dette appunto EAI.
Diamo una definizione formale:

Fonte Wikipedia:
"Enterprise Application Integration (EAI) (integrazione d'applicazioni di impresa) si riferisce al processo d'integrazione tra diversi tipi di sistemi informatici attraverso l'utilizzo di software e soluzioni architetturali".

L'integrazione può essere semplice (trasferimento di dati tra due applicazioni, diverso posizionamento "fisico" dei sistemi), o complessa (esigenze di riservatezza nel trasferimento dei dati, garanzia di consegna, sicurezza ecc.). Le piattaforme EAI si occupano di risolvere l'integrazione semplice (solitamente è un integrazione interna all'azienda).
L'esigenza di avere piattaforme EAI è nata proprio dalla complessità di far interagire tra loro sistemi eterogenei: inizialmente l'interazione avveniva con soluzioni punto-punto, ossia i sistemi dialogavano tra loro a due a due con soluzioni più o meno customizzate. Tutto ciò introduceva  un grosso problema architetturale detto "degli spaghetti", ossia una proliferazione di collegamenti diretti tra i sistemi e la perdita di controllo del trasferimento dell'informazione. Una prima risposta a tale "caos" si è avuta introducendo un primo livello di astrazione (Connectors e Data Transport) dello strato "fisico" di trasporto: avere un layer di comunicazione uguale per tutti per mezzo di costrutti informatici detti connectors e adapters. Tali costrutti vengono realizzati mediante framework che implementano i vari connettori alle applicazioni oppure, se l'integrazione avviene tra due prodotti, mediante adattatori ad hoc. La distinzione tra connector e adapter veniva fatta in base al loro impiego per interfacciare tra loro tecnologie diverse, diversi prodotti o diversi database. Questo livello di astrazione introdotto è in pratica uno strato che si occupa di interfacciare tra loro diverse tecnologie e diverse infrastrutture al livello più basso. Un secondo livello di astrazione deve essere introdotto per ovviare al problema dei "dialetti": si pensi ad esempio a due database che girano su DBMS diversi che devono dialogare tra loro, ciascuno col proprio "dialetto" SQL. Lo strato delle "Trasformazioni" serve proprio per cercare di astrarre le comunicazioni tra sistemi che hanno linguaggi o parti del linguaggio differenti.
Le piattaforme EAI di prima generazione solitamente implementano questi due livelli di astrazione.
Le piattaforme di seconda generazione implementano un ulteriore livello di astrazione detto del "flusso dei processi": si può avere non solo un'astrazione del trasferimento di informazioni tra le applicazioni, ma anche delle loro funzionalità e quindi della logica su come vengono integrate.

Livelli di astrazione:
  • Connectors & Data Transport (connectors e adapters)
  • Transformations (conversioni tra dialetti)
  • Process Flows (logica di integrazione)
Ci sono principalmente due tipi di piattaforma EAI:
  • Broker Engine: questo tipo di piattaforme si concentra sul far comunicare applicazioni eterogenee. Esse consistono in un componente detto "broker engine" che si occupa di trasferire i dati da un'applicazione all'altra, ma senza entrare nei dettagli della connettività. In pratica un broker engine utilizza diversi "connector" e "adapter" che si occupano della comunicazione tra il broker e l'applicazione ad un livello di astrazione più basso. In pratica il livello di astrazione (Connectors e Data Transport) introdotto dai connector e dagli adapter permette al broker engine di dedicarsi all'esclusivo instradamento dei flussi di dati.
  • Process Mapper Engine: sono le piattaforme EAI di ultima generazione. Tali EAI si occupano della gestione dei processi. Oltre al livello di astrazione dei connectors e degli adapters viene introdotto un ulteriore livello di astrazione detto Process Flow: in pratica viene astratta la logica di integrazione (composition logic). In tale scenario si può scegliere come integrare i diversi sistemi secondo una logica dei servizi da essi offerti. Da qui alle architetture SOA (Service Oriented Architecture) il passo è breve.

Un esempio di Broker Engine è il Message Broker che si occupa di smistare messaggi tra diverse applicazioni: un Message Broker è in grado di fornire a ciascuna applicazione un adapter ad hoc, inoltre la logica di instradamento dei messaggi può essere comandata tramite una logica programmabile (composition logic). Tale logica può essere implementata tramite un WfMS (Workflow Management System).
Il Message Broker come Broker Engine


    0 commenti:

    Posta un commento

    Recent Posts

     
    Design by Free WordPress Themes | Bloggerized by Lasantha - Premium Blogger Themes | cna certification