4.1 Definizioni dell’obiettivo del caso di studio

L’oggetto ed obiettivo principale di questa tesi consiste nel progetto e nella realizzazione di una architettura client-server, sviluppata in modo da risultare il più possibile d’uso generale, che possa essere usata come piattaforma per sviluppare applicazioni di tipo distribuito per la didattica.

L’uso del linguaggio Java, le cui caratteristiche sono state oramai ampiamente discusse, consente di immaginare, la realizzazione di applicazioni immerse nel contesto delle tecnologie WWW, con tutti i vantaggi in termini di ampiezze e diffusione del mercato potenziale e dell’ottimo rapporto costo/prestazione.

In particolare, nell’ambito di questa tesi si è individuata una vasta classe di applicazioni dedicate alla didattica nelle quali è necessario disporre di un generico "controllore di oggetti" (il server) che dialoga con una interfaccia utente localizzata in maniera imprecisata sulla rete e che richiede servizi per guidare gli studenti/utilizzatori in un opportuno percorso lavorativo.

In pratica, l’idea è quella di progettare e poi implementare in linguaggio Java una applicazione client-server per il controllo remoto di dispositivi elettronici e rendere operativa questa architettura attraverso il World Wide Web. Nel nostro caso di studio, per esempio, il dispositivo elettronico da controllare è una classe di strumenti di misura con la quale un generico utente interagisce per effettuare delle esperienze di laboratorio. Altre astrazioni di ampia utilità potrebbero comprendere il caso in cui elettronico è una qualche forma di digital library con lezioni in aula preregistrate: lo studente attraverso il Web può ottenere il controllo della digital library per richiedere la lezione di suo interesse. Ancora meglio si può immaginare direttamente una video camera situata in un’aula e connessa ad una dispositivo di acquisizione dati a sua volta connesso a un personal computer in rete con Internet.

Lo studente può allora ottenere, attraverso il Web, il controllo della scheda di acquisizione dati per ricevere il segnale video a casa propria, anche se attualmente la banda passante e i protocolli di Internet non garantiscono una corretta fruibilità di questo tipo di applicazioni.

Attraverso una rappresentazione grafica si chiarisce ciò che si vuole fare:

Si consideri Internet ed in particolare ciò che in Internet e il World Wide Web (Figura 4.1):

Figura 4.1 Il client-server nel contesto World Wide Web

In figura si ha un client Web connesso ad un server Web mediante Internet e, un altro oggetto chiamato Dispositivo Controllabile. Quest’ultimo rappresenta un qualunque dispositivo, apparecchiatura o generico oggetto che possiamo controllare mediante interfacciamento con un computer.

Naturalmente, l’opportunità di utilizzare le tecnologie WWW sta nel fatto che oggigiorno il Web è in continua crescita e i client Web (o browser) sono sempre più diffusi. Quindi costruire qualcosa basandosi sul World Wide Web equivale a renderla immediatamente disponibile a migliaia di utenti che già usano il Web e i browser Web.

Dalla situazione illustrata in Figura 4.1 ci si porta in quella illustrata nella Figura 4.2.

Figura 4.2 Dispositivo Controllabile nel contesto World Wide Web.

Nella Figura 4.2 Dispositivo Controllabile è connesso al server Web e sul client Web vi è l’Interfaccia Utente Dispositivo: un applicativo con cui l’utente può interagire per inviare controlli al dispositivo. Non è importante che il dispositivo da controllare sia fisicamente connesso al server Web, il server Web funzionerà solo da "contenitore" per le applicazioni client-server che servono per il controllo del dispositivo. Il dispositivo deve essere semplicemente connesso a un computer, a sua volta connesso a Internet.

Si vuole che le applicazioni necessarie per il controllo del Dispositivo Controllabile siano alquanto generali, in particolare il più possibile indipendenti dalle caratteristiche del dispositivo fisico.

In generale, come in ogni problematica client-server si distinguono due categorie di applicazioni (Figura 4.3): una applicazione che funziona da client (di cui una piccola parte è rappresentata da Interfaccia Utente Dispositivo), il cui compito è che da una parte di accettare comandi dall’utente e dall’altra dialogare con il server, e una applicazione che funziona da server che da una parte dialoga con il client e dall’altra, in questo caso, con il dispositivo da controllare.

