|
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)
|
