Organizzazione della lezione Lezione 1 Obiettivi del corso ... · – di linguaggio di...

Lezione 1Lezione 1Sistemi DistribuitiSistemi Distribuiti

Vittorio ScaranoCorso di Sistemi Distribuiti (2003-2004)

Laurea Specialistica in Informatica

Università degli Studi di Salerno

Sist

emi D

istr

ibui

ti (

2003

-200

4).

Vi.t

tori

oSc

aran

o

2

Organizzazione della lezioneOrganizzazione della lezione

• Obiettivi del corso di Sistemi Distribuiti

• Cosa è un sistema distribuito

• Esempi di Sistemi Distribuiti

• I requisiti di un Sistema Distribuito

• Trasparenza nei Sistemi Distribuiti

Sist

emi D

istr

ibui

ti (

2003

-200

4).

Vi.t

tori

oSc

aran

o

3

Obiettivi del corsoObiettivi del corso

• Comprendere le tecniche ed i principi utilizzati per costruire Sistemi Distribuiti– “Tecniche”

• astrazione dalle tecnologie disponibili

– “Principi”• linee guida nella progettazione

• In questa lezione:– cosa sono i Sistemi Distribuiti,

– perché dovremmo volere progettare un Sistema distribuito

– cosa vogliamo che si veda (e cosa non vogliamo che si veda) di un Sistema Distribuito

Sist

emi D

istr

ibui

ti (

2003

-200

4).

Vi.t

tori

oSc

aran

o

4



• Cosa è un sistema distribuito• Esempi di Sistemi Distribuiti



Sist

emi D

istr

ibui

ti (

2003

-200

4).

Vi.t

tori

oSc

aran

o

5

Hostn-1

Hostn

Host2

Host1

CosaCosa è un è un sistemasistema distribuitodistribuito??

MiddlewareMiddleware

MiddlewareMiddleware

Network Operating SystemNetwork Operating System

Network Operating SystemNetwork Operating System

HardwareHardware

HardwareHardware

Component1 ComponentnComponent1 Componentn

Component1 ComponentnComponent1 Componentn

Network

Sist

emi D

istr

ibui

ti (

2003

-200

4).

Vi.t

tori

oSc

aran

o

6

Cosa è un sistema distribuitoCosa è un sistema distribuito

• Un insieme di host autonomi connessi attraverso una rete

• Ogni host può eseguire– componenti distribuite– un middleware che permette la interazione tra le componenti

• Il middleware permette di coordinare le attività – in modo che l’utente possa percepire il sistema come un

singolo sistema di calcolo integrato– in modo che il programmatore (di applicazioni) possa

percepire il sistema come un singolo sistema di calcolo integrato (per quanto possibile/suggeribile)

• End-to-End argument

Sist

emi D

istr

ibui

ti (

2003

-200

4).

Vi.t

tori

oSc

aran

o

7

EsempiEsempi di Middleware di Middleware

• Transaction-oriented– IBM CICS

– BEA Tuxedo

– IBM Encina

– Microsoft Transaction Server

• Message-oriented– Microsoft Message Queue

– NCR TopEnd

– Sun Tooltalk

• Procedurali– Sun ONC

– Linux RPCs

– OSF DCE

• Object-oriented– OMG CORBA

– Sun Java/RMI

– Microsoft COM

– Sun Enterprise Java Beans Sist

emi D

istr

ibui

ti (

2003

-200

4).

Vi.t

tori

oSc

aran

o

8

Caratteristiche di un Sistema Centralizzato Caratteristiche di un Sistema Centralizzato

• Una singola componente senza parti autonome• Autonomia delle parti

– cruciale per la differenza tra centralizzato e distribuito– cioé il sistema mantiene il controllo pieno su tutte le parti

• Normalmente, omogeneo– stesso linguaggio, compilatore, linker, loader, etc.

• Risorse condivide da vari utenti• Programma eseguito in un unico processo:

– condivisione di spazi di indirizzamento, sincronizzazione “facile”,

• Singolo punto di controllo– registri, stack, PC, etc.

• e di fallimento (funzionano oppure no)

Sist

emi D

istr

ibui

ti (

2003

-200

4).

Vi.t

tori

oSc

aran

o

9

Sistema distribuiti Sistema distribuiti -- 11

• Componenti multiple che hanno una propria autonomia– ognuna ha il controllo delle proprie parti

– non esiste un controllo centralizzato sulle parti delle componenti

• Non omogenee– necessità per integrazione con HW/SW legacy