Figura 4.3 Architettura client-server per il controllo di Dispositivo Controllabile.

Nei paragrafi successivi viene effettuata una breve discussione delle problematiche che occorre affrontare nel contesto del progetto di una applicazione client-server.

Si passa poi all’applicazione di queste motodologie allo specifico caso di studio oggetto di questa tesi, utilizzando il linguaggio Java come linguaggio di codifica.

  4.2 Progettazione di applicazioni client-server

I sistemi client-server nascono come coordinamento di due sistemi logici (il client e il server) e dei componenti delle rispettive applicazioni.

La progettazione di applicazioni client-server richiede la scelta di architetture appropriate: poiché le diverse parti di un’applicazione vengono eseguite in più di un sistema, il software client-server deve essere modularizzato per consentire la distribuzione tra macchine client e macchine server. La separazione delle funzionalità delle applicazioni in vari componenti facilita l’elaborazione di applicazioni client-server, in quanto i componenti forniscono ubicazioni ben definite in cui le applicazioni possono essere distribuite.

La logica delle applicazioni deve essere separata in componenti indipendenti, dove un componente di richiesta (o client) effettua le richieste e si attende che un componente di risposta (o server) gli restituisca i risultati.

In generale nelle applicazioni client-server si può fare una suddivisione, a priori, dei componenti che vanno posizionati nel client e di quelli che vanno nel server:

 Compiti del client sono:

• Visualizzazione / Presentazione
• Interazione con l’utente
• Formulazione di richieste
• Logica dell’applicazione

• Query sulla risorsa (nel caso specifico sul dispositivo controllabile)
• Eventuali calcoli
• Gestione dei dati
• Comunicazioni
• Elaborazione di risposte

E’ importante notare che la capacità di elaborazione del server è fissa, la condivisione di questa capacità tra più client può degradare le prestazioni o addirittura saturare il server, una corretta distribuzione delle funzionalità diventa importante affinché il server conservi la capacità di elaborazione.

La programmazione client-server
Le applicazioni client-server devono essere progettate nell’ottica della modularità, in quanto parti del programma applicativo devono essere eseguite in più di una macchina. Questi componenti modulari, combinati in rete, aumentano sensibilmente le capacità e le prestazioni del software applicativo.

La codifica per le applicazioni client-server richiede l’attuazione di alcuni buoni principi di programmazione, inoltre sviluppare applicazioni client-server vuol dire rispondere ai seguenti requisiti:

• Utilizzo di una codifica non monolitica: le varie parti di una applicazione vanno strutturate in componenti modulari invece che in un unico blocco monolitico, ciò vuol dire dedicare molto più tempo all’architettura di un’applicazione prima che abbia inizio la codifica.
• Codifica in un’architettura di servizi indipendenti: ciascun componente dell’applicazione deve essere considerato come un servizio modulare, questi elementi di servizio modulare consentono di raggruppare logiche simili. La separazione dei vari componenti logici delle applicazioni delinea in modo quasi automatico il codice appartenente al componente server e quello appartenente al componente client. Possibilmente l’interfaccia tra i componenti deve rimanere inalterata anche se i componenti vengono situati su un’altra macchina o un’altra rete.
• Gestione dei dati specifica per ogni client: poiché i server ( i componenti server delle applicazioni) svolgono il lavoro per conto di molti client , i dati ai quali i componenti (logici) del server accedono devono essere unici per ciascun client. Spesso i dati sono trattati come globali: nel corso della manipolazione di essi per conto di molti client non è possibile garantire che i dati globali siano unici, pertanto occorre codificare le applicazioni per l’uso dei dati di ciascun client. Occorre raggruppare in una struttura tutti i dati attinenti a ciascun componente di richiesta di servizi (client); generalmente, per ciascun client richiedente viene creata un’istanza della struttura e le modifiche apportate ai dati dal componente server dell’applicazione si basano pertanto sulla struttura di dati dell’utente del client individuale. Il linguaggio Java accede ai dati modulari raggruppando tutti i dati e tutte le funzioni all’interno di una classe: questo incapsulamento fornisce un meccanismo naturale per l’accesso ai dati da parte dei singoli client.
• Integrazione di un meccanismo di Richiesta/Risposta: va sviluppato un meccanismo per la comunicazione tra i componenti di richiesta (client) e quelli di risposta (server), spesso questo lavoro richiede una quantità consistente di codifica.
• Eliminazione delle dipendenze sottostanti del sistema: poiché alcune parti del programma applicativo client-server possono essere eseguite su macchine diverse, è importante eliminare le dipendenze sottostanti del sistema operativo dal codice delle applicazioni: questo è necessario in quanto sovente la macchina client e la macchina server su cui l’applicazione viene eseguita sono diverse (dal punto di vista hardware). Il linguaggio Java in questo caso è di grande aiuto poiché e del tutto indipendente dalla piattaforma e i tipi di dati sono rappresentati sempre allo stesso modo su ogni sistema.
• Attuazione della modularità: è necessario creare una modularità dell’architettura del sistema client-server che si vuole implementare, attuando questa modularità a livello dei componenti fa si che l’interazione tra i componenti del sistema client-server possa essere gestita con continuità. Il linguaggio Java essendo orientato agli oggetti "impone" una struttura di tipo modulare.

