RGI

Introduzione

L'idea su cui si basa il prodotto è quella di svincolare la progettazione del layout grafico di un'applicazione dal progetto della parte algoritmica vera e propria.

Attualmente, le applicazioni su sistemi dipartimentali tradizionali prevedono l'output su terminali dotati di interfaccia a carattere. Con l'avvento delle tecnologie multimediali, però, si avverte la necessità di sfruttare le potenzialità messe a disposizione dei nuovi prodotti quali browser e linguaggi di nuova generazione atti a maneggiare queste nuove famiglie di dati.

In parallelo al sorgere di queste nuove tendenze, non si può ignorare, però, la presenza di grandi quantità di applicativi già sviluppati su macchine server e il know-how maturato da coloro che li hanno sviluppati nel corso degli anni.

L'RGI si pone come scopo quello di mediare queste due esigenze per permettere un passaggio graduale dallo sviluppo tradizionale ad un più avanzato modo di rappresentazione dati.

Ciò che While1 propone, infatti, è una serie di soluzioni che possono essere realizzate passo passo o singolarmente e che permettono ampia scelta da parte del cliente.

Tutte queste soluzioni nascono da una stessa architettura di base e partono dal mettere a disposizione del cliente un mezzo di sviluppo totalmente nuovo sul quale creare nuovi applicativi, fino a fornire strumenti atti ad interfacciare in modo indolore le vecchie applicazioni dipartimentali (es: AS/400) ai client dedicati alla rappresentazione grafica dei dati.

Descrizione generale dell'architettura

L'architettura di base proposta per la realizzazione di quanto sopra descritto prevede tre ambienti logici principali. Il primo, quello di basso livello, è l'ambiente cosiddetto client sul quale funzionerà l'interfaccia grafica. Il secondo ambiente permetterà di sviluppare nuove applicazioni che comunicheranno con il livello client. Il terzo, opzionale, è l'insieme delle librerie e dei tool (con eventuali modifiche necessarie) atti a porre in grado gli attuali applicativi del cliente di comunicare con i nuovi programmi grafici.

Si distinguono nello schema i tre ambienti sopra citati. Nel primo ambiente compaiono gli applet Java che saranno le interfacce grafiche dell'applicativo. È ipotizzabile lo sviluppo degli stessi tramite tool atti ad agevolare il progetto del layout della maschera.

Nella parte centrale dello schema si trova il vero e proprio motore dell'architettura. È composto da alcuni elementi tra cui uno sempre presente (Interfaccia Client) e due opzionali (Libreria per interfaccia con il sistema dipartimentale e TSMART).

Nella parte più a sinistra si nota il mondo DIPARTIMENTALE (es: AS/400) comprensivo di tutti gli applicativi attualmente in uso. Nel caso di esclusivo sviluppo di parti nuove, la suddetta parte non entrerà in gioco.

Passiamo ora a descrivere in dettaglio le singole componenti.

Client

Il livello client vede al suo centro le applicazioni Java. Questi programmi operano facendo riferimento a tabelle di descrizione dati da rappresentare e comunicano con la parte server dell'applicazione tramite apposite API. Una volta lanciate, aprono una connessione tramite le API verso il livello server.

Non agiranno sino all'arrivo del primo output dell'applicazione server (o dal sistema DIPARTIMENTALE). In quel momento provvederanno a interpretare i dati che sono giunti e a rappresentarli secondo i dettami sanciti nelle tabelle descrizione dati. Effettuata la rappresentazione su video (o su altri eventuali strumenti multimediali), rimarranno in attesa sia di comandi utente (clic del mouse, tastiera), sia di eventuali aggiornamenti da parte dell'applicazione server.

Di per sé, gli applet non prenderanno alcuna iniziativa algoritmica in quanto fungeranno da meri esecutori delle applicazioni che funzionano sul server (o sul sistema DIPARTIMENTALE).

Ad ogni cambiamento di stato di un elemento rappresentato sulla macchina client, corrisponderà un invio di un messaggio verso la macchina server.

Server

Si tratta del vero cuore dell'architettura. Si distinguono tre elementi principali:

• Interfaccia client
• Libreria di interfaccia verso il sistema DIPARTIMENTALE (opzionale)
• TSMART (opzionale)

Solo il primo elemento è parte indispensabile dell'architettura proposta.

Interfaccia client

