Il sistema Wrapper (livello software)

Il sistema Wrapper (livello software)

Il concetto di wrapper è abbastanza semplice: si tratta di un livello software  che nasconde l’implementazione effettiva delle funzionalità (che sono realizzate da uno o più moduli di un’applicazione legacy in ambiente mainframe o server) e le presenta attraverso un’interfaccia ben definita; quest’ultima è tipicamente ad oggetti, in modo che all’esterno, cioè verso il nuovo mondo ad oggetti distribuiti, la vecchia applicazione appaia sotto forma di uno o più oggetti, del tutto simili a tutti gli altri ed in grado, quindi, di operare nello stesso ambiente, accettare messaggi dagli altri componenti e rispondere in modo chiaramente definito.

In questo modo, poiché le applicazioni legacy implementano i processi fondamentali di business, il wrapper ad oggetti alza il livello di astrazione al livello di oggetti  di business, permettendo una facile integrazione con il resto del nuovo sistema.

Requisiti necessari per un Wrapper

I requisiti di un buon wrapper sono:

  • Fornire la gestione del protocollo di connessione a differenti livelli. Il wrapper deve connettersi al sistema legacy: questo significa aprire e  gestire differenti connessioni (che normalmente sono risorse platform – specific gestite dal sistema operativo, come pipe, socket, file I/O stream) se il sistema comunica su differenti interfacce. Inoltre il wrapper deve implementare un qualche protocollo a livello applicativo (per esempio un login od un dialog): questo può essere complesso se il sistema mantiene lo stato.
  • Ottenere la traduzione dei dati ed il processamento dell’informazione a differenti livelli.
  • implementare una qualche sorta di meccanismo di error detection/recovery. È inoltre fondamentale che se il sistema legacy non ha una gestione delle eccezioni esternamente definita o manca di robustezza; le eccezioni viceversa sono fondamentali per un sistema ad oggetti distribuiti.
  • Gestire l’ambiente nativo del sistema legacy. Se il sistema legacy si aspetta file d’inizializzazione con un certo nome e localizzazione, il wrapper deve prepararli; se usa file temporanei il wrapper deve controllare che non ci siano conflitti; se applicazioni collaterali sono necessarie al sistema legacy, il wrapper deve avviarle e gestirle; ecc.
  • Implementare nuove interfacce che rientrino in una specifica molto più generale.

Nello sviluppare un wrapper si possono dunque assumere approcci differenti, che chiaramente conducono a soluzioni e risultati piuttosto diversi (soprattutto per quel che riguarda il livello di astrazione ottenuto e l’efficacia dell’integrazione).

Un primo atteggiamento è quello opportunistico di cercare di riusare il vecchio sistema il più possibile ed in modo facile: è l’uso dell’applicazione che guida il  disegno  del wrapper e l’obiettivo del wrapping è solamente quello di esportare l’interfaccia dell’applicazione nel nuovo ambiente (tipicamente il Web).

Esempio pratico di Wrapper

Esempi sono dati dalle prime sperimentazioni che alcune Amministrazioni della PA hanno condotto relativamente alla DOC. In esse è stata identificata una transazione legacy particolarmente significativa anche dal punto di vista dell’utente finale e la si è offerta sul Web attraverso un semplice wrapper: un componente server con un unico metodo che accetta in input una stringa formattata secondo il tracciato record della transazione e riporta l’output sempre come stringa. In pratica il componente non fa altro che rendere accessibile il tracciato record della transazione (che quindi si mappa 1:1 su di esso) nel nuovo ambiente, ed il client deve occuparsi dello spacchettamento, non essendoci trasparenza rispetto alla logica legacy. Quello che si espone non è Object Oriented, bensì Object Based (nel senso che usa le nuove tecnologie ma non si avvale delle loro intrinseche potenzialità d’astrazione).

Non si vogliono cioè aggiungere nuove funzionalità, solamente rendere disponibile la vecchia applicazione nel nuovo ambiente; il punto di partenza quindi rimane la specifica del vecchio sistema: si risponde alla domanda di come riuscire ad esportare il sistema nel nuovo ambiente e non alla differente di come riuscire ad integrarlo, che porta a vedere l’incapsulamento in un’ottica molto differente.

Principali difetti dei Wrapper

Il principale difetto di questa strategia, che si potrebbe definire basata sul legacy (ovvero di semplice accesso), è l’esposizione dei vincoli della vecchia infrastruttura nel nuovo sistema, che è particolarmente dannosa nel caso di componenti distribuiti: si desidera che i componenti interagiscano per costruire nuove applicazioni, ma le applicazioni legacy non furono disegnate per essere blocchi componenti o per funzionare in concerto con altre, per cui le interfacce che esportano non rientrano in un framework omogeneo e non aderiscono ad una strategia.

Precedente Integrazione completa di un sistema informatico Successivo Panoramica sui sistemi legacy

Lascia un commento

*