• linguaggi, S.O., rappresentazione dati

• Possibile l’uso esclusivo – componenti (risorse) che possono essere usate da un solo

utente per volta

– al crescere delle richieste, si aumentano le componenti

Sist

emi D

istr

ibui

ti (

2003

-200

4).

Vi.t

tori

oSc

aran

o

10

Sistema distribuiti Sistema distribuiti -- 22

• Esecuzione concorrente in diversi processi– necessaria la comunicazione inter-process

• Gestione e controllo mediante punti multipli– problema rilevante in ambito aziendale

• strategie di deployment applicazioni, monitoraggio, controllo

• Failures parziali– parti del sistema sono pienamente operative ma altre no

– gestione dinamica di risorse che entrano ed escono dal sistema

Sist

emi D

istr

ibui

ti (

2003

-200

4).

Vi.t

tori

oSc

aran

o

11







Sist

emi D

istr

ibui

ti (

2003

-200

4).

Vi.t

tori

oSc

aran

o

12

Motivazioni allo studio di esempiMotivazioni allo studio di esempi

• Alcuni casi:1. Hong Kong Telecom’s Video-on-demand (reale)

2. Infrastruttura della banca UBS (reale)

3. Gestione della configurazione del Boeing’s 777 (reale)

4. Gestione delle tasse nella Federazione Russa (reale)

5. Gestione di una Lega di Squadre di Calcio (fittizio)

• Per estrapolare tecniche e principi …. – come esempi motivanti

– e come campo di sperimentazione per le nostre applicazioni

Sist

emi D

istr

ibui

ti (

2003

-200

4).

Vi.t

tori

oSc

aran

o

13

1. Hong Kong 1. Hong Kong TelecomTelecom “Video on “Video on demanddemand””

• Obiettivo: – fornire agli abbonati la possibilità di scaricare video dai

server della HK Telecom verso low-cost Web-TVs.

• Attualmente circa 90,000 users.

• Costruita utilizzando tecnologia ad oggetti distribuiti

…

Sist

emi D

istr

ibui

ti (

2003

-200

4).

Vi.t

tori

oSc

aran

o

14

Requisiti della architettura Requisiti della architettura -- 11

• Hardware:– Clients: Web-TV

– Servers: processore RISC

• Eterogeneità del Sistema Operativo:– Clients: Java OS

– Servers: UNIX

• Eterogeneità del linguaggio di programmazione:– Clients: Java

– Servers: C++

Sist

emi D

istr

ibui

ti (

2003

-200

4).

Vi.t

tori

oSc

aran

o

15

Requisiti della architettura Requisiti della architettura -- 22

• Comunicazione via rete– come trasmettere strutture dati complesse via rete?

• Evitare il paradosso della “morte per troppo successo”– deve essere possibile scalare le prestazioni all’aumentare

degli abbonati (da poche centinaia a 90,000 in poco tempo)

• Problemi di sicurezza– pagamento sicuro

– autenticazione

Sist

emi D

istr

ibui

ti (

2003

-200

4).

Vi.t

tori

oSc

aran

o

16

La soluzione: tecnologia ad oggetti distribuitiLa soluzione: tecnologia ad oggetti distribuiti

• Perché una soluzione distribuita:– lato client: Web-TV multiple per download/show dei video

– lato server: server replicati/distribuiti per assicurare prestazioni elevate

• Perché una soluzione ad oggetti:– i client sono scritti in Java

• le Web-TV hanno una JVM

• portabilità (Sony Playstation, Sega-Console, …)

– i server sono scritti in C++:• efficienza

Sist

emi D

istr

ibui

ti (

2003

-200

4).

Vi.t

tori

oSc

aran

o

17

TradingWorkstation

AuthorisationServices

Host Services

Customer Information

Services

Product DatabaseServices

MarketingServices

2. 2. InfrastrutturaInfrastruttura delladella bancabanca UBSUBS

Sist

emi D

istr

ibui

ti (

2003

-200

4).

Vi.t

tori

oSc

aran

o

18

Requisiti Requisiti -- 11

• Calcolo del “Time to market”– necessità di sviluppo di applicazioni con tecnologia recente

• che entrino sul mercato prima che la tecnologia invecchi! ☺

– Integrazione del preesistente sempre più difficile

• Scalabilità– Gestione di 30,000,000 di conti correnti

– Gestione di 10,000,000 clienti

– Uso concorrente da 2,000 utenti (in media)

• Affidabilità

• Basato su transazioni (circa 2 milioni al giorno/server)

