Perché dismettere qualcosa che, anche se obsoleto, funziona? Forse perché è necessario offrire i propri servizi sul Web, forse perché occorre la possibilità di estendere e migliorare il preesistente, forse perché l‘integrazione di oggi getta le basi per affrontare le sfide di domani.
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.
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.
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!
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).
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.
1Sabratec Integration Legacy Suitehttp://www.sabratec.com/new/prd_applinx.asp2″Uso della Model Driven Architecture nello Sviluppo di Applicazioni J2EE”, parte 1https://www.mokabyte.it/2004/07/mda-1.htm3M. Blechar, M. Hotle”ARAD Methods and Tools: Improve Productivity and ROI” Gartner Group, october 11, 20044″SOA come fondamento della Infrastruttura Enterprise”www.mokabyte.it/2005/soamda.htm5″Uso della Model Driven Architecture nello Sviluppo di Applicazioni J2EE”, parte 2https://www.mokabyte.it/2004/09/mda-2.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, l‘Enterprise Application Integration.