Gestione dell’interazione tra client e server
Un problema che si pone nelle architetture client-server è quello di creare un meccanismo per le comunicazioni tra i componenti client e server delle applicazioni. La distribuzione dei componenti delle applicazioni attraverso una rete comporta la necessità di costruire qualche mezzo di interazione, sono disponibili diverse soluzioni a questo problema.

In genere per l’interazione dei componenti delle applicazioni sono definiti tre strati (Figura 4.4):



Figura 4.4 Strati dell'interazione tra componenti client e server.

 

Protocollo di rete

Esiste un’ampia gamma di protocolli di rete tra cui scegliere, in passato gli sviluppatori di applicazioni client-server dovevano scegliere un protocollo di comunicazione e quindi codificare manualmente l’interazione client-server, oggi la scelta diventa automatica in base al tipo di "ambiente" a cui ci si rivolge, nell’esempio di Internet il protocollo di rete sarà il TCP/IP.
Tecniche di comunicazione

L’odierno ambiente delle comunicazioni tra client e server concede ai programmatori una elevata flessibilità per la progettazione delle applicazioni, esistono diverse tecniche di comunicazione idonee a soddisfare le esigenze di interazione client-server. Ciascuna di queste tecniche di comunicazione può essere adottata indipendentemente dal protocollo di rete sottostante.

Esistono generalmente quattro meccanismi per gestire l’interazione tra client e server:

• Chiamante di procedure remote (Remote Procedure Calls, RPC): le RPC costituiscono un metodo rapido per sviluppare il codice delle applicazioni client-server, soprattutto quando si tratta di convertire programmi autonomi in componenti client-server. C’è da dire però che la codifica delle RPC è un processo difficile, inoltre esse hanno una natura estremamente sincrona: questo significa che quando un client effettua una richiesta RPC alla procedura server, resta bloccato fino al completamento della funzione e alla restituzione dei risultati da parte del server.
• Protocolli di comunicazione nativi: si costruisce un proprio protocollo di interazione tra le applicazioni client e quelle server, ciò comporta solitamente la specifica di un componete di interfaccia di rete che gestisce specificamente i protocolli di comunicazione, crea legami di comunicazione, invia e riceve i dati.
• Messaggi: un meccanismo oggi diffuso per l’interazione client-server è l’uso dei prodotti di comunicazione mediante messaggi: tali prodotti trasmettono le comunicazioni tra il client e il server in forma di messaggi; questi ultimi vengono solitamente elaborati da un meccanismo di accodamento nel nodo ricevente. Per definizione, i prodotti per la comunicazione mediante messaggi sono di natura estremamente asincrona e si comportano di conseguenza, i messaggi sono molto flessibili in quanto possono essere inoltrati ad altri sistemi o memorizzati per l’elaborazione differita. Inoltre, i prodotti di comunicazione mediante messaggi eliminano la necessita del faticoso supporto al protocollo di rete sottostante da parte dello sviluppatore.
• Orientamento agli oggetti: quest’ultima è una tecnologia emergente per la distribuzione di applicazioni. Dal punto di vista logico gli oggetti si adattano perfettamente all’ambiente client-server. Poiché l’implementazione di ciascun oggetto è mascherata dall’interfaccia a oggetti, gli oggetti possono diventare client-server senza eccessiva difficoltà. Inoltre i dati correlati sono incapsulati nell’oggetto in modo tale che l’utente della classe sia protetto dalla complessità e dall’implementazione sottostante.

