Un progetto universitario, un database meteorologico e la scoperta della programmazione distribuita con Java RMI e i thread.
Un progetto universitario, una nuova sfida
Era il 2001 e da qualche anno avevo iniziato ad approfondire Java, un linguaggio che mi stava facendo scoprire un modo diverso di programmare rispetto al BASIC con cui avevo mosso i primi passi.
Per l’esame universitario di Sistemi di Elaborazione dell’Informazione B, il professore aveva assegnato una traccia che prevedeva l’utilizzo di Java RMI e dei thread.
L’obiettivo formativo era confrontarsi con alcuni concetti fondamentali dell’informatica: la comunicazione tra applicazioni, la programmazione distribuita e la gestione di più operazioni concorrenti.
Da quella traccia nacque JavaMeteo, un sistema per raccogliere, archiviare, consultare ed elaborare dati meteorologici.
A distanza di venticinque anni, rileggere quei sorgenti mi ha fatto ritrovare non soltanto un vecchio esercizio universitario, ma anche un passaggio importante del mio percorso nella programmazione.
Non una semplice applicazione meteo
L’idea alla base del progetto era costruire un sistema nel quale diversi programmi potessero collaborare.
Da una parte c’era un database con le rilevazioni delle stazioni meteorologiche. Dall’altra, applicazioni che dovevano inserire i dati o richiederli per effettuare delle elaborazioni.
Le informazioni comprendevano temperatura, umidità, pressione atmosferica e precipitazioni.
L’utente poteva selezionare una stazione, impostare un intervallo temporale e richiedere i dati relativi a un determinato fenomeno meteorologico.
Il programma poteva poi calcolare valori medi, massimi e minimi e presentare i risultati in una pagina Web.
Fin qui nulla di particolarmente sorprendente, almeno visto con gli occhi di oggi. La vera particolarità stava nel modo in cui avevo organizzato il sistema.
Quando i programmi cominciano a parlarsi
Uno degli elementi obbligatori della traccia era Java RMI, acronimo di Remote Method Invocation.
Il concetto è piuttosto semplice da spiegare: un programma può richiamare un metodo appartenente a un oggetto che si trova su un’altra macchina, attraverso la rete.
Per il programmatore, questo significa poter far collaborare applicazioni separate senza dover concentrare tutte le operazioni nello stesso processo.
In JavaMeteo realizzai un server che creava e registrava gli oggetti remoti responsabili della consultazione dei dati.
Il client poteva individuare l’oggetto corrispondente a una determinata stazione meteorologica e richiedere le informazioni desiderate.
Nel codice, questa operazione compare attraverso un’istruzione caratteristica di Java RMI:
MeteoDati meteodatiRem =
(MeteoDati) Naming.lookup(url + stazione);Il programma otteneva così il riferimento a un oggetto remoto, sul quale poteva invocare il metodo necessario per recuperare le rilevazioni.
Per me era un salto concettuale importante. Non stavo più scrivendo soltanto un programma che eseguiva istruzioni e visualizzava un risultato. Stavo costruendo diversi componenti che dovevano comunicare e funzionare insieme.
Il problema delle richieste contemporanee
L’altro requisito della traccia era l’utilizzo dei thread.
Un thread permette a un programma di gestire più attività all’interno della stessa applicazione, rendendo possibile l’esecuzione concorrente di operazioni differenti.
Nel mio progetto le richieste provenienti dagli utenti dovevano essere elaborate senza che l’intero sistema rimanesse impegnato con un’unica operazione.
Per questo avevo realizzato una classe chiamata ElaborazioneThread, incaricata di richiedere i dati, elaborarli e preparare la risposta HTML.
Accanto ai thread compariva anche il concetto di sincronizzazione, necessario per coordinare gli accessi a una parte condivisa del programma.
Rivedendo oggi il codice, mi colpisce proprio questo aspetto: dietro una semplice richiesta di dati meteorologici c’erano problemi di coordinamento, comunicazione e gestione delle risorse. Questioni che vanno ben oltre la scelta di un linguaggio di programmazione.
Un database, un’interfaccia grafica e dati simulati
JavaMeteo non si limitava al server e alle richieste remote.
Avevo sviluppato anche un’applicazione con interfaccia grafica Swing per gestire le stazioni e inserire le rilevazioni nel database.
La connessione ai dati utilizzava JDBC attraverso il bridge ODBC, una soluzione caratteristica di quel periodo.
Ma uno degli elementi che oggi trovo più curiosi era un’altra applicazione, chiamata Casuale.
Il suo compito era generare rilevazioni meteorologiche simulate, permettendo di popolare il database anche senza disporre di dati provenienti da vere stazioni.
La simulazione prevedeva una rilevazione ogni quindici minuti: 96 valori al giorno per ciascuna stazione.
In questo modo il sistema poteva essere utilizzato per sperimentare interrogazioni, elaborazioni e funzionamento complessivo dell’architettura.
Era una soluzione pratica a un problema altrettanto concreto: come verificare il comportamento di un’applicazione che necessita di una grande quantità di dati? Creando i dati necessari per provarla.
Cosa mi ha lasciato JavaMeteo
Oggi JavaMeteo è un piccolo pezzo di storia personale, conservato nel mio repository GitHub.
Alcune tecnologie utilizzate sono ormai superate. Il bridge JDBC-ODBC, per esempio, appartiene a un’epoca molto diversa dall’attuale ecosistema Java.
Eppure molti dei problemi affrontati allora sono ancora attuali.
Separare le responsabilità tra componenti, consentire a programmi differenti di comunicare, coordinare operazioni concorrenti ed elaborare dati sono esigenze presenti anche nei sistemi moderni.
La cosa che mi piace di più, rileggendo il progetto, è ritrovare il metodo con cui affrontavo le difficoltà.
Prima cercavo di capire il problema. Poi individuavo le componenti necessarie e provavo a farle funzionare insieme.
Non era sempre semplice e certamente non esistevano gli strumenti di assistenza alla programmazione di cui disponiamo oggi. Ma proprio per questo ogni risultato richiedeva studio, tentativi e una buona dose di pazienza.
Un altro passo nel mio percorso
JavaMeteo arrivò dopo i primi programmi in BASIC e dopo l’esperienza di Invoice Printer 98.
Rappresentò un passaggio verso un modo più articolato di progettare il software: non più soltanto singole applicazioni, ma sistemi composti da parti distinte e comunicanti.
Successivamente avrei approfondito un’altra idea che mi interessava particolarmente: scrivere componenti riutilizzabili e metterli a disposizione anche di altri programmatori.
Da quell’interesse sarebbe nato Java Island. Ma questa è un’altra storia.
Il codice cambia, le tecnologie invecchiano, ma il piacere di comprendere un problema e trovare il modo di risolverlo rimane.
Il codice sorgente originale è disponibile su GitHub – JavaMeteo.
Lascia un commento