Sist

emi D

istr

ibui

ti (

2003

-200

4).

Vi.t

tori

oSc

aran

o

19

Requisiti Requisiti -- 22

• Eterogeneità – di hardware

• Unisys Mainframes• IBM Mainframes• SPARC Servers• PC Workstations

– di Sistema Operativo • MVS• UNIX• Win-NT

– di linguaggio di programmazione • Cobol• C/C++• Visual Basic

Sist

emi D

istr

ibui

ti (

2003

-200

4).

Vi.t

tori

oSc

aran

o

20


• Perchè una soluzione distribuita?– vista uniforme e coerente di tutti i servizi della banca– livello di astrazione appropriato per le transazioni

commerciali

• Investimento che viene preservato nel tempo– l’integrazione con le applicazioni legacy è intrinseco

• Permette di utilizzare lo sviluppo OO per le nuove componenti– affidabilità, riusabilità, astrazione, etc.

• Permette di risolvere i problemi di– localizzazione distribuita (filiali, etc.)– eterogeneità (HW, SW, SO, etc.)

Sist

emi D

istr

ibui

ti (

2003

-200

4).

Vi.t

tori

oSc

aran

o

21

3. 3. GestioneGestione delladella configurazioneconfigurazione del Boeing 777 del Boeing 777

Sist

emi D

istr

ibui

ti (

2003

-200

4).

Vi.t

tori

oSc

aran

o

22

Alcuni “Alcuni “probleminiproblemini”… ”…

• Dimensione del problema– 3,000,000 di parti diverse per aeroplano – la configurazione di ogni aeroplano è diversa– i regolamenti obbligano a mantenere log degli interventi per

ogni singola parte di ogni aeroplano– i modelli di aeroplani evolvono durante la manutenzione– la Boeing produce 55 aeroplani all’anno– il database cresce di 1,5 miliardi di parti all’anno– la vita di ogni aeroplano è di circa 30 anni– 45000 persone hanno bisogno di accesso on-line ai dati

• circa 9000 in maniera concorrentee se non bastassero…

Sist

emi D

istr

ibui

ti (

2003

-200

4).

Vi.t

tori

oSc

aran

o

23

Altri Altri problemi…problemi…

• Integrazione di prodotti COTS– “Commercial Off The Shelf” – la infrastruttura precedente non più sufficiente– la Boeing non poteva permettersi di costruire una

infrastruttura propria– componenti acquistate da diversi fornitori:

• tecnologia di database relazionali • enterprise resource planning• computer aided project planning

• Dimensioni e eterogeneità:• 20 server Sequent con Oracle• 200 Server Unix per il software specifico• numerose workstation per la visualizzazione (NT e Unix)

Sist

emi D

istr

ibui

ti (

2003

-200

4).

Vi.t

tori

oSc

aran

o

24


• Perchè una soluzione distribuita ad oggetti?• Integrazione di interi package di software come oggetti

– “Object wrapping”

• Soluzione della distribuzione delle componenti– ad alto livello

• Soluzione della – eterogeneità– scalabilità

Sist

emi D

istr

ibui

ti (

2003

-200

4).

Vi.t

tori

oSc

aran

o

25

4. Sistema gestione tasse nella federazione russa4. Sistema gestione tasse nella federazione russa

• Ministero russo delle tasse– 89 agenzie regionali

– 2500 agenzie distrettuali

– circa 7,5 terabytes di dati

– circa 75000 workstations

• Meccanismi di ispezione tasse dinamici– regolamentazioni, controlli in corso

Sist

emi D

istr

ibui

ti (

2003

-200

4).

Vi.t

tori

oSc

aran

o

26

I I problemi…problemi…

• Necessario un sistema:– affidabile

– scalabile

– flessibile per accogliere le modifiche in corso del sistema di calcolo delle tasse

• Necessaria la integrazione di sistemi preesistenti– federali: basati su Oracle

– locali: basati su Microsoft

Sist

emi D

istr

ibui

ti (

2003

-200

4).

Vi.t

tori

oSc

aran

o

27

5. Gestione di una Lega di Squadre di Calcio 5. Gestione di una Lega di Squadre di Calcio

• Gestisce una lega di club, la nazionale, le squadre, il trasferimento dei giocatori, etc. – anche i contratti in nero, le plusvalenze, etc.? ☺

• Un sistema fittizio– per illustrare alcuni esempi

Sist

emi D

istr

ibui

ti (

2003

-200

4).

Vi.t