La scelta di un protocollo di interazione delle applicazioni predefinito o flessibile è sovente dettata dalle applicazioni stesse. Alcune applicazioni si adattano molto bene a uno dei tipi di protocolli e dovrebbero essere realizzate di conseguenza. Un protocollo di interazione delle applicazioni predefinito obbliga l’applicazione client ad adattarsi, mentre con un protocollo flessibile i dati del client possono essere accettati e trasmessi tra i sistemi così come sono. Entrambi i protocolli presentano vantaggi e svantaggi significativi: un protocollo predefinito è preferibile per quanto riguarda la velocità e la semplicità ma è più impegnativo per quanto riguarda la programmazione lato client; un protocollo flessibile richiede meno impegno al programmatore del client inoltre i parametri delle procedure client possono essere impaccati senza che l’applicazione client debba conoscere a fondo la transizione client-server; tale protocollo può tuttavia essere meno efficiente.

L’efficienza dei protocolli deriva dalla preparazione, dalla trasmissione, dall’accettazione dalla consegna dei dati tra i sistemi. Importante diventa anche il meccanismo adottato sia dal client che dal server per impaccare e disimpaccare i dati trasmessi attraverso la rete. Con i protocolli flessibili, ciascun parametro deve essere impaccato e descritto individualmente. Questo processo può richiedere tempo , in base ai dati trasmessi tra i sistemi. Con un protocollo predefinito, i dati solitamente vengono trasmessi tra i sistemi in un formato che non richiede disimpaccamento: normalmente , un’applicazione client invia una struttura di dati che rappresenta i dati stessi tra i sistemi, mentre un’applicazione server riceve un puntatore a tale struttura di informazioni; con tale protocollo, non occorre impaccamento e disimpaccamento dei parametri.

E’ importante notare che il protocollo di interazione delle applicazioni client-server prescelto non deve avere alcuna dipendenza dal meccanismo di trasporto sottostante adottato per le comunicazioni in rete, questo significa che il protocollo di interazione delle applicazioni, se correttamente architettato, deve rimanere indipendente dai protocolli di comunicazione sottostanti.

I protocolli predefiniti al livello delle applicazioni sono prevalenti nelle applicazioni architettate fin dall’inizio per ambienti client-server. Questi protocolli sono inflessibili e di conseguenza sono estremamente efficienti per natura. Il motivo di questa efficienza è che né i componenti client né i componenti server delle applicazioni devono impaccare e disimpaccare parametri per le procedure: i parametri sono invece collocati nel client o conservati in un buffer predefinito delle applicazioni; nel server, le procedure sono smistate e trasmesse al buffer predefinito delle applicazioni, senza che il buffer debba essere disimpaccato in parametri per essere trasmesso alle procedure.

Generalmente per rappresentare un protocollo predefinito viene definita, dal programmatore una struttura per contenere tutte le interazioni delle applicazioni. La struttura possiede informazioni uniche dell’applicazione oppure dati di lunghezza variabile trasmessi tra il sistema client e il sistema server.

Quindi, in genere, il pacchetto di rete consiste nelle informazioni del protocollo di rete, nel protocollo al livello delle applicazioni e in dati di lunghezza variabile.

