Per rendere più veloci le applicazioni legacy e risparmiare, le aziende IT hanno un’ampia gamma di opzioni, potendo scegliere tra migliorare l’hardware, il software o i servizi. Una strategia di transizione può essere rappresentata semplicemente dall’aggiunta di interfacce Web ad applicazioni legacy già esistenti, andando così a facilitare il mantenimento di una vecchia applicazione sul mainframe e, al tempo stesso, rendendo possibili applicazioni che si colleghino al mainframe con servizi Web.
Poiché una migliore elaborazione dei servizi Web viene inserita all’interno di nuovi mainframe, molte aziende stanno aggiungendo hook XML (eXtensible Markup Language) nativi nelle loro applicazioni COBOL (COmmon Business-Oriented Language). Il mainframe continuerà, così, a rimanere una piattaforma utilizzabile anche con l’evolversi delle SOA (Service Oriented Architecture) e l’aggiunta di funzionalità sempre più numerose alla piattaforma mainframe core, spiega Mark Neft, esperto di Application Portfolio Optimization and Renewal di Accenture. Per esempio, CICS (Customer Information Control System) e IMS (IP Multimedia Core Network Subsystem) dispongono entrambi di meccanismi per partecipare direttamente come provider o consumer. Esistono anche tool per automatizzare la creazione di WSDL (Web Services Description Language) dalle transazioni esistenti o i copybook COBOL.
Le aziende con un’ampia base installata di applicazioni terminal devono comunque fare attenzione, perché vanno a incorporare i loro mainframe in un sistema SOA. In pratica, il semplice wrapping di queste applicazioni in un emulatore di terminale può sembrare simile a un percorso di upgrade relativamente incrementale.
Ma Neft mette in guardia sul fatto che questo può, talvolta, danneggiare il sistema. Neft ha visto clienti tentare di utilizzare un tool di wrapping 3270 per l’integrazione di applicazioni mainframe, solo per scoprire in un pilot che le richieste sul sistema erano tali da sottoporre il mainframe a un carico eccessivo. Ciò era provocato dal modo in cui erano strutturate le loro schermate.
L’allontanamento dalle applicazioni terminal sta spingendo le aziende e i programmatori Cobol a riflettere su come possono ricreare applicazioni esistenti su un’interfaccia Web. “Per quanto riguarda i mainframe, i miglioramenti da un punto di vista hardware e software hanno reso più vantaggiose le applicazioni che interagiscono via Web – ha detto Neft -. Per esempio, la capacità, per CICS e IMS, di partecipare a messaggi basati su SOAP (Simple Object Access Protocol – ndr) rende semplice la creazione dell’interfaccia Web interattiva”.
Le prestazioni delle applicazioni in grado di interagire con i servizi Web miglioreranno nel tempo ora che il parsing TCP/IP (Transmission Control Protocol/Internet Protocol) viene ottimizzato con meccanismi come il z Integrated Information Processor (zIIP), un processore ideato specificatamente per alleggerire i servizi del processore principale, come l’accesso remoto DRDA (Distributed Relational Database Architecture) via TCP/IP, che include XML, JDBC (Java DataBase Connectivity) e ODBC (Open Database Connectivity). Può anche aumentare la quantità di elaborazione parallela.
Questo renderà il mainframe una piattaforma interessante per applicazioni mission critical che richiedono servizi di messaggistica Web ad alte prestazioni. Neft prevede che la tendenza generale sarà quella di allontanarsi dalle applicazioni di wrappering. È più sensato trasformare applicazioni legacy in modo tale che possano partecipare sia come utenti che provider di servizi che utilizzano un’interaccia Web (soprattutto SOAP).
Ci sono molti importanti aspetti da considerare quando si pensa al wrappering, alla migrazione o a riscrivere le applicazioni mainframe, afferma Neft. Nel valutare e confrontare i pro e i contro del riscrivere o del consentire i servizi a un’applicazione mainframe, si deve tener conto della durata dell’arco di vita dell’applicazione, se supporta bene le attuali esigenze di business e quanto potrebbe essere facile modificare l’applicazione in futuro.
Pensando alla migrazione, bisogna controllare le dimensioni dell’applicazione, il suo attuale costo e l’ecosistema di servizi che l’applicazione supporta. Potrebbero anche esserci dati residui e dipendenze sul mainframe, il che potrebbe influire in modo inatteso sulle prestazioni o i costi totali.
Attenzione: devono essere considerati anche i costi di migrazione e i rischi del progetto o di un malfunzionamento del servizio, che potrebbero annullare il risparmio preventivato.