tori

oSc

aran

o

28

RequisitiRequisiti

• Autonomia di ogni singolo club– propria amministrazione, gestione gare/allenamenti– con diverse squadre (la Primavera, allievi, etc.)

• Necessaria la integrazione per – registrare il cartellino di un giocatore nella Lega– convocare i giocatori per la nazionale– ottenere un accordo sul calendario delle partite

• Naturalmente localizzato sul territorio– distribuito ☺

• Eterogeneità (di HW/SW/SO)• Diversità di dimensione dei club

– connessione (ADSL, dedicata, modem, etc)– hardware

Sist

emi D

istr

ibui

ti (

2003

-200

4).

Vi.t

tori

oSc

aran

o

29







Sist

emi D

istr

ibui

ti (

2003

-200

4).

Vi.t

tori

oSc

aran

o

30

RequisitiRequisiti

•• Integrazione di componenti che siano:Integrazione di componenti che siano:–– nuovenuove

–– ereditate (ereditate (legacylegacy))•• non da non da riprogettareriprogettare

–– commercial offcommercial off--thethe--shelfshelf•• non modificabilinon modificabili

•• Eterogeneità diEterogeneità di–– hardwarehardware

–– sistema operativosistema operativo

–– reterete

–– linguaggi di programmazionelinguaggi di programmazione

Sist

emi D

istr

ibui

ti (

2003

-200

4).

Vi.t

tori

oSc

aran

o

31

Il processo di sviluppo dei sistemiIl processo di sviluppo dei sistemi

• Analisi dei requisiti

• Requisiti– funzionali: funzioni che il sistema deve realizzare

• localizzabili in una qualche componente

– non funzionali: relativi alla qualità del sistema • di solito globali • con un impatto notevole nella fase di design

– scelta della architettura

Requirements Analysis

Design

EvolutionMaintenance

Sist

emi D

istr

ibui

ti (

2003

-200

4).

Vi.t

tori

oSc

aran

o

32

Requisiti non funzionaliRequisiti non funzionali

• I requisiti non funzionali che caratterizzano (e motivano!) un sistema distribuito sono – Scalabilità

– Openness

– Eterogeneità

– Condivisione delle risorse

– Tolleranza ai malfunzionamenti

– Trasparenza

• Importante! Un sistema distribuito è più costoso di un sistema centralizzato…. – se si può evitare… tanto di guadagnato! ☺

Sist

emi D

istr

ibui

ti (

2003

-200

4).

Vi.t

tori

oSc

aran

o

33

Requisiti non funzionali per un sistema distribuitoRequisiti non funzionali per un sistema distribuito

��

��

��

��

��

��

��

��

��

��

Sist

emi D

istr

ibui

ti (

2003

-200

4).

Vi.t

tori

oSc

aran

o

34

ScalabilitàScalabilità

• Il sistema distribuito deve essere in grado di – fornire il servizio ad un numero crescente di utenti

– fornire il servizio efficientemente ad un numero crescente di utenti

• Di solito realizzato aggiungemdo risorse– processori, cicli di clock (velocità), dischi, etc.

• Le componenti di un sistema non devono essere cambiate quando la dimensione di un sistema cresce– il progetto delle componenti non può prescindere dalla

scalabilità

• Definizione della qualità del servizio

Sist

emi D

istr

ibui

ti (

2003

-200

4).

Vi.t

tori

oSc

aran

o

35


��

��

��

��

��

��

��

��

��

��

Sist

emi D

istr

ibui

ti (

2003

-200

4).

Vi.t

tori

oSc

aran

o

36

OpennessOpenness

• Requisito non funzionale– che garantisce la stabilità in presenza di modifiche dei requisiti

funzionali

• Le estensioni ed i miglioramenti del sistema distribuito devono essere possibili con facilità

• Adesione agli standard– in modo da permettere la modifica

• Definizione delle interfacce delle componenti– che possono essere quindi sostituite/modificate facilmente

• Identificazione dei servizi prestati dalla componente– con un client ed un server attraverso una richiesta

• Flessibilità della richiesta in un ambiente distribuito– sulla stessa macchina, asincrona/sincrona, etc.

Sist

emi D

istr

ibui

ti (

2003

-200

4).

Vi.t

tori

oSc

aran

o

37


��

��

��

��

��

��

��

��

��

��

Sist

emi D

istr

ibui

ti (

2003

-200

4).

Vi.t

tori

oSc

aran

o

38

EterogeneitàEterogeneità

