Architettura Client/Server
Le reti riescono a condividere in modo eccellente dati e risorse ma
risentono dei problemi legati alla velocita' di trasmissione dei dati, che e'
sempre limitata. Le soluzioni client/server mirano a contenere i problemi
legati a
questo punto debole nel modo piu' ovvio possibile , cioe'
cercando di ridurre la quantita' di dati che circola nella rete. Se ad un'
applicazione non client/server in esecuzione su un computer client viene
richiesto di visualizzare, ad esempio, i fornitori di una data localita'
prelevandoli da un archivio residente su un server collegato in rete,
(architettura a file condiviso) , l'applicazione "legge l'archivio" (cioe'
copia i dati dal disco del server nella memoria del computer client dove
l'applicazione stessa e' in esecuzione) per poter filtrare localmente i record
non utili e presentare poi all'utente solo quelli richiesti. In tal modo i dati
di tutti i fornitori sono transitati sulla rete. Viceversa, con una soluzione
client/server l'applicazione si limita ad inviare al server una precisa
richiesta di invio dati (query). Sul server e' presente un RDBMS, ovvero un
software che accoglie la richiesta inviata dal computer client , effettua la
lettura e il filtraggio dei dati come indicato nella query e ritorna sulla rete
solo i record utili.(RDBMS sta per sistema di gestione di database
relazionali.) Esistono molti produttori di RDBMS: Oracle, Microsoft (con SQL
Server), IBM e altri che consentono di implementare questo tipo di architettura
client/server tradizionale detta anche a due livelli. La stragrande maggioranza
delle applicazioni client/server e' di questo tipo, con motore RDBMS installato
sul server e un'applicazione (front-end) installata su ciascuno dei computer
client interessati. Nota: Il motore JET di ACCESS (motore gratuitamente
distribuito con Visual Basic) non e' un RDBMS, benche' consenta di gestire un
database relazionale (database MDB). Un' applicazione puo' certamente inviare a
JET una query (attraverso ADO.NET) ed ottenere il risultato ma JET e' un file
DLL (libreria a collegamento dinamico) per cui viene caricato nella memoria
dello stesso computer dell'applicazione che ne fa riferimento (e cioe' il
client). Per questo motivo, anche se e' JET che svolge il compito di reperire
il risultato e passarlo all' applicazione non si ottiene alcun risparmio di
transito dati in rete. JET va dunque escluso da questo tipo di architettura .
Architettura Client/Server a tre livelli
L' architettura client/server a due livelli e' la piu' semplice a realizzarsi
ma non e' di semplice manutenzione (ad esempio, un cambiamento
dell'applicazione di front-end comporta un complesso aggiornamento da
effettuare su tutti i client). Si cerca di rendere sempre meno gravoso il
compito del client cercando di spostare altrove il carico di lavoro (thin
client, clienti leggeri). L'architettura che ne risulta e' quella con un
ulteriore livello intermedio. In sostanza il livello intermedio e'
rappresentato da uno o piu' librerie (componenti Busines) chiamati a svolgere
alcune mansioni logiche. L'Architettura client/server con componenti risulta
certamente molto piu' complessa da progettare ma presenta alcuni indubbi
vantaggi rispetto a quella tradizionale a due livelli. Tali architetture dette
three tier possono realizzarsi attraverso diverse tecniche.
Panoramica Tecnica
Il nuovo linguaggio di programmazione Microsoft Vb.Net mette a
disposizione due tecnologie per la realizzazione di una applicazione
client/server : Web Service e Net Remoting. Il primo tipo di tecnologia viene
essenzialmente utilizzato per la realizzazione di servizi Web (classi
invocabili su server web IIS) da client che girano su qualsiasi sistema
operativo. Il secondo e' invece piu' specificamente rivolto alla realizzazione
di applicazioni gestionali distribuite e non richiede la presenza di web server
installati sul computer che funge da Host. Fatte queste considerazioni si e'
deciso di utilizzare la tecnologia Net Remoting (anche considerando che
opportune valutazioni in fase di sviluppo consento di passare velocemente da
una implementazione ad un'altra).
La Tecnologia Net Remoting
Microsoft .NET remoting fornisce una struttura che consente agli
oggetti di interagire fra loro su domini di applicazione. La struttura fornisce
una serie di servizi, tra cui supporto di attivazione e durata, oltre a canali
di comunicazione che si occupano del trasporto di messaggi verso e da
applicazioni remote. I formattatori vengono utilizzati per la codifica e
decodifica dei messaggi, prima che il canale li trasmetta. Le applicazioni
possono utilizzare la codifica binaria in caso di prestazioni critiche, oppure
la codifica XML laddove è essenziale l'interoperabilità con altre strutture
remote. Tutte le codifiche XML utilizzano il protocollo SOAP per la
trasmissione dei messaggi da un dominio di applicazione a un altro. La gestione
della durata degli oggetti remoti senza un supporto della struttura sottostante
non è sempre facile. .NET remoting mette a disposizione una serie di modelli di
durata tra cui scegliere, suddivisi in due categorie:
-
Oggetti attivati da client -
Oggetti attivati da server
Gli oggetti attivati da client sono controllati da un programma di gestione
durata basato su lease, che assicura che l'oggetto venga sottoposto a garbage
collection alla scadenza del lease. Nel caso di oggetti attivati da server, gli
sviluppatori possono selezionare un modello "single call" (istanza diversa per
ogni chiamata)o "singleton(istanza unica)". La tecnologia Net remoting fornisce
dunque la base per la comunicazione tra i componenti. Una tipica applicazione
Client server sara' dunque costituita da due programmi: un programma Host che
"ospita " l'oggetto remoto e un programma client che invoca l'oggetto remoto.
Il remoting mette dunque a disposizione la tecnologia per la comunicazione tra
i programmi. Il programma host puo' essere realizzato in diversi modi: Consolle
application( applicazione consolle che deve essere lanciata su server affinche'
possa creare, dopo invocazione del client, istanze dell'oggetto remoto) ,
servizio Win NT 4.0 o Windows 2000, applicazione win32 classica. In tale
applicazione viene posto il riferimento alla classe remota e viene scritto il
codice che permette di istanziarla. Nel caso di un Web service l'applicazione
Host sara' la Web Service stessa. Si comprende dunque da questa descrizione
come il passaggio da una tecnologia all'altra sia alquanto semplice. Il
componente remoto rimane sempre lo stesso (una .dll) a cambiare e' invece il
programma host. Naturalmente la creazione di un componente che sia in grado di
funzionare in entrambi i modi necessita di rispondere a determinate
caratteristiche che tengano in considerazione i limiti a cui deve soggiacere
una Web Service come per esempio il fatto che in questo tipo di applicazione le
classi remote non posso avere uno stato (viene creata una una nuova istanza di
oggetto per ogni chiamata da parte del client). I Canali di comunicazione che
e' possibile utilizzare sono due : HTTP e TCP. Il primo e' considerato quello
maggiormente consigliato in termini di funzionamento in presenza di FIREWALL
mentre il secondo viene utilizzato in condizioni critiche (quando per esempio
il protocollo http e' troppo lento per le applicazioni che si intende
realizzare). Il primo protocollo consente la trasmissione dei dati in formato
ASCII il secondo in formato Binario. I componenti possono comunicare con RDBMS
sul server e, utilizzando la tecnologia .NET REMOTING, con le applicazioni sui
client. Il progetto di una procedura viene a dividersi, cosi', in due parti:
progetto della parte client e progetto dei componenti di livello intermedio. Un
ulteriore vantaggio e' rappresentato dal fatto che qualsiasi altro programma
che supporti la tecnologia in oggetto puo' utilizzare tali componenti .
Fisicamente i componenti possono risiedere su altri computer ma anche sullo
stesso server che ospita il RDBMS. Nota: Certamente, per quanto detto nella
nota sopra, JET e' un motore per database locali e non remoti. Va pero'
osservato che se ad utilizzare Jet e' un componente che si trova sul server e
non direttamente l'applicazione client, JET viene caricato in memoria sullo
stesso computer del componente che ne fa riferimento (cioe' sul server) e
pertanto le query vengono risolte sul server. In pratica l'applicazione client
invia la richiesta al componente (attraverso un canale remoto) il quale passa
la query a Jet (tramite ADO.NET) che la elabora e ritorna il risultato al
componente che lo invia definitivamente al client (remoting): il principio
dell'architettura client/server e' rispettato: solo i dati utili transitano
sulla rete. Puo' sembrare allora che con l'architettura a componenti, non si
abbiano problemi di scalabilita' utilizzando JET al posto di un vero RDBMS.
Purtroppo non e' proprio cosi' : occorre prendere in considerazione anche altri
aspetti e coinvolgere il concetto di multithreading. Un componente puo' essere
multithread nel senso che puo' rispondere "contemporaneamente" a piu' richieste
inviate da svariati client , Jet invece puo' eseguire le query solo in modo
seriale: se un client manda una richiesta e il componente passa tale richiesta
a Jet, finche' quest'ultimo non ha terminato l'esecuzione, le altre richieste
in arrivo da altri client saranno accodate pur essendo il componente
multithread. In pratica JET viene a rappresentare, se i client vanno oltre un
certo numero, un vero e proprio collo di bottiglia. Se ogni Query richiedesse
lo stesso tempo di esecuzione (indipendentemente se di breve o di lunga
durata), su server dotati di processore unico, la serializzazione operata da
Jet non rappresenterebbe un problema aggiuntivo , nel senso che i tempi di
esecuzione in tal caso dipendono esclusivamente dalla velocita' dell' hardware.
Il problema si ha invece quando una query di breve durata viene serializzata
dopo una di lunga durata. In un sistema multithread la risposta alla query
breve si avrebbe prima di quella di grande durata mentre nel caso seriale si ha
l'inverso. Il problema puo' essere parzialmente risolto se le query che
generalmente sono, per loro natura, di lunga durata vengono eseguite su un
componente diverso da quello che esegue quelle di breve durata. Infatti, in tal
caso, ciascuno dei due componenti carica il suo Jet in memoria. E' possibile
dunque utilizzare JET sfruttando i vantaggi legati alla sua semplicita'
rispetto alla complessita' di gestione di un vero RDBMS, ma si ottiene un
programma non scalabile, nel senso che le prestazioni calano all'aumentare del
numero degli utenti (di norma con il motore Jet si riescono ad avere
prestazioni accettabili fino ad un limite di 10/20 terminali anche se
teoricamente ne potrebbe supportare 255)
Conclusione
In base a quanto esposto la scelta dell'architettura con la quale Winwaste
sara' realizzato non puo' che ricadere sull'architettura a componenti. Saranno
dunque sviluppate diverse classi per l'accesso ai dati e le istanze di tali
classi saranno esposte da un programma host (win32 o win2000 service?) ai vari
client che ad essi si collegano.
Sud Italia: Corso Umberto I, 251 - 80034 Marigliano (NA) Tel.: +39 081 8854335 - Fax: +39 081 8855619 Nord Italia: Via San Giorgio, 6 - 24122 Bergamo (BG) Tel.: +39 035 270221 - Fax: +39 035 2281092 Codice Fiscale: 05669600636 - Partita IVA: 02732221219 Reg. Imprese NA n. 05669600636 - REA n. 453994
Cap. Sociale Euro 60.000 i.v.