Questo elemento si occupa di comunicare con gli applet Java mediante un protocollo applicativo in grado di definire i campi che debbono essere rappresentati, nel caso di trasmissione verso il client, e quelli che hanno subito variazioni, nel caso opposto.

Nel caso di trasmissione verso il client, non verranno solo trasmessi i dati, ma anche gli attributi comportamentali ad essi attribuiti (ad esempio: solo visibili, modificabili ecc.).

Per ciò che concerne i campi modificati sulla macchina client, questo modulo verificherà la loro correttezza sintattica. In altre parole, ad ogni modifica della videata presente sulla macchina client, corrisponde l'arrivo dell'informazione che viene controllata e, qualora necessario, un invio di messaggio di errore o di validazione verso il client.

Sostanzialmente, possiamo discernere tre tipi di eventi che possono giungere dal client:

• inquiry
• choose
• validate

Il primo evento (inquiry) è scatenato dalla richiesta di un dato, da parte di un applet Java. L'interfaccia client, che, ripetiamo, potrà coincidere con l'applicativo stesso, provvederà all'invio del valore del dato richiesto.

L'evento choose giunge nel momento in cui l'utente seleziona uno degli elementi rappresentati a video dall'applet Java. L'applicazione potrà in questo momento fornire tutte le variazioni del campo in questione oppure di altri presenti nella videata.

L'evento validate provoca l'invio di uno o più dati. L'interfaccia riceverà i dati in questione e procederà alla loro elaborazione e al proseguimento dell'algoritmo di gestione.

Libreria interfaccia RGI

Questo elemento verrà sviluppato qualora il cliente intenda utilizzare le attuali applicazioni, disponibili sul sistema DIPARTIMENTALE, apportando ad esse un minimo di variazioni. Sostanzialmente, si tratterà di sostituire le operazioni di read e write verso i terminali con chiamate RGI. Questo per permettere una rapida interfaccia con il mondo RGI e mantenere l'attuale logica applicativa. La libreria presente sul lato server, dovrà necessariamente avere un corrispondente strato di software sul sistema DIPARTIMENTALE atto a comunicare con essa.

A sua volta, la libreria comunicherà con l'interfaccia client inserendosi nel contesto sopra descritto.

TSMART

Questo elemento, l'ultimo presente nel server, è quello che offre al cliente la possibilità di lasciare assolutamente intatte le applicazioni sul sistema DIPARTIMENTALE. Per fare ciò, si pone come output delle stesse, interpretando, secondo un metalinguaggio predefinito, dei file di descrizione delle videate stesse.

In pratica, si tratta di un vero e proprio interprete video che riceve le videate degli applicativi (tramite interfaccia HLLAPI), ne isola i campi significativi ed è in grado di spedire all'applicativo ciò che l'utente ha modificato nei campi della maschera stessa.

Si tratta della scelta meno dispendiosa dal punto di vista dello sviluppo, ma indubbiamente aumenta un poco il carico di lavoro in fase di esecuzione.

Conclusioni

Di seguito sono riportate le soluzioni possibili:

• sviluppo dei nuovi applicativi secondo la modalità cosiddetta ad eventi con gli algoritmi "affogati" dentro l'interfaccia verso client. Questo consente di sfruttare appieno la nuova architettura costringendo, però ad un cambio di "abitudine" di programmazione per coloro che erano usi ad una programmazione sequenziale

• sviluppo di nuovi applicativi in ambiente server in modalità transazionale. Non si sfruttano totalmente le potenzialità offerte dalla programmazione ad eventi, ma si mantiene una logica di programmazione più tradizionale offrendo, nel contempo, la possibilità di lavorare su un nuovo sistema operativo e di sganciarsi, in futuro, dal mondo classico del sistema DIPARTIMENTALE utilizzato (es: AS/400)

• interfaccia degli applicativi attuali sul sistema DIPARTIMENTALE con l'utilizzo di librerie e interfacce sullo stesso; permette il mantenimento degli attuali programmi e del know-how dei programmatori con un piccolo sforzo di adattamento

• utilizzo di TSMART; permette di continuare lo sviluppo degli applicativi secondo la corrente modalità e il mantenimento di quelli sviluppati senza modifiche nel mondo DIPARTIMENTALE a prezzo, forse, di un leggero calo prestazionale.

Up to LAN * TSI  *   HSI  *  HOME