• Uso di diverse tecnologie – per i servizi

– per la gestione dei dati

– per la esecuzione delle componenti su piattaforme HW

• Necessaria: – per poter utilizzare in ogni parte del nostro sistema la

tecnologia più adatta allo scopo

• La integrazione di componenti eterogenee è possibile solamente in un ambiente distribuito– durante la comunicazione tra componenti

Sist

emi D

istr

ibui

ti (

2003

-200

4).

Vi.t

tori

oSc

aran

o

39


��

��

��

��

��

��

��

��

��

��

Sist

emi D

istr

ibui

ti (

2003

-200

4).

Vi.t

tori

oSc

aran

o

40

Condivisione delle risorseCondivisione delle risorse

• Possibilità di usare hardware, software, dati – dappertutto all’interno del sistema

• Necessario per rendere un sistema economicamente vantaggioso– riutilizzo di HW specializzato da parte di numerose funzioni

• Impone scelte per la sicurezza del sistema– gestite dal manager della risorsa

• Impone la gestione della concorrenza• Modelli di condivisione delle risorse

– client-server– basati su oggetti (invocazione di metodi)

Sist

emi D

istr

ibui

ti (

2003

-200

4).

Vi.t

tori

oSc

aran

o

41


��

��

��

��

��

��

��

��

��

��

Sist

emi D

istr

ibui

ti (

2003

-200

4).

Vi.t

tori

oSc

aran

o

42

Tolleranza ai malfunzionamentiTolleranza ai malfunzionamenti

• Hardware, software e rete (a volte) non funzionano

• Necessità che il sistema continui a funzionare (anche parzialmente) in presenza di malfunzionamenti

• Tecniche per ottenere la tolleranza ai malfunzionamenti– recovery

– ridondanza (replication)

Sist

emi D

istr

ibui

ti (

2003

-200

4).

Vi.t

tori

oSc

aran

o

43


��

��

��

��

��

��

��

��

��

��

Sist

emi D

istr

ibui

ti (

2003

-200

4).

Vi.t

tori

oSc

aran

o

44







Sist

emi D

istr

ibui

ti (

2003

-200

4).

Vi.t

tori

oSc

aran

o

45

TransparenzaTransparenza

• I sistemi distribuiti devono essere percepiti– dall’utente

– e dal programmatore di applicazioni

come un unicum piuttosto che come un insieme di componenti che cooperano

• La trasparenza viene rappresentata attraverso varie dimensioni– che rappresentano le proprietà che un sistema distribuito

dovrebbe avere

• Definite da board internazionali– International Standard on Open Distributed Processing

Sist

emi D

istr

ibui

ti (

2003

-200

4).

Vi.t

tori

oSc

aran

o

46

Trasparenzadell’accesso

TrasparenzaTrasparenza neinei sistemisistemi distribuitidistribuitiSi

stem

i Dis

trib

uiti

(20

03-2

004)

. V

i.tto

rio

Scar

ano

47

Trasparenza dell’accessoTrasparenza dell’accesso

• La interazione tra componenti avviene attraverso la richiesta di un servizio…

• Le interfacce devono essere le stesse sia per accedere un oggetto da remoto che da locale– questo permette di poter muovere componenti all’interno del

nostro sistema

• Alcuni esempi:– le operazioni sui file di NFS (Network File System)

– navigazione sui Web

– SQL query su database distribuiti

Sist

emi D

istr

ibui

ti (

2003

-200

4).

Vi.t

tori

oSc

aran

o

48


Trasparenzadella locazione

TrasparenzaTrasparenza neinei sistemisistemi distribuitidistribuiti

Sist

emi D

istr

ibui

ti (

2003

-200

4).

Vi.t

tori

oSc

aran

o

49

Trasparenza della LocazioneTrasparenza della Locazione

• Per richiedere un servizio, componenti devono rivolgersi ad altre componenti

• Alle componenti possono essere richiesti servizi senza che se ne debba conoscere la locazione fisica (host)

• Esempi:– Operazioni su NFS indipendenti dal volume montato

– Pagine sul Web

– Tabelle su database distribuiti

– Video in un sistema di video-on-demand Sist

emi D

istr

ibui

ti (

2003

-200

4).

Vi.t

tori

oSc

aran

o

50



Trasparenzadella migrazione


stem

i Dis

trib

uiti

(20

03-2

004)

. V

i.tto

rio

Scar

ano

51

Trasparenza della migrazioneTrasparenza della migrazione