Il protocollo flessibile, invece, al livello delle applicazioni riduce al minimo il lavoro richiesto allo sviluppatore di applicazioni lato client, poiché un protocollo flessibile può descrivere più facilmente i dati trasmessi come parametri tra le funzioni, una quantità minore di lavoro di codifica è necessaria per lo sviluppatore e una quantità inferiore di modifiche è necessaria per impaccare, inviare, ricevere e restituire i dati dai componenti client-server.

La conversione dei parametri trasmessi tra i componenti procedurali di un protocollo flessibile è facilitata: il protocollo flessibile è studiato per consentire di posizionare un numero qualsiasi di parametri di tipo arbitrario in un buffer di dati per il trasferimento client-server. Generalmente il pacchetto di rete, per i protocolli flessibili, contiene un pacchetto di intestazione, il protocollo flessibile e dati di coda, questi ultimi hanno strutture miste che descrivono i dati trasferiti tra client e server.

Tecniche di realizzazione di applicazioni client server
Le tecniche per realizzare applicazioni client-server possono variare in larga misura, in base alle scelte specifiche operate da chi crea le applicazioni. Queste scelte determinano la modalità di creazione e gestione delle applicazioni, la modalità di interazione tra di esse e la loro efficienza. Le scelte di realizzazione, comunicazione e ottimizzazione possono ripercuotersi sull’applicazione client-server finale.

• Identificazione e raggruppamento logico di operazioni simili: il raggruppamento delle procedure contribuisce a identificare le dipendenze dei componenti procedurali, in alcuni casi, le dipendenze dovranno essere attenuate perché i componenti procedurali non sono eseguiti sulla stessa macchina.
• Suddivisione delle applicazioni in componenti Richiesta/Risposta: ciascun componente deve essere separato mediante un meccanismo ben definito. L’architettura costituita da componenti di Richiesta/Risposta, fornisce tale ambiente, in cui il componente client effettua richieste al componente server e attende la restituzione dei risultati. L’interazione dei componenti quindi non si deve basare su interazione procedurale locale. L’interfaccia tra i componenti di richiesta e quelli di risposta può variare in larga misura ed è una questione di progettazione. Adottando le chiamate a procedure remote (RPC) molte funzioni o procedure effettuano comunicazioni remote con il server. Questi componenti procedurali sono distribuiti mediante un modello di Richiesta/Risposta sincrona. Un’impostazione simile convoglia tutte le richieste procedurali del server attraverso una singola funzione o interfaccia; altri metodi di avvalgono di un’interfaccia basata sui messaggi per questa interazione. Qualunque sia il meccanismo impiegato come interfaccia ai componenti di richiesta risposta, il valore fondamentale deve essere di modellare un’interazione tra i componenti logici discreti delle applicazioni e mascherare la posizione fisica dell’esecuzione.
• Creazione di funzioni "rientranti": i componenti di risposta (server) devono essere architettati nell’ottica dei componenti di richiesta. I componenti server possono essere eseguiti contemporaneamente per conto di più client; in ambienti che supportano i thread, è importante che i componenti server siano rientranti: rientrante vuol dire che una procedura applicativa può essere chiamata più volte ed essere eseguita contemporaneamente senza causare alcun disturbo. Le applicazioni server che supportano i thread distribuiscono un thread per ciascuna connessione client. Ogni thread eseguirà molte funzioni simili per conto dei componenti di richiesta: ciascuna procedura eseguita simultaneamente deve avere caratteristiche rientranti. Le variabili globali devono essere evitate perché la loro modifica cambia il valore contenuto in altri thread effettuando la stessa chiamata di procedura.
• Accesso ai dati specifici per ciascun client: la suddivisione in componenti di richiesta (client) e componenti di risposta (server) implica che ogni accesso ai dati per conto del componente di risposta dovrà essere effettuato per ciascun singolo componente di richiesta. Poiché le funzioni del server devono essere rientranti, i dati devono essere contenuti localmente (dal client) oppure bisogna coordinare l’accesso ai dati globali. I dati specifici di ciascun client sono molto importanti per i componenti server delle applicazioni, in quanto consentono di far riferimento ai dati del client al di fuori dell’ambito di una singola procedura senza provocare modifiche accidentali, come invece avverrebbe con le variabili globali.

