Newsgroup: it.comp.java
Titolo: Aiuto a costruire una Chat

come si costruisce una chat in java?
at...@prof.it
grazie e saluti

come si costruisce una chat in java?
L'architettura piu' semplice e' di avere un singolo processo
"servente di chat" su di un server, e piazzare su questo stesso
server il codice di un'applet che fa da front-end (thin client)
per la funzionalita' del servente di chat.  Questa e' quella che
si chiama una "topologia a stella".  Unico neo, il centro della
stella puo` diventare collo di bottiglia per le prestazioni, se il
server non e' adeguatamente dimensionato rispetto al traffico.
Usando pero' protocolli leggeri (socket UDP, cioe` a datagram,
e non TCP, cioe` a stream, ovvero connection-based) questa
eventualita' puo` spesso essere evitata.
Altre topologie tendono a scontrarsi con le limitazioni di
sicurezza delle applet, con la possibile eccezione di una
piu` complessa architettura N-tier (stella di stelle: le applet
sono scaricate da K diversi server, che a loro volta sono
in contatto con un super-server centrale; o addirittura, mesh
di stelle -- i K diversi server sono in mesh, peer-to-peer).
Sconsiglio INTENSAMENTE di avventurarsi sul progetto
di questo tipo di architetture sinche' non ci si e' fatti le ossa
con piu' progetti topologicamente e architettonicamente piu`
limitati!!!
Una volta scelta la topologia fondamentale, la corretta
scelta del protocollo e' molto importante (e indispensabile,
se il progetto e' "serio" e non semplicemente "giocattolo",
misurare ed estrapolare le prestazioni in varie condizioni
realistiche di carico simulato).  I protocolli di piu` alto
livello, e in particolare HTTP, offrono una serie di vantaggi
(come la trasparenza ai firewall) a fronte di appesantimenti
che a volte possono essere notevoli dal punto di vista delle
prestazioni; incapsulare in questi termini le semplici
funzionalita' richieste da un chat puo` inoltre essere poco
agevole.  In questa fase merita "guardarsi in giro", vedendo
quali librerie di classi si possono trovare gia` disponibili per
l'incapsulamento; ed e' indispensabile definire le esatte
specifiche funzionali (e' necessaria la trasparenza ai
firewall...? ecc ecc) e prestazionali.  Spesso, si trovera`
che le buone, vecchie, semplici socket (stream o dgram
che siano), offrono la soluzione migliore per questo tipo
di problemi; particolarmente deludente, nella mia modesta
esperienza in merito, tendono a rivelarsi le RMI, mentre
DCOM (pur avendo, in congiunzione a MTS e MSMQ,
grandiose caratteristiche di scalabilita') tende a limitare
troppo la portabilita' del codice.  CORBA e' un'altra
possibilita' (sorprendentemente poco scalabile nella
gran parte delle sue implementazioni, ahime`!!!), e cosi'
pure lo sono approcci innovativi come ObjectSpace
Voyager, ecc.
Definiti i parametri architetturali fondamentali -- topologia
e protocolli -- si passa alla progettazione vera e propria.
Non e' facile fare considerazioni generali da questo punto
in avanti, perche` troppo dipende dalle scelte di tipo
"architettonico" compiute sino a questo punto.  Supponendo
ad esempio di avere scelto architettura a stella e socket,
il prossimo passo e' definire la tipologia del "servente di
chat".  Se sul server d'interesse sono disponibili le servlet,
esse possono a volte offrire la soluzione migliore.  Se no,
si prenda in considerazione la possibilita` di avere il servente
di chat come "demone" (terminologia Unix; "service" in
terminologia Windows/NT): se il processo servente e'
"sempre attivo", dormiente in attesa di connessione su
di una server-socket (o dell'arrivo di un datagram) con un
port number "ben conosciuto", questo semplifica molto la
realizzazione, rispetto alla necessita' di attivare il server
"just-in-time"/"on-demand" -- ma non e' detto che il server
"sempre vivo" sia accettabile (in Unix, e' possibile avere
un buon compromesso attraverso il super-demone inetd,
e Windows/NT offre varie possibilita' quasi analoghe).
Se si scelgono i datagrammi, bisogna compensare per il
fatto che sono soggetti a delivery multipla, fuori ordine, e
inaffidabile -- il prezzo, per il programmatore applicativo,
della loro "leggerezza" in termini di prestazioni (e delle
innegabili comodita' che comportano).  Le connessioni
(stream) sono piu` semplici da questo punto di vista, ma
la "brusca caduta" di una connessione, che va sempre
prevista, puo` comportare tutta una serie di problemi (e
puo` essere assai difficile da diagnosticare per il server).
Ma a questo punto stiamo parlando (beh, gia` da un pezzo)
di problematiche piu` o meno indipendenti dal linguaggio di
programmazione usato, e molto dipendenti invece dalle
scelte architettoniche fatte "a monte".  Java qui e' rilevante
solo per le facility che offre, come il multithreading, e al
limite per eventuali problemi di prestazioni (naturalmente,
nulla vincola a implementare il servente di chat nello stesso
linguaggio usato per i front-end, ovvero thin-client, se la
scelta di altri linguaggi dovesse offrire sostanziali vantaggi
di prestazioni; l'unica scelta architetturale che impedirebbe
d'altronde di "migrare" l'implementazione da un linguaggio
ad un altro sarebbero le RMI, altra ottima ragione a mio modo
di vedere per evitarle come la peste [beh, per essere onesti,
anche il brillante ObjectSpace Voyager non renderebbe certo
la vita facile a chi volesse avere il servente in altri linguaggi
che Java...!]).
Spero di avere dato sin qua abbastanza materiale da studiare
e rimuginare, senza bisogno per ora di considerare specifici
dettagli di codifica e di progettazione dettagliata, che tutto
sommato sono le cose piu` facili e meno importanti rispetto
a questo tipo di macro-considerazioni.
Alex