Parliamo un pò di SOA (Service Oriented Architecture)

Dopo aver visto un’introduzione alle EAI, veniamo al passo successivo che si è avuto nel panorama dell’integrazione dei sistemi informativi: le soluzioni SOA (Service Oriented Architecture). La grande diffusione del Web ha portato le architetture legate ad esso a grandi trasformazioni passando dalla costruzione di semplici siti web, ai portali aziendali fino alle soluzioni che integrassero le infrastrutture IT.

Agli inizi degli studi dei problemi di integrazione di applicazioni si avevano le cosiddette applicazioni distribuite (Object Oriented Architecture, OOA): componenti realizzati con tecnologie differenti potevano cooperare tra di loro dando vita ad un’applicazione unica secondo protocolli standard (es. CORBA, DCOM).  A questo livello agivano le EAI: far interagire tra loro applicazioni/componenti del tutto eterogenee.

Ci si è resi conto però dei vantaggi di un approccio differente, a servizi distribuiti (web services): si poteva accedere a tali servizi usufruendo dell’interfaccia che tali web services fornivano secondo un contratto (WSDL) e un protocollo (SOAP) standard. Eventualmente tali servizi potevano essere ricercati e scoperti (discovered) in una lista di servizi disponibili (UDDI). Il vantaggio di questo approccio (SOA) rispetto a quello precedente (OOA) consisteva nel fatto che veniva posto il focus sulle funzionalità e non sulle tecnologie.

In altre parole l’approccio SOA mette in evidenza un’entità nota maggiormente al management aziendale di quanto lo fossero le implementazioni tecnologiche, ossia metteva al centro dell’attenzione il processo di business.

Un’architettura SOA è qualcosa di più complesso di un’architettura a WS, nonostante possiamo affermare che essa si possa anche fondare sui concetti tecnologici dei WS. In realtà un’architettura SOA sta ad un livello di astrazione superiore di una struttura a WS: possiamo affermare che un’architettura SOA è

“Un paradigma per l'organizzazione e l'utilizzazione delle risorse distribuite che possono essere sotto il controllo di domini di proprietà differenti. Fornisce un mezzo uniforme per offrire, scoprire, interagire ed usare le capacità di produrre gli effetti voluti consistentemente con presupposti e aspettative misurabili” - Reference Model for Serviced Oriented Architecture 1.0.”, OASIS,12 ottobre 2006 (Oasis è un consorzio mondiale fondato nel 1993 che regolamenta le convergenze degli sviluppi e l’adozione di standard di e-business).

SOA è pertanto un paradigma che si traduce in un’architettura dinamica con la quale il progetto e lo sviluppo delle soluzioni sono portate a livelli di ragionamento più elevati. Tali ragionamenti permettono di  valutare in modo più completo i processi aziendali, considerandoli nel loro insieme e non solo singolarmente, e, quindi, a ricercare lo sviluppo della migliore soluzione possibile che realizzi le operazioni di business richieste .

Quindi SOA non è una tecnologia, ma un approccio architetturale costruito attorno alle tecnologie esistenti. Promuove un insieme di pratiche, discipline, modalità di disegno e linee-guida che possono essere applicate usando una o più tecnologie. SOA propone lo sviluppo di nuovi servizi basati su funzionalità già offerte da un’applicazione. Altre applicazioni che desiderano comunicare con questa applicazione, faranno uso di uno o più servizi per realizzare il compito desiderato.

Il paradigma SOA si basa su tre concetti basilari:

• Visibilità:  capacità di trovare il servizio più idoneo alle proprie necessità
• Interazione: capacità di richiesta di un servizio e conseguentemente di esaudizione della richiesta mediante scambio di messaggi.
• Effetti reali: capacità di dare i risultati dell’interazione.

Si nota come tali concetti non definiscano altro che le proprietà di un servizio: un servizio viene erogato quando si svolgono attività per conto di un richiedente (service consumer). Il servente (service provider) garantisce la propria offerta di servizio, la propria capacità di svolgerlo e la descrizione delle specifiche con le quali si può invocare correttamente il servizio offerto. La descrizione del servente viene resa pubblica mediante una discovery agency (service broker), un repository o una directory.

SOA è uno degli ultimi paradigmi della Web Engineering: generazione di servizi e creazione delle condizioni per la meccanizzazione dei processi all’interno degli asset informativi aziendali attraverso delle composite applications. Scegliere una soluzione SOA rispetto ad una OOA significa assumere per l’architettura queste proprietà:

• Effettivo riuso e migliore “granularità” del servizi
•  Interoperabilità dei servizi e loro componentizzazione in servizi più semplici (composite application)
• Assunzione di standard generici e/o specifici di certi domini
• Identificazione e accessibilità ai servizi standardizzata
• Monitoraggio della soluzione (IT governance)
• Incapsulamento dei servizi
• Accoppiamento debole tra i servizi (loose coupling) mediante messaggi XML standard
• Regole di interazione tra i servizi mediante contratti definiti
• Maggiore astrazione dalle logiche di implementazione
• Possibilità di suddivisone dei servizi per macro-funzionalità
• Autonomia di ciascun servizio nel definire la propria logica implementativa
• Rintracciabilità dei servizi mediante costrutti noti e standard

Semplificando possiamo dire che SOA ricontestualizza il paradigma nato con le OOA alla rete e ad Internet. I nuovi livelli di astrazione introdotti permettono di ridurre notevolmente il gap presente tra le logiche dei processi di business e i sistemi IT.

Schema modulare di un'architettura SOA

Read more »

Posted in: composite applications,CORBA,DCOM,EAI,Integrazione,Oasis,OOA,Processo di business,SOA,SOAP,UDDI,Web Engineering,WSDL

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

Read more »

Posted in: EAI,Integrazione,Message Broker,SOA,WfMS,Workflow