• Permette lo spostamento di una componente senza influenzare le operazioni ed i servizi offerti agli utenti ed a altre componenti

• Alcune motivazioni allo spostamento:– overload (aggiunta di componenti)

– rilocazioni di componenti più vicine all’utente

• Esempi:– NFS

– pagine Web

– giocatori nel sistema della Lega Calcio

Sist

emi D

istr

ibui

ti (

2003

-200

4).

Vi.t

tori

oSc

aran

o

52




Trasparenzadella replica


Sist

emi D

istr

ibui

ti (

2003

-200

4).

Vi.t

tori

oSc

aran

o

53

Trasparenza della replicaTrasparenza della replica

• Ci sono alcuni vantaggi ad avere servizi (componenti) replicate nel sistema.– overhead: lo stato delle repliche deve essere sincronizzato

• Permette l’uso di repliche di componenti (per aumentare prestazioni ed affidabilità) senza che ne sia necessaria la conoscenza da parte di utenti o programmi

• Esempi:– DBMS distribuiti

– sistemi di mirroring (siti Web, ftp, etc.)

– sistemi di video-on-demand (per i picchi di carico)

Sist

emi D

istr

ibui

ti (

2003

-200

4).

Vi.t

tori

oSc

aran

o

54



Trasparenzadella concorrenza




stem

i Dis

trib

uiti

(20

03-2

004)

. V

i.tto

rio

Scar

ano

55

Trasparenza della ConcorrenzaTrasparenza della Concorrenza

• Permette a diversi processi concorrenti di accedere componenti del sistema senza interferenze reciproche

• Esempi:– NFS (meccanismo di lock)

– Bancomat (in un sistema bancario)

– DBMS

– Lega Calcio: un giocatore può essere utilizzato nella sua squadra e nella nazionale, da due diverse componenti (allenatore del club e allenatore della nazionale) Si

stem

i Dis

trib

uiti

(20

03-2

004)

. V

i.tto

rio

Scar

ano

56






Trasparenzadei malfunzionamenti


Sist

emi D

istr

ibui

ti (

2003

-200

4).

Vi.t

tori

oSc

aran

o

57

Trasparenza dei malfunzionamentiTrasparenza dei malfunzionamenti

• Permette di nascondere i malfunzionamenti dagli utenti e dalle componenti sia client che server.

• Supportato dalla trasparenza della concorrenza e della replica

• La integrità delle componenti non deve essere violata – problemi possono sorgere da aggiornamenti parziali

– importante che il sistema offra un ambiente per transazioni

• Esempi: – Database Management System

– transazioni bancarie

Sist

emi D

istr

ibui

ti (

2003

-200

4).

Vi.t

tori

oSc

aran

o

58





Trasparenzadelle prestazioni




stem

i Dis

trib

uiti

(20

03-2

004)

. V

i.tto

rio

Scar

ano

59

Trasparenza delle prestazioniTrasparenza delle prestazioni

• Permette di nascondere come vengono ottenute le prestazioni del sistema

• Quindi il sistema viene “silenziosamente” (per l’utente) riconfigurato per poter migliorare le prestazioni al crescere del carico– tecniche di load balancing

• Esempio:– Una make distribuita per compilare in parallelo su più

macchine

Sist

emi D

istr

ibui

ti (

2003

-200

4).

Vi.t

tori

oSc

aran

o

60





Trasparenzadelle prestazioni

Trasparenzadella scalabilità




Sist

emi D

istr

ibui

ti (

2003

-200

4).

Vi.t

tori

oSc

aran

o

61

Trasparenza della Trasparenza della scalabilitàscalabilità

• Permette al sistema ed alle applicazioni di crescere di dimensione senza che cambi la struttura o i protocolli utilizzati

• Supportato dalla capacità di nascondere la migrazione e l’utilizzo di repliche

• Esempi:– il World Wide Web

• confronto con gli Open Hypermedia

– Database Distribuiti Sist

emi D

istr

ibui

ti (

2003

-200

4).

Vi.t

tori

oSc

aran

o

62

ConclusioniConclusioni


• L’architettura distribuita di un sistema viene dettata dai requisiti non funzionali

• Fondamentale per un sistema distribuito è la trasparenza verso utenti e designer– La trasparenza ha diverse dimensioni, con una certa

interdipendenza tra di esse

Organizzazione della lezione Lezione 1 Obiettivi del corso ... · – di linguaggio di...

Documents

Transcript of Organizzazione della lezione Lezione 1 Obiettivi del corso ... · – di linguaggio di...