1 / 33

Midrange Modernization Conference modernizzare le applicazioni sviluppate per AS/400: la proposta Microsoft per i Partne

Midrange Modernization Conference modernizzare le applicazioni sviluppate per AS/400: la proposta Microsoft per i Partner. la migrazione di codice COBOL AS/400 verso il mondo .NET. agenda. introduzione la migrazione delle applicazioni le applicazioni COBOL la “roadmap”

ariane
Download Presentation

Midrange Modernization Conference modernizzare le applicazioni sviluppate per AS/400: la proposta Microsoft per i Partne

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Midrange Modernization Conferencemodernizzare le applicazioni sviluppate per AS/400:la proposta Microsoft per i Partner la migrazione di codice COBOL AS/400 verso il mondo .NET

  2. agenda • introduzione • la migrazione delle applicazioni • le applicazioni COBOL • la “roadmap” • le principali tecnologie a supporto del processo di migrazione • conclusioni

  3. chi è bizlogica • un’azienda focalizzata su processi e tecnologie attinenti il software lifecycle • partner italiano di aziende come Relativity Technologies, Fujitsu Computer Systems (ex Fujitsu Software), Borland (Segue Software: soluzioni di test) • esperienze in progetti di trasformazione di applicazioni legacy

  4. la migrazione delle applicazioni • a chi si rivolge:  tutte quelle situazioni in cui sono presenti piattaforme applicative e/o architetturali in produzione da tempo, e per le quali esista una esigenza (generica) di miglioramento di risultati, performance, funzioni, utilizzo da parte dell’utente, meccanismi e cicli di manutenzione, fino a ipotesi di ammodernamento di basi dati, interfacce, environment o ambienti applicativi

  5. legacy migration • la soluzione si basa sul recupero della conoscenza dell’applicazione, e la conseguente creazione di componenti • tali componenti, una volta creati, possono avere diverse destinazioni, secondo le diverse scelte architetturali, adeguandosi di fatto alle piattaforme tecnologiche target • la soluzione può avere diverse articolazioni con vantaggi che, secondo le scelte effettuate, sono di tipo economico, di efficace impiego delle risorse, e di minor rischio

  6. rifare, emulare, o migrare? • nella necessità di sviluppare da zero una nuova applicazione, oggi quasi nessuno orienta la propria scelta su COBOL o RPG • anche se esistono da tempo versioni object oriented dei compilatori, tutti gli environment più evoluti e attuali contemplano l’utilizzo di linguaggi diversi • nel caso della piattaforma .NET di Microsoft, è possibile la convivenza tra linguaggi diversi, come C#, J# e VB, e, soprattutto, COBOL e RPG, rendendo possibile e vantaggioso il recupero del codice

  7. le scelte possibili rischio: medio/alto costo: alto tempo: lungo valore: elevato  sostituzione delle applicazioni e dei sistemi esistenti con soluzioni di mercato (es. sistemi ERP) sostituzione rischio: basso  costo: contenuto  tempo: breve  valore: basso modernizzazione di tipo “tattico”, con il supporto di layer software di emulazione emulazione rischio: alto costo: alto tempo: lungo valore: elevato  conversione e/o riscrittura delle applicazioni in linguaggi/ambienti moderni (J2EE, .NET) rifacimento rischio: basso  costo: medio  tempo: medio  valore: elevato  migrazione delle applicazioni (o di parti di esse) verso un ambiente moderno (.NET) mantenendo i linguaggi esistenti (COBOL e RPG) migrazione

  8. la migrazione • l’esperienza dimostra che l’obiettivo è raggiungibile, senza necessariamente rischiare una rivoluzione • il percorso è configurabile con obiettivi intermedi • l’investimento è configurabile secondo le capacità • l’impatto sull’utente è modulabile • l’acculturamento delle risorse di sviluppo e manutenzione è graduale • è possibile far convivere le nuove applicazioni con le vecchie • la configurazione target la decide il Cliente

  9. la migrazione: vantaggi e benefici • se sono validi i presupposti, i vantaggi sono: • minor tempo • migliore razionalizzazione • migliore qualità • migliore corrispondenza ai requisiti utente • minori rischi • riutilizzo degli skill

  10. a quali piattaforme e linguaggi legacy è applicabile? • sistemi mainframe (IBM, Unisys, Bull, …) • sistemi centrali (AS/400–iSeries, Unix) • applicazioni CICS, IMS, AS/400, Adabas, ADW, APS, ADS-Online, … • organizzazioni dati VSAM, DL/I, DB2, DB2/400, files AS/400, Adabas, IDMS, … • linguaggi COBOL, RPG, PL/I, Natural, … • JCL, ECL, CL/400 • …

  11. sistema applicativo legacy modello funzionale intervista utente prototipo decisione presentation knowledge mining 1° classificazione logica decisione modello dati analisi dati dati re-learning analisi risultati progetto individuazione e separazione logica dei layer livello tipo di documentazione sistema mappa generale, elenco dei sottosistemi sottosistema mappa, elenco dei moduli, job batch, database, schermate, ... batch job programmi lanciati, database acceduti, frequenza, ... programma scopo, programmi chiamati, database letti o scritti, chiamato da, parametri, ... section funzionalità, chiamate esterne, section performed, condizioni verificate, variabili utilizzate... modalità di migrazione documentazione fattibilità

  12. la migrazione delle DDS Descrizione: La soluzione proposta prevede l'adozione del tool Fujitsu NetCOBOL for .NET unito alle suite Monarch e Visual RPG.NET di ASNA I Wizard forniti da Monarch consentono di importare le DDS (Display file, Printer file) e di convertirle automaticamente in form ASP.NET o in classi AVR per la gestione delle stampe, nonché di generare, partendo da file Template RPG, il codebehind associato alla Form DDS (Print File ) DDS (Display File ) RPG Template File ASNA Monarch VS.NET Project .NET Framework AVR class AVR class IIS Web Server COBOL component

  13. slicing logica COBOL COBOL programs Descrizione: La logica business in COBOL, sottoposta ad un processo di slicing può essere estrapolata in componenti (Object Oriented) COBOL.NET, e richiamata dai programmi RPG (codebehind) generati Business Rules Extraction .NET Framework VS.NET Project NetCOBOL .NET COBOL component COBOL component COBOL component

  14. migrazione struttura dati e Data layer Descrizione: Il tool DataGate di ASNA consente la migrazione automatica della struttura dati da AS/400 a MS SQL Server, mentre l'isolamento degli accessi alla base dati in un unico componente di data layer consente l'integrazione con le classi COBOL I-O DB statements DB AS/400 ASNA Monarch ASNA DataGate Data Layer NetCOBOL .NET AVR class COBOL component COBOL component COBOL component AVR class MS SQL Server AVR class

  15. .NET Framework Web Services DDS File (display file, Print file ecc..) VS.NET Project Built application ASNA Monarch ASNA Visual RPG.NET RPG template AVR Class AVR Class Fujitsu NetCOBOL.NET COBOL File Business Rules Extraction Cobol component Cobol component Data Layer DB AS/400 ASNA DataGate MS SQL Server una visione d’insieme

  16. Data Layer Presentation Layer Communication Layer Business Layer il processo che interviene sul codice COBOL • esame del codice sorgente per l’individuazione dei diversi layer: • Files READ & WRITE • Printer READ & WRITE • Video READ & WRITE • CALL • Using (Linkage Section) • COMPUTE FIELD-A = …

  17. aree di attenzione BR 1 BR 2 Separazione logica (fisica?) User Interface Code analisi degli impatti Presentation Layer User Interface Code BR 1 BR 2 Data Access Code BR 3 BR 4 razionalizzazione / refactoring Data Business Layer BR 5 BR 6 BR 5 BR 6 eliminazione di codice morto/decaduto Data Access Code User Interface Code Data Layer documentazione BR 3 BR 4 Data Data Access Code Data Programma COBOL destrutturato partizionamento applicazioni Programma COBOL monolitico rinnovo (refactoring) - COBOL

  18. .NET Framework SQL Server Web Services .NET Components Business Components Service Data Application Data Host Integration Layer Messages SQL Native Mid. Data Transformation & Replication Environment (HIS) DRDA AS400 iSeries File Transfer AS400 Procedures (i.e. COBOL/400) DB2/400 AS/400 Files gli ambienti target di riferimento: esempi di configurazione per l’integrazione con servizi centrali OLEDB/ODBC MOM Adapter ADO.NET MQSeries

  19. le tecnologie

  20. le principali tecnologie a supporto dei processi di migrazione • Relativity Technologies: Modernization Workbench • Fujitsu Software Corp.: Dialect Converters • Fujitsu Software Corp.: NetCOBOL for .NET • ASNA: Monarch • ASNA: Visual RPG .NET • ASNA: Datagate

  21. physical files CL source Source RPG/400 RPG ILE Printer file DDS Display file DDS Piano di lavoro Source COBOL/400 ILE COBOL logical files data area RMW parsing CL transformation RPG generation printer file migration dispaly file migration data & schema migration COBOL Dialect Converters physical files VRPG .NET VRPG .NET text print file ASPx pages inventory analysis assessment re-learning NetCOBOL for .NET logical files la migrazione delle applicazioni AS/400 – per componenti

  22. Relativity Technologies: Modernization Workbench

  23. Modernization Workbench: le caratteristiche principali • esecuzione di analisi d’impatto tramite viste a diagramma di data flow, call map, e screen flow per ridurre il tempo di analisi • al cambiamento del codice sorgente corrisponde un aggiornamento della documentazione, che così è sempre aggiornata • inventario degli asset disponibili • slicing delle business rules • componentizzazione del codice COBOL

  24. Fujitsu: Dialect Converters • i Dialect Converters sono strumenti che aiutano nei processi di conversione dei programmi sorgente sviluppati in altri dialetti COBOL: • IBM®, Micro Focus®, Microsoft®, e altri • i Dialect Converters caricano il sorgente scritto in un altro dialetto per costruire una mappa del programma, trasformare questa mappa e generare un sorgente in output che risulti logicamente equivalente all'originale ma che sia compatibile con il compilatore NetCOBOL

  25. Fujitsu: NetCOBOL for .NET • Fujitsu NetCOBOL for .NET è un compilatore COBOL appositamente progettato per il Framework Microsoft .NET • è in grado di generare moduli in Microsoft Intermediate Language (MSIL), che possono essere eseguiti sotto il controllo del Common Language Runtime (CLR) • tale environment permette di “mescolare” il codice COBOL con qualsiasi altro linguaggio supportato in .NET (C#.NET, VB.NET, VRPG.NET, ecc.) • l’adozione della sintassi OO COBOL, così come il supporto delle estensioni specifiche di .NET, consente di sviluppare programmi in grado di sfruttare al meglio le classi del framework • il COBOL è definibile come script language per ASP.NET • è “runtimefree”

  26. COBOL for .NET VRPG.NET C#.NET Common Language Runtime (CLR) il CLR (Common Language Runtime) in .NET Framework Ambiente di Sviluppo: MS Visual Studio Just-inTime Compiler .NET Framework Win32 OS (Windows)

  27. ASNA Monarch • Monarch • trasforma le applicazioni iSeries ILE RPG ed RPG/400 in applicazioni native Microsoft .NET • facilita l’utilizzo di programmi RPG per Web Services • aiuta ad identificare gli elementi per generare applicazioni complesse • genera oggetti MSIL per altri linguaggi .NET

  28. iSeries to .NET ASNA Monarch • il risultato è un’applicazione .NET-hosted scritta in AVRpg per .NET • RPG source • Display files • CL • Menus • Printer files • l’unica soluzione che converte da RPG ad……..RPG! • produce applicazioni .NET che possono dialogare con i processi batch OS/400 con interscambio parametri. • genera un’applicazione browser-based, pronta all’utilizzo • si collega a iSeries • oppure a SQL Server • oppure..ad entrambi in un’unica sessione!

  29. conclusioni

  30. conclusioni • deve esistere una forte motivazione • le applicazioni legacy devono essere soddisfacenti • occorre avere deciso la configurazione target • esiste la necessità di salvaguardare gli skill interni • l’obiettivo è una nuova applicazione con le regole e i pregi di quella esistente e con l’opportunità di una reale modernizzazione • totale integrazione nel Framework .NET

  31. La “roadmap” • verifica • analisi di un campione ridotto ma qualitativamente significativo di codice • intervista sui requisiti di base • verifica di applicabilità di tools e metodologie • produzione di una “pre-fattibilità” che consenta al cliente di decidere se proseguire o meno con una stima: • ordine di grandezza dell’impegno (tempi/costi) • valutazione dei rischi principali • Proof of Concept (progetto pilota) • definizione di limiti e obiettivi • pianificazione dei tempi • verifica dei requisiti • Il PoC produce: • un test “reale” di intervento, in grado di consentire un esame tecnicamente accurato dei risultati ottenibili • una documentazione che riporta le esperienze fatte, le decisioni prese, i problemi incontrati • gli elementi utili alla redazione di una offerta finale per l’intero progetto • la pianificazione del progetto complessivo • una offerta economica per il progetto • progetto

  32. documentazione • presentazioni • white paper • processi • metodologia • esempi di codice • Web Services • prove su campioni di codice • referenze • storie di successo • www.bizlogica.it e info@bizlogica.it

  33. Midrange Modernization Conferencemodernizzare le applicazioni sviluppate per AS/400:la proposta Microsoft per i Partner la migrazione di codice COBOL AS/400 verso il mondo .NET

More Related