FotoContest
Il primo servizio interamente
dedicato ai Concorsi Fotografici
basato su Corba
Reti di Calcolatori LS
Prof. Antonio Corradi
Progetto:
Giombi Giorgio e Soffritti Luca
Presentazione:
Giombi Giorgio
1
Introduzione
L’obiettivo di questo progetto è stato quello di realizzare
un’applicazione per la creazione e gestione di Concorsi
Fotografici a tema con scadenza periodica, sfruttando gli
strumenti forniti dallo standard CORBA e ponendo particolare
attenzione alla gestione delle risorse ,all’efficienza complessiva
del sistema e soprattutto alla tolleranza ai guasti.
Modello di Comunicazione
Client/Server
sistema asimmetrico e indiretto
comunicazione sincrona bloccante
Client
Server
2
Architettura Generale (1)
L’utente (Client) accede a tutti i servizi offerti comunicando in
maniera trasparente con tre differenti Server.
ServerAuth:
Gestione
Autenticazione
ServerFoto:
Gestione Concorso
(Concorso in atto)
ServerArchivio:
Gestione Archivio
(Concorsi terminati)
ServerRepl:
Server di controllo
Gestione della QoS
3
Architettura Generale (2)
Il middleware CORBA:
come strumento di
supporto completo alla
comunicazione in remoto
Facilita quindi la
realizzazione di sistemi
distribuiti, permettendo
allo sviluppatore di
trascurare l’aspetto
tecnologico
concentrandosi solo sul
servizio da fornire.
C
O
R
B
A
C
O
R
B
A
4
Perché Corba?
• Eterogeneità di Linguaggio:
tramite IDL
IDL è possibile
definire le interfacce
(descrizione dei servizi
offerti) di ogni oggetto
remoto rimanendo totalmente
indipendenti dal linguaggio
di programmazione e dalla
macchina di esecuzione
• Indipendenza Client/Server:
l’ ORB , cuore del sistema,
gestisce tutta la
comunicazione permettendo ad
un Client di legarsi ad un
servizio, non ad un servitore!
• Maggiori Servizi offerti:
un NAME
name SERVICE
service più evoluto
e strutturato
<<Lookup>>
Client
NAME
SERVICE
<<Register>>
Server
5
Il Client
Login
(Registrati)
ServerFoto
Login
Logout
Vai all’
Utente…
Vota Foto
Salva Foto
Vai alla
Pagina…
ServerAuth
Vai al
Concorso
Vedi Foto
Client
Vai alla
Mia Pagina
ServerArchivio
Vedi Foto
Vai all’
Archivio
Inserisci
Foto
Cancella
Foto
Seleziona
Concorso
6
Il Client – come
metodi
Servitore
remoti invocati
cacheArchivio
cacheConcorso
notificaContest()
NB
Sono state previste lato client due
directory per salvare e mantenere le foto
•
Anche il Client rende disponibile all’esterno uno
in modo da non richiamare inutilmente
specifico
remoto
ogni voltametodo
il metodo
remoto getFoto()
•• Appositamente
definito per permettere al ServerAuth
cacheConcorso
di notificarlo immediatamente quando un concorso
• cacheArchivio
termina
7
Il ServerAuth
Gestione Autenticazione:
• Garantisce l’accesso al
Servizio solo ai Client che si
sono precedentemente registrati
Gestione Notifica di Fine
Concorso:
• Permette di notificare a
tutti gli iscritti l’avvenuta
fine di un concorso
• Mantiene tre distinti
vettori per gestire
correttamente tale notifica
iscritti.txt
username
notificaContest()
O
F
Giorgio
F
… L
I
… N
… E
passwordD
O
A
…L
I
…N
E
O
T
I
F
I
C
A
N
#x+ù@k2##
N
…
8
Il ServerFoto
Gestione Concorso:
• Mantiene tutte le foto del concorso
in atto in formato jpg
• Mantiene le informazioni relative a
tale concorso (titolo, scadenza) e alle
foto inviate(titolo, autore, numero
voti, utenti che hanno votato) in un
file XML, foto.xml
• Crea e salva inoltre le relative
miniature di ogni immagine partecipante
Trasferimento dei File Immagine
Rappresentando
Rappresenta
l’operazione
però il collo
principale
di
del
struct fileFoto
ServerFoto,
bottiglia
del
richiesta
sistema si
quando
è pensato
un Client:
di
{
• vuole
introdurre:
aggiungere
foto > file;
sequence
<octetuna
,500000
• vuole
visualizzare
una pagina
numeroByte;
• lelong
miniature
per caricare velocemente
• vuole
vedere una specifica foto
una string
intera nomeFoto;
pagina
string utente;
• unshort
Limite
in KB su ogni foto inviata
voti;
fileFoto
};
• un Limite Max
di 9 foto per concorso
fotoConcorso
foto.xml
iconeConcorso
9
Il ServerArchivio
Gestione Archivio:
• Progettato per mantenere tutte
le “vecchie” foto e i file
foto.xml, in modo che l’utente
possa sempre rivedere i tre
vincitori e le proprie immagini di
ogni Concorso Terminato
• Realizzato per non
sovraccaricare di troppe richieste
il ServerFoto, suddividendo così
le responsabilità e i rispettivi
carichi di lavoro
concorsi.txt
titolo1
titolo2
titolo2
titolo3
titolo…
titolo1
foto.xml
titolo3
titolo…
10
Gestione Termine Concorso
foto.xml
Termine
Concorso
ServerFoto
fotoConcorso
Client onLine
Titolo Concorso
1) titoloFoto, autore, voti
2) titoloFoto, autore, voti
3) titoloFoto, autore, voti
iconeConcorso
notifica()
ultimoConcorso()
notificaContest()
ThreadUltimoConcorso
ThreadAuthNotifica
ServerAuth
ServerArchivio
concorsi.txt
iscritti.txt
titolo…titolo…
titolo…
titolo…
O
F
F
L
I
N
E
O
N
L
I
N
E
D
A
N
O
T
I
F
I
C
A
Client
daNotifica
Client
offLine
11
Conclusioni & Sviluppi futuri
Conclusioni:
–
Il progetto è stato testato più volte sia in localmente che
su più macchine con esiti positivi e tempi di risposta
accettabili
–
La scelta progettuale di avere tre differenti server con
tre specifici compiti (gestione Autenticazione – gestione
Concorso – gestione Archivio) comporta sicuramente un
maggiore costo in fatto di risorse ma tale scelta viene
ripagata da una maggiore efficienza complessiva del sistema
Sviluppi Futuri:
– ServerFoto replicato in grado di gestire più richieste
parallelamente, per prevenire situazioni di forte congestione
– Più concorsi attivi contemporaneamente
– Possibilità di commentare le foto
– Concorsi a pagamento con premi in denaro ai vincitori
12
Fine
13