• Riduzione al minimo della quantità di dati trasmessi tra il client e il server: La riduzione al minimo della quantità di dati trasmessi è uno strumento di ottimizzazione quanto mai ovvio per le applicazioni client-server: quantità ingenti di dati rallentano le applicazioni, il sistema può dare l’impressione di non rispondere se la maggior parte del tempo di esecuzione viene sprecata per la trasmissione di dati non necessari. La riduzione al minimo di queste trasmissioni assicura un impatto minimo dell’utente verso l’applicazione e l’impiego limitato della rete fisica. Il trasferimento di quantità consistenti di dati attraverso una rete aumenta il carico di lavoro delle infrastrutture fisiche: la larghezza di banda della rete fisica è una risorsa statica è non deve essere consumata con dati inutili. Inoltre, le applicazioni sono rallentate dall’elaborazione delle grandi quantità di dati.
• Conservazione dei dati nel server: un altro metodo per ridurre al minimo la quantità di dati che passano tra il client e il server consiste nel conservare nel server i dati simili. Per le connessioni client-server che comportano molte interazioni tra client e server, alcune informazioni essenziali possono essere trasmesse ad ogni chiamata: generalmente, queste informazioni di stato possono essere facilmente eliminate dalla rete se il server memorizza i dati delle precedenti chiamate del client. Conservando questi dati nel server, l’efficienza dell’applicazione client-server risulta migliorata.
• Elaborazione dei protocolli predefiniti delle applicazioni: la realizzazione e la rapida elaborazione dei protocolli predefiniti delle applicazioni sicuramente miglioreranno le prestazione delle applicazioni server; questi protocolli sono potenziati da un duplice meccanismo: innanzitutto sono inflessibili quindi richiedono una quantità di tempo minima per inserire i dati nei buffer di comunicazione secondariamente, possono essere elaborati in modo efficiente dall’applicazione server, se correttamente architettati. Un componete server può essere o non essere consapevole della propria esecuzione come componente server separato. L’ottimizzazione dell’esecuzione basata sull’elaborazione efficiente dei protocolli al livello delle applicazioni richiede che il componente server sia estremamente consapevole delle proprie mansioni. L’elaborazione server dei protocolli al livello delle applicazioni può essere ottimizzata trasmettendo i veri e propri buffer dei protocolli alla procedura server per l’elaborazione.
• Server che elabora le code: l’elaborazione efficiente delle richieste del client da parte del server è essenziale per ottimizzare le applicazioni client-server: questo processo è sensibilmente potenziato dall’uso efficiente delle code. Le code di rete accelerano l’elaborazione degli eventi avviati dal client esse si adattano naturalmente all’interfaccia di un componete basato sui messaggi, in quanto i messaggi trasmessi tra i sistemi vengono elaborati dalle code. Le code non si limitano tuttavia ai messaggi e possono essere utilizzate per elaborare anche la distribuzione delle applicazioni basata su procedure. Le code servono a tutti i livelli dell’esecuzione dei componenti server: potenzialmente , vengono utilizzate tanto dall’interfaccia quanto dai meccanismi di comunicazione, accettazione e distribuzione che un’interazione client-server deve sostenere.

Figura 4.5 La divisione del lavoro dei componenti client-server.

Questa architettura per le applicazioni può essere realizzata creando le funzioni e le procedure delle applicazioni come componenti autonomi. Ciascun componente può interagire con gli altri solo tramite questa interfaccia ben definita. I componenti autonomi delle applicazioni sono un requisito della programmazione client-server.

Sviluppare applicazioni client-server vuol dire operare scelte architettoniche importanti fin dall’inizio: la scelta dell’interfaccia tra i componenti è una decisione fondamentale che determina la modalità di interazione delle applicazioni client-server.

In genere ogni metodo, o meglio qualsiasi interazione client-server ha le seguenti caratteristiche principali:

• L’interfaccia tra i componenti di Richiesta/Risposta.
• La formulazione delle richieste da parte del client.
• La trasmissione delle richieste tra i componenti.
• L’accettazione e il disimpaccamento delle richieste provenienti dal client.
• L’esecuzione delle richieste da parte del server.