Introduzione
Anno nuovo, vita nuova! La nostra azienda ha in casa tante
applicazioni più o meno obsolete, è ora
di rimodernare, recuperando e riutilizzando ciò
che non è conveniente riscrivere e riscrivendo
ciò che va ormai dismesso: parliamo di Enterprise
Application Integration o EAI se si preferiscono gli acronimi,
una sigla dietro cui si cela un insieme di processi e
attività tutt'altro che banali. Giga Group, in
un report di qualche tempo fa, la definiva "
..la
sfida di reperire strumenti e tecnologie tali da offrire
la più semplice transizione possibile verso il
web nel breve termine, e al tempo stesso un cammino di
migrazione verso architetture a componenti nel lungo termine".
Si tratta in effetti di fare i conti con un asset IT in
molti casi un tantino superato ma pienamente funzionante
in esercizio, con l'esigenza di affacciarsi sul web per
conoscere e farsi conoscere, magari per offrire anche
i propri servizi applicativi, cercando di essere competitivi,
di non dilapidare il proprio budget, di "arrivare"
presto sul mercato, di offrire valore aggiunto, di porre
le basi per una ristrutturazione che funzioni oggi ma
che resti valida anche per il domani. Questo è
proprio l'argomento del presente articolo, in cui si cercherà
di fare il punto su queste problematiche, di porsi delle
domande e di cercare una chiave di lettura e di analisi
per possibili risposte.
EAI: le diverse fasi
Il processo di modernizzazione di una infrastruttura
IT segue, sempre secondo quanto affermato da Giga Group,
alcune fasi fondamentali, che devono necessariamente
tener conto sia di ciò che al momento è
presente "in casa", sia dei diversi possibili
strumenti che possono essere impiegati, con un occhio
attento a tempi, costi, valore aggiunto. Giga Group
sintetizza il tutto nel grafico riportato nella figura
1.
Figura
1
Le fasi dell'Enterprise Application Integration
Vale la pena di notare la forma del grafico di figura,
che lascia intendere come, superata una fase iniziale
abbastanza "critica" di start up, piccole
variazioni in termini di cambiamento (ascissa) producono
considerevoli variazioni in termini di business (ordinata).
Il problema è intraprendere la prima parte del
cammino, quella più pesante e con meno ritorno
sugli investimenti. Pronti a iniziare allora? Allacciamo
le cinture
.
Fase 1: Analisi del Codice
Si tratta di una delle fasi maggiormente critiche, proprio
in quanto responsabile dell'avvio dell'intero processo.
Mai come in questo caso, il modo di dire "partire
col piede giusto" si rivela appropriato. Il problema
di base è che la realtà infrastrutturale
con cui è necessario confrontarsi è complessa,
è pienamente funzionante, e poco o per nulla
documentata
in casi come questo, per usare
un termine molto in voga, è una realtà
"Legacy". La parola "Legacy" significa,
letteralmente, "lascito ereditario", e indica
quanto preesistente in termini di infrastruttura: sostanzialmente,
è l'ingrediente di base del nostro percorso EAI,
ossia proprio ciò che dobbiamo modernizzare.
"Legacy è tutto ciò che funziona",
affermava Gartner Group qualche tempo fa, e considerando
che - sempre secondo Gartner Group - si stima che un
buon 80% delle informazioni "business-critical"
nel mondo risieda su sistemi Legacy, si può facilmente
comprendere quanto delicato sia il discorso che stiamo
affrontando. E quando si parla di sistemi cosiddetti
Legacy si fa riferimento a infrastrutture basate su
host di tipo IBM OS/390, ma anche AS/400, UNIX
.sistemi
nati e cresciuti in un'epoca "monolitica",
in cui il server centrale, con elevate capacità
di calcolo e memoria, serviva un insieme di terminali
tutt'altro che "intelligenti"
.ma questo
poco importava, dato che di "intelligenza"
lui ne aveva in abbondanza
come mettere mano
a una simile realtà? Ma soprattutto, cosa andare
a cercare, esaminare, eventualmente modificare? E in
quale modo? Ad esempio, nel caso in cui si desideri
operare su sistemi host di tipo OS/390 su cui risiedono
applicativi COBOL/CICS sarà molto importante
verificare se quando a suo tempo sono stati scritti,
è stato rispettato il paradigma cosiddetto DPL
(Dynamic Program Link), valido a partire dalla release
3.3 del CICS, che sostanzialmente prevede una netta
separazione tra la parte "presentation logic"
e la parte "business logic". Se abbiamo a
che fare con applicativi DPL-compliant, sarà
molto più semplice "isolare" la sola
parte di "business logic" e concentrarsi su
di essa per effettuarne la analisi e predisporne l'invocazione.
Per fortuna, sono disponibili sul mercato alcune soluzioni
(ad esempio [1], figura 2) che offrono la possibilità
di effettuare approfondite analisi del codice "Legacy"
anche se è non-DPL-compliant, fornendo anche
informazioni di tipo "navigazionale" tra le
diverse parti dell'applicativo medesimo, e predisponendone
poi la "pubblicazione" sul web tramite Web
Services, e l'interfacciamento tra Web e EIS-tier tramite
componenti di tipo Java Servlet.
Figura
2
Navigational paths in applicativi COBOL
Fase 2: Nuova User Interface
Alcuni anni fa si parlava di "screen scraping",
un modo di dire piuttosto pittoresco per indicare il
fatto che si era semplicemente "cambiato il vestito"
alle applicazioni Legacy, limitandosi a individuare
e distaccare le sole parti di "presentation",
sostituendole con altre decisamente più accattivanti.
Tutto il backend restava inalterato, ma almeno il "vestito
nuovo" conferiva loro un look&feel decisamente
migliore e soprattutto moderno. Ad esempio, se diamo
un'occhiata alla figura 3, notiamo una notevole differenza
tra le due interfacce
.eppure la business logic
che c'è dietro è la stessa!
Figura
3
Rinnovare la GUI
Non è tutto oro ciò che è luce,
direbbe un proverbio, e certamente l'operazione di rinnovo
"cosmetico" dell'interfaccia è importante
almeno quanto le altre. Occorre tenere sempre bene a
mente che una volta riprogettata la nuova user interface
il lavoro da compiere è appena iniziato, evitando
l'errore che a volte si commette di fermare qui il cammino
di modernizzazione.
Fase
3: Accesso a dati eterogenei
Qui si inizia a parlare di integrazione vera e propria,
anche se per il momento esclusivamente da un punto di
vista delle sole fonti di informazioni utilizzate. E'
infatti perfettamente possibile che, trovandoci a dover
effettuare modernizzazione della nostra infrastruttura
"Legacy", si desideri estenderne le potenzialità
di interfacciamento con sorgenti dati esterne (database),
prevedendo la possibilità di averne di vari tipi
e provenienti da differenti vendor. Sarà pertanto
di vitale importanza, in questo caso, prevedere di sganciare,
ove possibile, la nostra infrastruttura applicativa
dalla dipendenza di un determinato database, proprio
al fine di rendere l'eventuale modifica per accesso
ad un altro, ovvero l'inserimento di uno ulteriore quanto
più "indolore" possibile....JDBC del
mondo Java è solo una delle possibili risposte,
per nostra fortuna già da tempo disponibile.
Fase
4: Integrazione con altre applicazioni
Ed eccoci alla fase che ha come scopo preciso quello
di creare un "collante" tra i diversi applicativi
già presenti all'interno del proprio parco applicativo,
risolvendo le problematiche di invocazione, e decidendo
cosa riscrivere e cosa riutilizzare. Storicamente, CORBA
nacque proprio per questo obiettivo, solo in parte raggiunto,
data la complessità intrinseca conseguente ad
un simile approccio. Il mondo J2EE recupera alcuni dei
punti di forza della filosofia CORBA, e definisce diverse
modalità di interazione con applicativi o parti
di essi differenti, posti remotamente e anche sviluppati
con tecnologie differenti: JCA e JMS, tanto per citare
due degli strumenti che la piattaforma J2EE offre al
riguardo.
Fase
5: Sviluppo nuove funzionalità
L'appetito vien mangiando, dice un noto proverbio. E'
altamente probabile che, se abbiamo fin qui seguito
con successo il cammino di figura 1 (vedi più
sopra), ci troviamo nella parte alta della parabola
raffigurata nella medesima figura, laddove una piccola
variazione di ascissa (effort nel cambiamento) produce
un elevato ritorno in termini di business. E allora
perchè non approfittarne? Se ad esempio si è
scelto di riprogettare il nostro processo di EAI servendosi
di metodologie altamente produttive come MDA ([2]),
si ha a disposizione, arrivati a questo punto, una potente
infrastruttura completamente integrata in cui è
possibile non solo controllare quanto già esiste,
ma anche creare ex-novo ciò che si desidera utilizzando
i formalismi tipici di MDA, come UML.....ottenendo in
tal modo la possibilità di progettare a livello
di business (livello alto), e di riflettere quanto progettato
nei livelli più bassi (modelli applicativi e
codice), proprio grazie al fatto che i livelli più
bassi sono stati costruiti in modo completamente integrato
con la realtà IT da cui eravamo partiti (figura
4).
Figura 4 Infrastrutura Integrata
Conclusioni
Enterprise Application Integration: un complesso insieme
di problematiche, metodologie, strumenti e tecniche
per affrontare la sfida della modernizzazione su larga
scala di un asset IT che si considera obsoleto. Come
abbiamo avuto modo di constatare nel corso di questo
articolo le sfide sono tante, vanno affrontate con le
metodologie e tecnologie appropriate e gli strumenti
giusti ([3]) e comportano un diverso livello di effort
rispetto al ritorno che si può ottenere, che
varia considerevolmente lungo il cammino. Se è
vero però che la posta in gioco è alta,
è pur vero che elevato è il livello del
risultato che è possibile ottenere. Non fermiamoci
all'idea di aver ottenuto una infrastruttura integrata
web-based, interfacciata con svariate realtà
IT e in cui è possibile con relativa facilità
e molta efficienza inserire nuove funzionalità.
Pensiamo anche che il corretto approccio nell'ottenere
un simile risultato può permetterci ad esempio
di pervenire a infrastrutture aziendali altamente efficienti
in grado di offrire i propri servizi anche all'esterno,
le cosiddette architetture SOA ([4]). Una nuova sfida
da raccogliere? Tutt'altro, si tratta piuttosto di un
risultato facilmente accessibile se ci basiamo su solide
fondamenta.
Bibliografia
[1]
Sabratec Integration Legacy Suite, http://www.sabratec.com/new/prd_applinx.asp
[2] Mokabyte - "Uso della Model Driven Architecture
nello Sviluppo di Applicazioni J2EE, parte 1 http://www.mokabyte.it/2004/07/mda-1.htm
e parte 2 http://www.mokabyte.it/2004/09/mda-2.htm)
[ 3]
M. Blechar, M. Hotle ARAD Methods and Tools: Improve
Productivity and ROI - Gartner Group, october
11, 2004
[4]
Mokabyte - " SOA come fondamento della Infrastruttura
Enterprise, www.mokabyte.it/2005/soamda.htm
Doriano Gallozzi è
nato a Roma nel 1964 e si è laureato in Ingegneria
Elettronica (indirizzo Informatica) nel 1989. Da sempre
interessato a problematiche di analisi, progettazione
e sviluppo di Sistemi Informativi, ha lavorato per diversi
anni in aziende del settore informatico italiano (gruppo
ENI, gruppo Telecom Italia), dove ha acquisito diverse
esperienze tanto nel campo della progettazione e sviluppo
del software (in ambiente M/F come in ambiente distribuito)
quanto nel campo dei RDBMS (DBA su diversi progetti
per clienti finali quali Telecom Italia). Da gennaio
2000 lavora nella Divisione Prevendita di Compuware
Italia. La sua attività verte principalmente
sulla piattaforma J2EE e tecnologie correlate, ma anche
su ambiti tecnologici quali le soluzioni di Project
Management per IT-Governance, i Portali Web, gli strumenti
di Business Process Automation, lEnterprise Application
Integration.
|