|
Introduzione
L'integrazione non è un problema semplice. Coinvolge
aspetti economici, tecnologici, culturali ed organizzativi.
L'aspetto economico è evidenziato dal fatto che
un'organizzazione ha la necessità di evolversi
e, allo stesso tempo, conservare i propri asset aziendali.
Un'organizzazione matura con un sistema informativo
complesso sa che il cambiamento è inevitabile;
è quindi suo compito gestirlo in modo da minimizzare
l'impatto economico.
L'ambito del Business
è in continuo e rapido cambiamento; la competizione
è sempre più accesa. Le regole e gli standard
impongono alle aziende una sempre maggiore reattività
(basti pensare a standard come Basilea II, RFID, …
o a regole come SOX ...).
Oltre queste sollecitazioni
"esterne", ci sono quelle interne, che possono
essere di varia natura.
Ad esempio può
essere richiesto il raggiungimento di obiettivi di business
come l'aumento del profitto / ROI, la riduzione dei
costi, la diminuzione del time-to-market, l'ottenimento
di una maggiore customer satisfaction.
Lo stimolo inoltre
può venire anche dalla necessità del raggiungimento
di obiettivi legati ai processi aziendali, come ad esempio
la “velocizzazione” della produzione o della
consegna, il miglioramento della qualità riducendo
gli errori o i colli di bottiglia, l'aumento della flessibilità
dei processi aziendali, la possibilità di implementare
nuove soluzioni di business in modo piu' veloce ed economico
per consentire una sempre piu' facile modifica dei processi
aziendali.
Infine può
essere l'area IT che si trova a dovere affrontare questi
problemi: può nascere la necessità di
integrare applicazioni esistenti ed infrastrutture IT
corporate (a seguito ad esempio di fusioni, acquisizioni,
out-sourcing, ...) preservando ed ottimizzando sempre
più gli investimenti; in questi interventi si
affrontano molte questioni complesse. Alcuni esempi
sono: eliminare la rindondanza di funzioni e/o dati,
ridurre la complessità dei sistemi, ri-utilizzare
le applicazioni esistenti, mantenere il controllo di
efficienza ed il governo della struttura integrata per
le attuali e future applicazioni aziendali e adottare
un approccio il più possibile modulare per ridurre
anche i rischi di installazione e aggiornamento di nuove
applicazioni
Si hanno quindi
obiettivi, visioni e interessi diversi che si devono
riconciliare e che nascono dal fatto che le aziende
necessitano di un continuo adattamento per sopravvivere
e rimanere profittevoli: l'obiettivo è di rispondere
sempre più velocemente alle mutevoli sollecitazioni
esterne ed interne.
Le domande che un'organizzazione
con obiettivi di questo tipo si pone sono:
-
Come evolvo il mio sistema informativo in modo da
avere un costo il più basso possibile?
-
Come devo progettare e sviluppare un sistema oggi
in modo che il costo dell'integrazione sia basso domani?
- Come
posso raggiungere gli obiettivi di business prefissati
nel modo più “economico” e più
flessibile possibile?
Esiste anche un ulteriore
raffinamento del problema: con lo sviluppo della rete
è diventato concreto il problema dell'integrazione
a livello business, cioè la creazione di processi
B2B ottenuti componendo funzionalità che sono
esposte da organizzazioni differenti. Possiamo quindi
parlare di integrazione “interna” (normalmente
legata ad una estensione dei sistemi con nuove o vecchie
tecnologie) e integrazione “esterna”.
Per rispondere
correttamente a queste domande occorre affrontare innanzitutto
il problema dal punto di vista architetturale piuttosto
che tecnologico.
Strategie di
integrazione
Classifichiamo
le strategie di integrazione sulla base del livello
architetturale su cui agiscono.
Possiamo supporre di avere un sistema informativo a
“layer” che sia suddivisibile in:
-
Data layer
-
Business Layer
- Presentation
Layer.
Le strategie di integrazione
che considereremo sono classificabili , in prima istanza,
con il layer su cui vanno ad agire. Possiamo quindi
pensare di integrare a livello di presentazione, a livello
di logica applicativa oppure a livello di dati.
La scelta del livello
su cui si effettua integrazione è dettata da
molti fattori: “raramente” però la
scelta è stata consapevole, essendo normalmente
guidata più da considerazioni di tipo tecnologico
che architetturale (es: bisogna utilizzare un certo
tipo di strumento prodotto e/o tool) .
La prima classificazione
che possiamo fare sulle strategie di integrazione è:
-
Portal Integration
- Enterprise
Information Integration (EII)
- Enterprise
Application Integration (EAI)
Questi tre possibili
approcci architetturali sono volti ad aggiungere alle
tradizionali applicazioni "verticali", caratterizzate
da scarsa integrazione reciproca e dalla presenza di
information silos isolati, una dimensione di integrazione
orizzontale che è in grado di portare ad ulteriori
vantaggi di business mediante una maggiore efficienza
generale dei processi aziendali ed inter-aziendali.
Figura
1: EIP, EAI & EII
Portal Integration
La
Portal Integration avviene a livello di interfaccia
utente. Questo tipo di strategia è molto comune
dato che è semplice da implementare, non è
invasivo nei confronti delle applicazioni integrate
e permette di effettuare in maniera semplice e rapida
l'aggregazione di sistemi molto eterogenei tra loro.
Quello
che viene realizzato è un “accorpamento”
di diverse applicazioni su un'interfaccia comune. Un
componente (nel caso di applicazioni web l'Enterprise
Information Portal o EIP) aggrega le di diverse applicazioni,
che sono reponsabili di esporre la propria interfaccia
in un modo che sia componibile dal portale (es: Portlets).
Il
portale mostra quindi un'interfaccia composta da tutte
le applicazioni che integra.
Al
contrario della integrazione a livello di business logic
(che aggrega elaborazione di sistemi diversi), nel caso
di integrazione a livello di portale le informazioni
provenienti da sorgenti multiple e differenti vengono
visualizzate in una singola finestra.
Questo avviene normalmente dividendo lo schermo in diverse
zone ognuna delle quali comunica con un differente sistema.
Figura 2: Portal Integration
I
processi di business sono di fatto eseguiti dagli utenti
del portale, che effettuano le interazioni sulla base
dei dati esposti.
Ad esempio, è possibile pensare di integrare
un'applicazione di customer-care ed un'applicazione
di gestione di dati bancari: l'operatore può
visualizzare sulla stessa interfaccia il conto corrente
associato ad un utente (sulla “zona” dedicata
all'applicazione di customer-care) e effettuare delle
operazioni sul conto corrente di questo utente sulla
seconda applicazione (sull'altra zona). In questo caso
l'eventuale mismatch semantico tra i dati esposti dalle
due applicazioni viene risolto direttamente dall'operatore.
Il
portale diventa di fatto il punto centrale di accesso
per insieme eterogeneo di applicazioni. Nel caso di
applicazioni web (che è il caso più frequente)
questo si realizza tecnologicamente ad esempio tramite
normali tecniche HTML (frame, link o window open), oppure
tramite Portlet.
Portlet: il componente applicativo di portale in J2EE
In
ambito J2EE le Portlet sono state introdotte con le
specifiche JSR 168 (la versione 1.0 rilasciata nell’Ottobre
2003).
Tali
specifiche definiscono:
-
Il ruolo e le responsabilità del Portlet Container
(cioè il portale)
- Il
ruolo e le responsabilità de Portlet, che espongono
le applicazioni integrate nel portale
- Il
contratto tra il Container e le Portlet
- la
gestione del ciclo di vita delle Portlet
- le
relazioni tra Portlet, Servlet e JSP
- I
servizi middleware necessari alle Portlet.
Le
applicazioni integrate possono essere esposte tramite
Portlet installate su un PortletContainer. Una Portlet
compatibile con le API definite dalle specifiche può
essere installata su un Container compatibile con lo
stesso livello di specifiche, di fatto garantendone
la portabilità su portali differenti. Questo
rende possibile anche l'acquisto di Portlet da aziende
esterne, integrabili all'interno del proprio portale
aziendale.
In
conclusione questo tipo di integrazione è interessante
nel momento in cui si richieda una soluzione veloce
e non invasiva (e, di conseguenza, poco costosa). In
alcune situazioni questo è sufficente e può
essere una strategia vincente. In altri casi è
necessario effettuare azioni più complesse, agendo
sulla business logic o sull'accesso ai dati.
EAI
Enterprise
Application Integration (EAI): in questo caso ci 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 sia i dati che la logica possono
vivere indipendentemente, in questo caso parte della
logica di business è necessariamente condivisa.
Possiamo
classficare l'integrazione EAI secondo due possobili
approcci:
-
Verticale (P2P – Point-to-Point)
-
File batch / reinserimento dati
- Soluzioni
applicative punto punto
-
Centralizzata (Middleware-based)
-
Application Server-based
-
Programmatic Integration Server
- Integration
Broker
- Enterprise
Service Bus
In
un'integrazione Punto-Punto si costruiscono le singole
connessioni tra le Applicazioni gestendo singolarmente
i problemi di comunicazione e di mapping dei dati.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 (in modo mirato)
non solo le necessarie conversioni dei dati, ma anche
le regole di business.
Lo svantaggio principale è che tale codice può
essere complesso da sviluppare e va generato per ogni
coppia di applicazioni. 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.
Figura 3 - Integrazione Punto-Punto
/ Middleware-based
Per
evitare i problemi sopra descritti, è opportuno
definire ed integrare nell’architettura un opportuno
strato di Application Integration che permetta di isolare
le applicazioni centralizzando la gestione delle interconnessioni.
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. Tale
approccio può essere a sua volta “diretto”
o “indiretto”. L’approccio
più diretto prevede di utilizzare una semplice
tecnologia di connessione e comunicazione, demandando
allo strato applicativo (possibilmente ingegnerizzato),
le ulteriori problematiche di integrazione (mapping,
routing, transformation, …).
L’approccio
“meno diretto”, Middleware-based, prevede
l’introduzione di uno strato di Middleware più
o meno evoluto. Tale strato, agendo da intermediario,
centralizza sia le problematiche puntuali di comunicazione
che quelle più ampie d’integrazione.
EII
Enterprise
Information Integration (EII): relativamente nuovo,
almeno rispetto ai due precedenti, questo approccio
è incentrato sull'integrazione a livello dati.
Si basa sul concetto che in alcune organizzazioni il
problema non è legato tanto alla condivisione
della logica quanto ad avere una modalità di
accesso ai dati centralizzata, omogenea e condivisa.
In questo caso si ritiene che l'integrazione a livello
di logica applicativa non sia necessaria: l'obiettivo
è avere applicazioni che agiscono sugli stessi
dati, che devono essere quindi accessibili in maniera
omogenea.
Questo si realizza mediante l'uso di una serie di tecnologie
tra le quali la più peculiare è quella
"federation" (database federation), che implementa
un concetto di "database virtuale".
L'EII
ha l'obiettivo di raggiungere un’integrazione
a livello dati che complementi gli altri approcci al
problema generale dell'integrazione, e sia in grado
di assicurare:
-
una vista completa e tempestiva ed univoca (!) su
entità ed eventi critici a livello aziendale
-
connettività, accessibilità e utilizzabilità
dei dati a prescindere da specifiche piattaforme,
database, formati (inclusi i dati non strutturati)
- consistenza
a livello enterprise dei dati che sono a fondamento
di applicazioni diverse tra loro correlate (ad esempio
a fronte di replicazione).
L'EII si concretizza nella realizzazione di uno strato
di Middleware che da un lato sia accessibile ad ogni
tipo di applicazione e tool mediante interfacce standard,
e dall'altro sia in grado di accedere ed agire su ogni
tipo di dato e informazione, qualunque sia la natura,
la forma (strutturata, semi-strutturata, non strutturata),
la locazione fisica, fornendo sui dati stessi una serie
di servizi che, superando il tradizionale acceso "a
silos applicativi", ne consentono un utilizzo ottimale
da parte di ogni utente e ogni processo aziendale.
Figura
4 - EII
SOA e integrazione
Dall'esperienza
degli architetti sulle problematiche di sviluppo e integrazione
è nata la definizione di una serie di best-practices
che globalmente vengono indicate con il termine Service-Oriented
Architecture (SOA).
SOA è un nuovo paradigma architetturale basato
sui concetti di servizio e di processo.
La caratteristica fondamentale di questo approccio è
un forte pragmatismo, orientato soprattutto alla produzione
di sitstemi informativi complessi che siano nel contempo
facilmente manutenibili, estendibili e integrabili.
Il
presupposto che guida SOA è la considerazione
che conviene sviluppare sistemi già pensando
all'integrazione (il cambiamento è inevitabile)
piuttosto che adattarli volta per volta.
Un
servizio è una funzionalità (con un preciso
significato di business) che deve essere disegnato seguendo
una serie di dettami architetturali.
Molti
dei principi di SOA si sposano 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à
integrarlo. Oppure dal fatto che si ritiene necessario
conservare gli asset dell'organizzazione, in questo
caso facendo esplicitamente integrazione.
L'applicazione
dei principi di SOA alle problematiche d’integrazione
viene indicato con il termine Service Oriented Integration
(SOI), che prevede lo sviluppo di Integration Services.
Un
Integration Service ha lo scopo di fornire un’interfaccia
a servizi di applicazioni esistenti portando a fattore
comune funzionalità o dati trasversali alle applicazioni.
Per
quanto riguarda EAI e SOA, si può dire che nell'evoluzione
generale dei sistemi IT verso la Service Oriented Architecture
le funzionalità da integrare devono essere esposte
tramite una logica a servizi.
Tali
servizi, detti Functional Integration Service, possono
permettere l'accesso e l'utilizzo di funzionalità
di business da parte di qualunque altro servizio, applicazione
o utente finale.
Per
quanto riguarda invece EII e SOA, trova posto anche
l'emergere dell'EII nel ruolo chiave di fornitore di
Data Integration Service (o Information Service) a livello
enterprise; in questo caso questi servizi sono resi
disponibili alle altre applicazioni mediante l'elemento
portatante della SOA stessa costituito dall'Enterprise
Service Bus.
Figura
5 - P.I, EAI, EII & SOI
Conclusioni
Abbiamo
introdotto una classificazione delle principali strategie
adottate sino ad oggi nell’ambito IT per l'integrazione
nei sistemi informativi complessi.
Queste strategie (PI, EAI, EII) differiscono tra loro
in base al layer architetturale su cui si effettua integrazione.
La PI (Portal Integration) effettua un accorpamento
di diverse applicazioni in un'unica interfaccia utente,
l'EAI (Enterprise Application Integration) prevede l’integrazione
a livello di business-logic mentre l'EII (Enterprise
Information Integration) propone un approccio orientato
ai dati.
Abbiamo inoltre presentato SOA / SOI come la soluzione
architetturale più adattabile al cambiamento,
introducendo concetti che si dimostrano essere ortogonali
e trasversali alle strategie d’integrazione presentate.
Bibliografia
[MOKA_SOA_I]
M. Piraccini, S. Rossini: SOA: Introduzione - MokaByte
100 - Ottobre 2005
http://www.mokabyte.it/2005/10/soa-1.htm
[MOKA_SOA_II] M. Piraccini,S. Rossini: SOA: Metodologia
- MokaByte 101 - Novembre 2005
http://www.mokabyte.it/2005/11/soa-2.htm
[MOKA_SOA_III] M. Piraccini,S. Rossini: SOA (III): Il
Maturity Model - MokaByte 102 - Dicembre 2005
http://www.mokabyte.it/2005/12/soa-3.htm
[MOKA_SOA_IV] M. Piraccini,S. Rossini: SOA (IV) Roadmap
- MokaByte N.103 - Gennaio 2006
http://www.mokabyte.it/2006/01/soa-4.htm
[MOKA_SOA_V] M. Piraccini,S. Rossini: SOA (V) SOI -
MokaByte N.104 - Febbraio 2006
http://www.mokabyte.it/2006/02/soa-5.htm
[MOKA_SOA_VI] M. Piraccini,S. Rossini: SOA (VI) ESB
(I) - MokaByte N.105 - Marzo 2006
http://www.mokabyte.it/2006/03/soa-6.htm
|
