Università degli studi di Bologna
Facoltà di ingegneria
Reti di calcolatori L-S
Un sistema software per
la vendita di prodotti
on-line
Studente: Rinaldi Francesco
Matricola 0900011421
Anno Accademico 2003/2004
Acquisti on-line
Azienda
Cliente
 soddisfacimento del cliente
 tempi di risposta accettabili
 prevenzione di guasti
 Sicurezza dell’acquisto
 qualità del servizio
 disponibilità del servizio
Sistema Software





Inserimento acquisti nel carrello
Cancellazione acquisti dal carrello
Visualizzazione acquisti in ordine
di costo
Visualizzazione acquisti per data di
immissione
Salvataggio acquisti su un supporto
di memorizzazione
Il sistema software terrà conto di

modelli di comunicazione remota: modello publish and subscribe, modello callback

replicazione di servizi tramite copie attive e passive

politiche di sincronizzazione per l’ accesso ad una risorsa condivisa

tecniche di load sharing
Modello publish-and-subscribe
Il cambio di stato di un elemento A implica l’invio di una notifica a uno o più componenti
dipendenti, di cui A non conosce l’identità a priori.
Si distinguono due categorie di oggetti: soggetti e osservatori. Un soggetto (o publisher)
può essere associato a zero o pıù osservatori (o subscribers), ciascuno dei quali riceve una
notifica ad ogni modifica di stato del soggetto.
I Java Bean
Un bean in Java denota una classe di componenti

Proprietà

Personalizzabilità

Eventi


Introspezione
Persistenza
Proprietà accessibili con metodi
setXXX() e getXXX()
Rappresentazione grafica esterna
modificabile con un ambiente di lavoro
sorgenti di eventi di tipo specifico
Rilevamento dinamico di proprietà,
metodi e eventi supportati
Memorizzazione del bean in una forma
personalizzata
Architettura di rete
Livelli dell’architettura di rete
 Livello applicativo
 Livello di servizio
 Rete
 Livello Server
Tipi di server in esecuzione

Server dell’utente

Server di sistema

Server di supporto
Architettura logica
1 - registrazione
Azione Login
Azione Insert
Azione Save
BeanControllo
Azione Remove
2 – arrivo di un evento
3 - notifica evento
Azione Logout
4 - notifica evento
Bean
di
elenco
9 - notifica evento
6 - notifica evento
7 - notifica evento
AdapterCosto
AdapterElenco
Listener
Elenco1
5 - notifica evento
10 - notifica evento
Bean
del
costo
Bean
di
elenco
8- notifica evento
11 - notifica evento
Listener
Elenco2
Listener
Costo

L’elenco degli acquisti è stato modellato con due Bean a cui sono associati ordinamenti diversi

Il bean del costo calcola la somma dei prezzi di tutti i prodotti presenti nel carrello
Tecnica di replicazione
Replicazione a copie passive

server di sistema: una copia attiva e una copia passiva aggiornate in modalità eager
Bean di controllo, bean di elenco, bean del costo: una tripla di copie attive e due triple di copie
passive aggiornate in modalità eager

Evento Load
BeanControllo
Azione Load
BeanControllo
Azione Load
BeanControllo
Azione Load
Nodo del Bean di
Controllo
Bean
di
Elenco
Bean
del 2°
Elenco
Bean
di
Elenco
Bean
del 2°
Elenco
Bean
di
Elenco
Bean
del 2°
Elenco
Nodo del bean del 2°
Elenco
Bean
del
costo
Bean
del
costo
Bean
del
costo
Nodo del Bean del
costo
Gestore del Bean di Controllo
Il bean di controllo si presenta come un entità senza stato che notifica un evento alle azioni registrate: le
singole copie rimangono in esecuzione per tutta la sessione utente
ListenerLogin
1 – richiesta nome Bean
di controllo
2 – connect
GestoreBeanControllo
Autenticatore
6 – nome Bean
5 – nome Bean
3 – crea
7 – crea
GeneratoreCopie
GestoreServizi
4 – crea
Nodo Client
8 – connect
BeanControllo1
BeanControllo2
BeanControllo3
ThreadPolling
ThreadPolling
Ad ogni copia passiva del bean di controllo è associato un processo che rileva, ad intervalli regolari di
tempo, lo stato di tutte le istanze associate alla copia attiva (Bean di controllo, Bean del secondo elenco,
Bean del costo) e delle istanze associate alle copie passive.
Politica di prevenzione ai guasti
Tecnica di recovery

guasti su istanze attive: eliminazione delle istanze rimanenti associate alla copia attiva, fase di elezione

