BACKGROUND

La migrazione dei sistemi legacy mainframe su nuove piattaforme  ha ricevuto molta attenzione, poiché le organizzazioni devono passare a soluzioni software distribuite e abilitate per il Web.

Sono stati esplorati diversi approcci, che vanno dall'avvolgimento di sistemi esistenti con livelli software abilitati per il Web, a approcci di conversione automatici 1-a-1 per la conversione di programmi in COBOL in 4GL. Pertanto, la letteratura attuale presenta molti rapporti relativi alle esperienze.

Poiché la migrazione è stata un problema da quando i primi sistemi aziendali hanno iniziato a diventare obsoleti, c'è attualmente molto lavoro su questo argomento. Ad esempio, i ricercatori hanno sviluppato diverse metodologie per migrare il sistema dalla loro tecnologia originale a nuove tecnologie, come Cold Turkey, Chicken Little e Renaissance. Tuttavia, queste metodologie non affrontano esplicitamente come migrare i sistemi in SOA.

Per risolvere questo problema, i ricercatori hanno sviluppato una tecnica di migrazione e riutilizzo orientata ai servizi (SMART) per la selezione delle strategie di migrazione, ma mancano strumenti per aiutare gli sviluppatori ad applicarlo. Inoltre, SMART non considera la qualità della frontiera SOA come una preoccupazione principale in questo tipo di migrazione.

Un'altra metodologia di migrazione da COBOL a SOA è SOAMIG che, al contrario di SMART, fornisce sia una metodologia di migrazione che strumenti. La metodologia di migrazione consiste di quattro fasi e ciascuna di queste fasi può essere eseguita in diverse iterazioni. L'idea principale alla base di SOAMIG è quella di trasformare il sistema originale in uno orientato alla SOA utilizzando diversi strumenti di traduzione. Ad esempio, propone di utilizzare uno strumento che traduca il codice COBOL in codice Java che è più facile da esporre come servizio Web. Tuttavia, questo approccio potrebbe avere un impatto negativo sulla qualità della frontiera SOA perché il codice COBOL è stato progettato utilizzando criteri di progettazione scaduti, e questo tipo di privilegio non ha consentito il controllo del sistema. Oltretutto, COBOL impone limitazioni alla lunghezza di nomi e commenti di routine che potrebbero essere probabilmente tradotti nella frontiera SOA, che potrebbe anche rappresentare un problema di qualità per la frontiera SOA.

In questo contesto, la migrazione dei sistemi legacy alla SOA, pur ottenendo interfacce di servizio di alta qualità invece di "semplificare" i sistemi, è un tema di ricerca incipiente.

Harry Sneed ha la necessità di ricercare costantemente i programmi COOL di COOL sui servizi Web e di misurare la qualità delle interfacce di servizio. L'autore presenta uno strumento per identificare i programmi COBOL che possono essere serviti. Le basi di strumenti che organizzano i computer a partire dal tuo computer determinano la complessità del programma, e quindi suggerisce se i programmi debbano essere incapsulati o nuovamente progettati. In quanto tale, la complessità dei programmi guida la selezione della strategia di migrazione.

I progetti di Sneed per analizzare le interfacce di servizio utilizzano una metrica particolare, che comprende 25 quantità, 4 dimensioni, 5 complessità e 5 parametri di qualità. Egli presenta inoltre un framework e delle linee guida per migrare un sistema legacy in SOA, che mira a definire una frontiera SOA avendo solo i servizi "ottimali" e con un livello appropriato di granularità. Il quadro è costituito da tre fasi. Il lavoro consiste nel formulare i sistemi principali e le interazioni che utilizzano l'LL.

Al termine del processo, i processi di servizio e i processi di servizio sono identificati. La terza fase consiste nell'aggregare elementi di servizio identificati, in base a una tassonomia predefinita dei tipi di servizio (ad esempio, servizi CRUD, servizi di infrastruttura, servizi di utilità e servizi aziendali). Durante la seconda e la terza fase, gli analisti software sono assistiti tramite tecniche di clustering, che raggruppano automaticamente operazioni e servizi simili dello stesso tipo.

Questo lavoro presenta un confronto tra l'applicazione di diversi approcci di migrazione. Due di loro insieme ai loro prosand sono noti con la community, mentre l'altro è un nuovo approccio che mira a ottenere i pro della migrazione precedente senza i loro contro. La seguente sezione illustra il caso di studio utilizzato per questa analisi.

Case Study

Il caso in esame in questo lavoro è costituito da un sistema incentrato sui dati composto da diversi sottosistemi per il mantenimento di record di dati relativi a individui tra cui informazioni personali complete, relazioni, background lavorativo, benefici ricevuti e così via.

Il sistema è scritto in COBOL, esegue così nan mainframe IBM e accede a un DB2database con circa 0,8 PetaByte. D'altra parte, ci sono alcuni programmi COBOL che accedono ai dati storici attraverso VSAM (Virtual Storage Access Method), un metodo di archiviazione e accesso ai dati caratterizzato da numerosi sistemi operativi mainframe IBM. Inoltre, alcuni dei programmi COBOL sono accessibili solo attraverso una rete intra-via tramite applicazioni di terminale 3270, mentre altri programmi sono raggruppati nelle transazioni CICS (Customer Information Control System) e consumati dalle applicazioni Web. CICS è un gestore transazioni progettato per l'elaborazione rapida e ad alto volume, che consente di organizzare una serie di programmi come attività atomica.

In questo caso, questi programmi consistono in business logic e accessi al database, principalmente convalide e interrogazioni di input, rispettivamente.
Tabella 1: caratteristiche delle transazioni di sistema più importanti in base al carico del mainframe in termini di chiamate eseguite nel mese di gennaio 2010.

tablesrt2MM

A scopo illustrativo, una breve panoramica delle sole 6 transazioni è mostrata nella Tabella 1, che indica il numero di righe di codice sorgente non commentate2, il numero di query SQL eseguite e il numero di righe e file associati a una transazione. Quando un programma P1 chiama un programma P2, o importa una definizione di area di comunicazione (COMMAREA) C, o include una definizione S di SQL, si dice che P1 è associato a P2, o C o S, rispettivamente. In media, ogni transazione aveva 18 file, comprendeva 1803 righe di codice, ed eseguiva 6 istruzioni SQL SELECT.