guasti su istanze passive: eliminazione delle istanze rimanenti associate alla copia passiva
GestoreServizi
BeanControllo1
Bean 2°Elenco1
copia attiva
copia attiva
1 – crash copia attiva
Bean del Costo1
copia attiva
2 – eliminazione copia
3 – eliminazione copia
4 – crea copia fittizia
BeanControllo1
BeanControllo2
(BeanControlloFalso)
BeanControllo3
BeanControllo1
7 – invio richieste memorizzate
8- aggiornamento archivio
BeanControllo1
Fase di elezione
6 – inizializzazione
(BeanControllo2)
5 – elezione copia attiva
Fase di
elezione

scambio dei codici identificativi tra tutte le copie passive del bean di controllo

elezione della nuova copia attiva (copia con il codice minore)

recupero eventi memorizzati nel Bean di controllo fittizio
Politica di prevenzione ai guasti

Aggiornamento eager delle copie passive


La creazione delle copie fittizie (bean di controllo, bean del
secondo elenco, bean del costo)



il crash su una copia attiva del bean di controllo non impedisce
l’aggiornamento delle copie passive restanti.
evita l’attivazione di più bean di controllo fittizi
nasconde la fase di elezione
Il protocollo è corretto se


ogni copia passiva del bean di controllo conosce le copie candidate attive
altrimenti una copia può aspettare indefinitamente un codice da parte di
una istanza passiva che potrebbe esser andata in crash.
Server di naming
Il gestore di Naming accetta in ingresso il tipo di gestore a cui si vuole accedere e ritorna l’elenco
delle stringhe di connessione associate ai server che forniscono il servizio richiesto
GestoreNaming1
GestoreNaming2
stato
2 – crea
stato
RilevatoreStatoGestori
GestoreNaming3
stato
3 – memorizzazione richiesta in coda
1 – arrivo richiesta
Codice prenotazione: indirizzo server
NamingObject
4 – 102 : //156.7.0.98/gestorenaming3
L’accesso ad un gestore di naming avviene tramite il NamingObject, una entità di servizio che
dopo aver recuperato la lista di gestore di Naming disponibili accede ad un gestore in modo
pseudocasuale.


in caso di guasto, il NamingObject procede ad inviare la richiesta ad un altro gestore disponibile
Server di Accesso all’archivio
L’archivio tiene traccia degli ordini effettuati da un cliente ed è localizzato su tre file: il recupero
e la modifica delle informazioni include una fase di coordinamento tra le singole richieste che
accedono alla risorsa.
GestoreArchivio
Archivio1
RichiestaAccesso
Coordinatore
RichiestaAccesso
Coordinatore
RichiestaAccesso
Coordinatore
RichiestaAccesso
Coordinatore
coordinazione

la suddivisione dell’archivio riduce i tempi medi di attesa in coda

il gestore dell’archivio genera un processo per ogni richiesta di accesso
Archivio2
Archivio3
il protocollo di sincronizzazione basato sull’ ordinamento dei tempi logici di Lamport coinvolge
solo i coordinatori


è fondamentale rilevare lo stato della Richiesta di accesso che utilizza al momento la risorsa
Server di autenticazione
La fase di autenticazione permetterà all’utente di accedere al carrello dei prodotti:

l’entità di servizio Autenticatore nasconde i dettagli della fase di login all’applicazione.
Nodo Client
1 – richiesta indirizzi IP
GestoreCopieAutenticatrici
NamingObject
Autenticatore
2 – indirizzi liberi
5 – crea
3 – crea
4 – connect
GeneratoreCopie
GestoreRecRisultati
6 – crea
7 – recupera nome del
cliente
ServizioAutenticazione
ServizioAutenticazione
ServizioAutenticazione

Un guasto su una delle copie non compromette la fase di autenticazione

tecnica alternativa: fase di coordinamento tra le copie prima del rilascio del risultato
Prototipo
Un primo prototipo del sistema è stato sviluppato in Java, di conseguenza le invocazioni remote sono
state implementate tramite Java RMI.

un’applicazione esterna consente di visualizzare lo stato dei server e degli oggetti registrati nel registry

la simulazione di un crash di un componente è ottenuta effettuando un’operazione di unbind

ipotesi: i guasti non si verificano mai durante l’esecuzione di una richiesta specificata dal client
Conclusioni

Il sistema non fa alcuna ipotesi sui tempi di risposta a fronte di una
richiesta del cliente:
 politiche di load balancing tra i gestori di naming
 ridurre il numero di invocazioni sul gestore di nomi

Ulteriori sviluppi futuri includono l’introduzione di:
 procedure più complesse per il recovery ai guasti
 gestione delle transazioni
 accessi multipli dello stesso utente da diversi client